Ladezeitoptimierung

[Cax]

Hi

Ich suche Webseiten mit dem Thema Ladezeitoptimierung...
bzw. Tipps zum schnelleren Seitenaufbau
(Es geht mir aber nicht um Tipps, wie möglichst kleine Bilder, möglichst wenig verschachtelte Tabellen, sondern eher wie viele Tabelle am sinnvollsten sind, ob man eine Tabelle lieber in 2 teilen sollte, usw.)
Mir ist schon klar, das es im DSL Zeitalter nicht mehr wirklich viel aus macht, aber trotzdem interessiert mich dieses Thema.

Danke im voraus,
Cax

[Kai Lahmann]

hi

(Es geht mir aber nicht um Tipps, wie möglichst kleine Bilder, möglichst wenig verschachtelte Tabellen, sondern eher wie viele Tabelle am sinnvollsten sind, ob man eine Tabelle lieber in 2 teilen sollte, usw.)
Mir ist schon klar, das es im DSL Zeitalter nicht mehr wirklich viel aus macht, aber trotzdem interessiert mich dieses Thema.

nicht nur das. Die meisten Optimierungen schaden mehr, als das sie nützen. Das einzige, woran man sich halten sollte ist möglichst keine kilometerlangem Tabellen zu haben. mod_gzip auf dem Server bringt oft mehr Speed als unzählige Fummeleien an der Seite.
Dann noch 2 kleinere Tipps:
1. gute CSS-Formatierung ist immer schneller als <font> und co
2. einige Browser haben bei schlampigem HTML die Angewohnheit erstmal "ne Runde zu lachen".

Achja, und falls du viel auf Netscape 4 achten musst: der mag keine wilden Tabellen, irgendwann kannste inzwischen Kafee kochen.

Grüße aus Bleckede

Kai

[Mulder]

Ich suche Webseiten mit dem Thema Ladezeitoptimierung...
bzw. Tipps zum schnelleren Seitenaufbau
(Es geht mir aber nicht um Tipps, wie möglichst kleine Bilder, möglichst wenig verschachtelte Tabellen, sondern eher wie viele Tabelle am sinnvollsten sind, ob man eine Tabelle lieber in 2 teilen sollte, usw.)

Die _Anzahl_ der Tabellen ist relativ wurscht (obwohl viele Tabellen ja auch viel Quellcode bedeuten, der über die Leitung gehen muß). Nur die Komplexität ist entscheidend.
Und die Frage "Tabelle lieber in 2 teilen" hat doch auch was mit "möglichst wenig verschachtelte Tabellen" zu tun, oder?

Mir ist schon klar, das es im DSL Zeitalter nicht mehr wirklich viel aus macht, aber trotzdem interessiert mich dieses Thema.

Doch, das macht noch was aus. Bei unserem Shop haben immerhin 36% der Betatester die Ladezeiten kritisiert (Startseite ca. 110 KB damals, was ja per DSL in 1.2 Sek. da wäre).

Generell:

* Doppelte Leerzeichen raus. Bis zu 5% einer Seite bestehen oft aus überflüssigen Leerzeichen (z.B. wenn Einrückungen per Space statt per Tab gemacht sind).
* Bildnamen kürzen. Auf manchen Seiten, bei denen mit transparenten GIFs gelayoutet wird, sind teilweise 300mal <img src = "graphics/misc/empty.gif"> zu finden - da lohnt sich ne Verkürzung auf "g/e.gif" enorm.
* Javascript zusammenfassen. Hier gilt: kommt eine Variable mehr als einmal vor, lohnt es sich, ein kürzeres Alias zu definieren.
Beispiel:

blubb = document.forms['foo'].shit.value;
schnarch = document.forms['foo'].blah[document.forms['foo'].blah.selectedIndex].text;

=>

f = document.forms['foo'];
b = f.blah;
blubb = f.shit.value;
schnarch = b[b.selectedIndex].text;

etc. (125 => 96 Bytes, also 30 Bytes pro Zeile!)

[gini]

webseite zu dem thema kein ich leider keine...

die größten Ladezeitprobleme habe ich immer mit externen Elementen - Tracker/counter/Gästebuch... -> weglassen oder selbst machen.

auf frames verzichten, der browser muß das frameset und jeden frame einzeln vom server anfordern, die antwortzeiten kommen ja zur ladezeit dazu.

