Seite 4 von 11
#46
Verfasst: 12.12.2005 20:52:28
von Jonas
6s geladen nachdem ich auf antwort erstellen geklickt habe...
Aber seht es doch mal so, früher waren wir alle mit modem unterwegs, da haben wir minuten auf eine seite gewartet!
Also stellt euch nicht so an...
Obwohl es teilweise echt verdammt langsam läuft.
#47
Verfasst: 12.12.2005 20:54:13
von helihopper
Hmm,
dann werden eben Bilder, die die Grenzen übersteigen vom System abgelehnt. Fettich.
Es sollte inzwischen bekannt sein, dass die Bildgrössen, die einige hier mal eben hochjuckeln
a. unnötigen Traffic verursachen (den Eco Zuckungentread mache ich schon gar nicht mehr auf, weil es nur nervt auf die paar überdimensionierten Bilder zu warten)
b. nervige scrollerei erfordern
Cu
Harald
#48
Verfasst: 12.12.2005 20:57:25
von tracer
OK, ich nehme es mal raus.
Dann schauen, ob es daran liegt, wenn ja, lass ich mir ne andere Lösung einfallen.
#49
Verfasst: 12.12.2005 21:01:14
von Patanjali
Also, um ehrlich zu sein, ist mir nicht unbedingt aufgefallen, dass das RHF langsamer ist als andere Internetseiten. Warum Google so schnell ist, werd ich eh nie verstehen ...
@Jonas: ja, stimmt schon, in den Gründerzeiten haben einfache Textpages schon mal locker 30s gebraucht und man hat versucht alles mit Grafik zu vermeiden. Akzeptieren sollte man aber nicht, dass das heute fast genauso langsam ist, weil schließlich die Hardware 10^4 mal schneller, und die Leitungen auch ca. 10^3 mal schneller geworden sind ... aber das ist ja ein generelles Problem: warum ist Word 200x auf einem 2.5 GHz Rechner genauso langsam wir Winword x.x auf einem 386 mit 33 MHz? Obwohl es KAUM mehr Funktionen hat (die dämliche Büroklammer stellt man eh beim ersten Mal ab)??????????? Gibt's dafür eine Erklärung???
#50
Verfasst: 12.12.2005 21:07:24
von xxxheli
Warum kann nicht generell einführen das die Bilder
nicht gleich in der richtigen voller Größe gezeigt werden sondern
nur so wie die Attachmentbilder in der kleinen Box oder wie man das nennt.
Wer sie dann in voller Pracht sehen möchte klickt hallt drauf.
Ist das nicht schneller?
#51
Verfasst: 12.12.2005 21:14:35
von Dome
xxxheli hat geschrieben:Warum kann nicht generell einführen das die Bilder
nicht gleich in der richtigen voller Größe gezeigt werden sondern
nur so wie die Attachmentbilder in der kleinen Box oder wie man das nennt.
Wer sie dann in voller Pracht sehen möchte klickt hallt drauf.
Ist das nicht schneller?
Das Problem ist, dass man nicht so einfach Abfragen machen kann, wie groß das Bild ist etc.
So wie es jetzt ist, ists eigentlich keine tolle Lösung.
Aber das Phpbb erschwert das ganze.
Am besten wäre es, wenn Bilder bis zu einer bestimmten Größe einfach angezeigt werden würden und die die gößer sind verkleinert und dann verlinkt oder einfach nur verlinkt werden
Aber das lässt sich mit dem php net so einfach realisieren, mal sehn ob es daran liegt, wenn ja, dann lassen wir uns was besseres einfallen
#52
Verfasst: 12.12.2005 21:26:11
von tracer
Ich habe das Verkleinern mal rausgenommen, daran scheint es aber nicht zu liegen.
#53
Verfasst: 12.12.2005 21:45:32
von Patanjali
es liegt nicht daran wieviele oder wiegroße Bilder auf einer Seite sind. Die Bilder des "ECO-8-Zuckungen-Threads" (Zitat: Helihopper) werden eh erst nachgeladen, nachdem die ganze Seite schon da ist (inkl. Tracers Zeitmessungs-Zeile), die ansonsten weder schneller als langsamer ist als reine Textseiten. Und die ECO-8-Bilder brauchen bei mir auch nur weniger als ein paar Sekunden (zumindest weniger als die Seite ohne die Bilder). Also liegts nicht am Seiteninhalt oder an der Provider-Bandbreite ... ich hab keine Ahnung von Protokollen. Aber falls in der digitalen Kodierungswelt irgendwas zu langsam ist, gibt man immer den Protokollen die Schuld ... aber das machen so Hardwareleute wie ich halt gerne: die Schuld den DSP-Fritzen in die Schuhe schieben, weil an der Hardware kanns nicht liegen ...
#54
Verfasst: 12.12.2005 21:48:54
von tracer
Patanjali hat geschrieben:es liegt nicht daran wieviele oder wiegroße Bilder auf einer Seite sind.
War aber nicht auszuschliessen, da jeden Bild, das verlinkt ist, analysiert wrd, und dann ggf. verkleinert.
On the fly, um keine Copyrightprobleme zu bekommen.
Aber daran lag es wohl nicht

#55
Verfasst: 12.12.2005 21:51:19
von bugatti
Hi Micha
Page generation time: 4.1903s (PHP: 64% - SQL: 36%) - SQL queries: 92 - GZIP enabled - Debug off
für Umts ist das eigentlich sehr ok.
Beste Grüße
#56
Verfasst: 12.12.2005 21:53:18
von tracer
Hmm, also unabhängig von der Uhrzeit dauert es bei einigen Ewig, bei anderen geht es schnell...
#57
Verfasst: 12.12.2005 21:56:10
von bugatti
die rein subjektiven Zugriffszeiten, sind auch via ISDN (Tiscali) immer sehr gut, auch schon bei den anderen freds.
Beste Grüße
#58
Verfasst: 12.12.2005 22:04:24
von Patanjali
wie kann man, wenn man sich bugatti schimpft, mit diesen Zugriffszeiten zufrieden sein ... hast ihn nur in der Garage stehen????
#59
Verfasst: 13.12.2005 12:36:32
von helihopper
Öhmm,
da fällt mir noch was ein.
Kann das mit den Bannern zusammen hängen?
Ich frage mich das, weil es bei einigen Seitenaufrufen immer recht flott geht und bei anderen nicht. Unabhängig von der Benutzeranzahl.
Also mal drauf achten, ob da ein Zusammenhang bestehen könnte.
Cu
Harald
#60
Verfasst: 13.12.2005 12:41:47
von Dome
naja Harald, dass wäre nur der fall, wenn das script von den Bannern viele Ressourcen ziehen würde.
Die Zeit unten zeigt ja an, wie lange es gedauert hat, dass PhP die Seite zusammengestellt hat (sprich aus programmierung wird dann html was dann zu dir geschickt wird)
Die Banner läd ja dann dein Browser und hat keinen Einfluss auf die Zeit da unten (eigentlich)
korrigiert mich, wenn ich falsch liege.
Aber grundsätzlich könnte es jedes Script sein, oder wirklich der Server der so lahm is, also ganz falsch liegst du nicht, Harald

Evtl mal ein Phpbb aufsetzen, mit nem andren verzeichniss und ner copy von der datenbank und dann mal sehn was passiert wenn da mehrere rumsurfen?