Freitag,
25. September 2009
25. September 2009
Gestern, am 24.9. hatte ich die Ehre, zusammen mit David Maciejewski auf dem “Best of Accessibility” Symposium über Möglichkeiten zur Optimierung der Ladezeiten von Webseiten zu sprechen. David war so freundlich und hat die Folien bereits bei Slideshares hochgeladen, sodass ich sie hier zur Verfügung stellen kann.
Zum Thema CSS-Sprites gibt es weiterhin eine kleine Demo von David, welche er soeben online bereit gestellt hat.
Weitere Vorträge im Netz:
Freitag, 25.09.09 (13:13 Uhr)
Die Image-Slide könnt ihr euch unter lab.macx.de ansehen.
Freitag, 25.09.09 (14:44 Uhr)
Ihr erwähnt auf Folie 9 HTML Tidy. Funktioniert das entfernen von Whitespace auch zuverlässig mit pre Tags oder Textareas?
Ich habe da bisher schlechte Erfahrungen mit gemacht und verzichte deshalb darauf…
Freitag, 25.09.09 (15:06 Uhr)
@David
Was mich etwas irritiert ist, dass die Navi-Sprites hier (sogar mit Demo) als neue Lösung mit der “klassischen Methode” kontrastiert werden, obwohl sie doch selbst längst ein Klassiker sind. Und im Kontext eines Symposiums über “Best of Accessibility” wundert mich, dass hier der Text des Navi-Elements Teil der Grafik ist und nicht unabhängig von der Grafik besteht, die meines Erachtens für zugängliches Design zudem in der Größe variabel sein sollte (auch da lassen sich ja performance-verbessernde Sprites basteln).
@David und Dirk
Danke für die interessanten Tests und die Mühe!
Die Testergebnisse muss ich mir mal noch im Detail zu Gemüte führen.
Freitag, 25.09.09 (17:10 Uhr)
Hi,
netter Slide.
Wie? Wat? – gibst 8-bit .png nun auch schon mit Aphakanal(im PS CS4)??
Beim PS CS3 gibs nur 1 Transparenzfarbe.
Aber nun was anderes, klar, man kann Bilder optimieren, aber wenn ich eine Galerie mache, wo Werke und Bilder von Künstlern ausgestellt werden, werd ich ein Bild von 800 x 600 pixel grösse nicht optimieren, auch nicht unbedingt als .jpg abspeichern (wenn dann meistens nur unter voller Qualität). Ich selbst bevorzuge (und das ist mein absoluter Favorit) das .png-Format. Ist meistens ein vielfaches Grösser (in kB) gefällt mir aber auch um ein vielfaches mehr.
Quintezens: Das Auge spielt bei Optimierung auch eine Rolle, auch wenn es mal 1 sek. länger dauert, das ein Bild läd. Die Gleiche Diskussion könnte man ja auch anders führen, wie Qualität vs. Speed.
Don
Freitag, 25.09.09 (17:16 Uhr)
@Zeek: Ich hatte derartige Probleme bisher nicht, was aber nichts heissen muss. Jedoch sollte es auch ohne Tidy für ein wenig geübte Programmierer möglich sein, Kommentare und Whitespaces zu filtern und dabei diese speziellen Elemente außen vor zu lassen.
@Antonio: CSS-Sprites mögen nicht mehr ganz so frisch sein, dennoch werden sie bisher nicht oft eingesetzt - z.T. weil ihre Erstellung etwas komplizierter sein mag. Es lohnt daher auch heute noch, diese Technik anzupreisen. Was die Texte in den Grafiken angeht, schau Dir bitte den HTML-Quelltext der Demo an. Die Menütexte finden sich selbstverständlich auch im HTML und somit für Screenreader zugänglich. Auch die Verwendung von Grafiken und damit fixen Breiten ist per Definition keine Barriere. Die Schriften sind groß, ausreichend kontrastreich und das Menü lässt sich problemlos mit jedem modernen Browser skalieren.
Freitag, 25.09.09 (17:22 Uhr)
@Don: 8-bit PNGs mit Alphakanal lassen sich aktuell nur mit Adobe Fireworks erstellen, dort aber schon seit einigen Versionen.
Zum Thema Galerien: Im Web sind bei Fotos so gut wie nie 100% Qualität erforderlich. Ich habe lange ein Fotoblog betrieben, dort ist kein einziges Foto mit Qualitätseinstellungen oberhalb 75% abgespeichert. Das Einsparungspotential gerade bei Fotos ist enorm, ohne dass für das Auge eine sichtbare Beeinträchtigung der Qualität entsteht.
Freitag, 25.09.09 (17:48 Uhr)
Kommentare filtern ist nicht das Problem. Aber beim Whitespace sieht das schon anders aus. Außerdem glaube ich nicht, dass sich die Größe bei der Verwendung von Gzip großartig unterscheidet (Whitespace entfernt zu normal). Da wäre aber eine Messung mal ganz hilfreich.
Freitag, 25.09.09 (17:55 Uhr)
@Zeek: Wir hatten sowas vor kurzem erst auf einer größeren Webseite getestet. Mit Entfernung von Kommentaren und Whitespaces kamen auf auf die Hälfte der Einsparungen von Gzip. Allerdings ging Gzip in diesem Fall nach hinten los, weil das Caching nicht korrekt funktionierte und die Serverantwortzeiten deshalb deutlich stiegen. Somit wurde Gzip wieder abgeschaltet und das Säubern des HTML blieb drin. Auf die Markupgröße bezogen waren es immer noch ca. 20-30% Einsparung.
Freitag, 25.09.09 (18:09 Uhr)
Hab dazu gerade was gefunden: Don’t bother using HTML white-space removal to speed up a web site
Freitag, 25.09.09 (18:15 Uhr)
Cool. Danke für den Link
Freitag, 25.09.09 (21:33 Uhr)
Ich finde es etwas gewagt, von Barrierefreiheit zu reden und die Informationen in eine kaum lesbare Präsentation zu verpacken.
Samstag, 26.09.09 (11:01 Uhr)
Ladezeiten bekommt man mit schlankem sauberem Markup recht gut in den Griff. Und mit einem angemessenen Cacheing kann man das noch mal signifikant beschleunigen.
Letzteres geht natürlich nur, wenn man statische Inhalte auch statisch ausliefert. Dynamisch erzeugte Seiten lassen sich nun mal grundsätzlich nicht cachen.
Mittwoch, 07.10.09 (01:30 Uhr)
Als Leser der ersten Stunde von Steve Souders “High Performance Web Sites” beschäftige ich mich schon eine gute Weile mit der Optimierungsliste von YSlow, und dem Thema Ladezeiten. Im Laufe der Zeit hat sich da einiges an Lösungsansätzen gesammelt. Angeregt durch Euren tollen Vortrag hab ich mich mal aufgerafft und ein kleines PHP-Paketchen aus all dem geschnürt, mit dem jeder seine Seite in den wesentlichen Punkten automatisiert beschleunigen lassen kann (sofern es sich ins bestehende Code-Umfeld einbauen lässt). Eine Abweichung allerdings zu Euren Empfehlungen: CSS-Bilder werden bei mir nicht in Sprites gesteckt, sondern on-the-fly in inline-data:URIs, respektive MHTML für IE <= 7 gewandelt.
Vielleicht nützt es ja noch wem außer mir selbst?
CSS-JS-Booster
Donnerstag, 08.10.09 (16:33 Uhr)
Diese Sprite Navigation hat zusätzlich halt noch den Vorteil in den IEs, dass beim Laden der neuen Bilder dem “aufblitzen und Flackern” ein Ende gesetzt ist.
Freitag, 09.10.09 (10:38 Uhr)
@Schepp
Sehr interessantes Projekt. Schaue ich mir demnächst mal genauer an. Danke.
Gruß
Dirk
Montag, 23.11.09 (19:23 Uhr)
Ladezeiten sind echt ein wichtiges Kriterium. Wenn ich auf ne Seite gehe die eine lange Ladezeit hat verliere ich meist die Lust und gehe auf eine andere.