Die _Anzahl_ der Tabellen ist relativ wurscht (obwohl viele Tabellen ja auch viel Quellcode bedeuten, der über die Leitung gehen muß). Nur die Komplexität ist entscheidend.
Und die Frage "Tabelle lieber in 2 teilen" hat doch auch was mit "möglichst wenig verschachtelte Tabellen" zu tun, oder?

nein, hier geht es darum daß tabellen erst angezeigt werden wenn der komplette inhalt geladen wird. darum sollte man recht lange seiten nicht in eine tabelle stecken, sondern z.b. in der mitte teilen. dann kann der user schon lesen, während die untere tabelle geladen wird.

Generell:

* Doppelte Leerzeichen raus. Bis zu 5% einer Seite bestehen oft aus überflüssigen Leerzeichen (z.B. wenn Einrückungen per Space statt per Tab gemacht sind).

ich verzichte im html meistens komplett auf einrückungen. bei standard-dreamweaver-einstellungen sind meine seiten durch die einrückungen schon über doppelt so groß geworden, man kann das aber abstellen.

[Michael Schröpl]

Hi,

auf frames verzichten, der browser muß das frameset und jeden frame
einzeln vom server anfordern, die antwortzeiten kommen ja zur ladezeit
dazu.

Ja - aber nur einmal. Danach innerhalb derselben Session nie wieder.
Im Schnitt ist es weniger Traffic mit Frames als ohne.

nein, hier geht es darum daß tabellen erst angezeigt werden wenn der
komplette inhalt geladen wird.

Nicht unbedingt - nur dann, wenn das Layout der Tabellen vom Inhalt abhängt.
Tut es das nicht (weil z. B. feste Spaltenbreiten bereits in der Kopfzeile der Tabelle vorgegeben sind), dann kann der Browser die Tabelle sofort darstellen.

ich verzichte im html meistens komplett auf einrückungen. bei standard-
dreamweaver-einstellungen sind meine seiten durch die einrückungen schon
über doppelt so groß geworden, man kann das aber abstellen.

Ich lasse HTML-Seiten durch ein "uglyfyer"-Perl-Skript laufen, das alles rausmacht, was ich online nicht brauche (Kommentare, Leerzeichen, z. T. sogar Zeilenumbrüche).

Viele Grüße
      Michael

[Michael Schröpl]

Hi Cax,

* Doppelte Leerzeichen raus. Bis zu 5% einer Seite bestehen oft aus
überflüssigen Leerzeichen (z.B. wenn Einrückungen per Space statt
per Tab gemacht sind).

das ist wahr. Aber wenn die Seiten gleich komprimiert ausgeliefert werden, dann macht das fast nichts mehr aus, weil solche überflüssigen Leerzeichen phantastisch gut komprimiert werden können. (mod_gzip spart bei normalen sites 50-70% des Brutto-Traffic.)

* Bildnamen kürzen. Auf manchen Seiten, bei denen mit transparenten
GIFs gelayoutet wird, sind teilweise 300mal <img src =
"graphics/misc/empty.gif"> zu finden - da lohnt sich ne Verkürzung
auf "g/e.gif" enorm.

Dann doch mindestens auch zusätzlich aggressiv cachen (HTTP-Header mit sinnvollen Aufbewahrungsfristen mitsenden).
Jeder Zugriff auf ein Bild mit einem gekürzten Pfadnamen spart vielleicht 20-50 Bytes; jeder Zugriff, der gar nicht erst abgefeuert wird, spart knapp 1000 Bytes an TCP- und HTTP-Headern.

* Javascript zusammenfassen. Hier gilt: kommt eine Variable mehr als
einmal vor, lohnt es sich, ein kürzeres Alias zu definieren.
Beispiel:
f = document.forms['foo'];
b = f.blah;
blubb = f.shit.value;
schnarch = b[b.selectedIndex].text;
etc. (125 => 96 Bytes, also 30 Bytes pro Zeile!)

Nicht nur das - es ist womöglich auch noch im Client schneller ausführbar als irgendwelche komplizierten Adressierungen (bei denen sich der Verfasser gar nicht bewußt ist, wie teuer die sind - getElementByID ist so ein Kandidat, der ganz schön kompliziert sein kann).

Viele Grüße
      Michael