Performance Optimierung - Barrierefreiheit beginnt mit Ladezeiten http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Performance Optimierung - Barrierefreiheit beginnt mit LadezeitenView more documents from David Maciejewski. Zum Thema CSS-Sprites gibt es weiterhin eine kleine Demo von David, welche er soeben online bereit gestellt hat. Weitere Vorträge im Netz: Jan Eric Hellbusch, “WCAG 2.0 und BITV2 für Einsteiger”Jens Meiert: HTML5: Barrierefreiheit, Performance, WartbarkeitChristian Heilmann: Barrierefreiheit im Datennetz de-de Dirk Jesse Copyright 2009 2009-09-25T;08:54:26+00:00 Kommentar von Marco http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ @Schepp Sehr interessantes Projekt. Schaue ich mir demnächst mal genauer an. Danke. Gruß Dirk @Schepp

Sehr interessantes Projekt. Schaue ich mir demnächst mal genauer an. Danke.

Gruß
Dirk

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Guenter http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Schepp http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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 &lt;= 7 gewandelt. Vielleicht nützt es ja noch wem außer mir selbst? CSS-JS-Booster 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

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Siegfried http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Harald http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Ich finde es etwas gewagt, von Barrierefreiheit zu reden und die Informationen in eine kaum lesbare Präsentation zu verpacken. Ich finde es etwas gewagt, von Barrierefreiheit zu reden und die Informationen in eine kaum lesbare Präsentation zu verpacken.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Cool. Danke für den Link Cool. Danke für den Link

]]> 2012-01-18T;11:39:34+00:00 Kommentar von zeek http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Hab dazu gerade was gefunden: Don’t bother using HTML white-space removal to speed up a web site Hab dazu gerade was gefunden: Don’t bother using HTML white-space removal to speed up a web site

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ @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. @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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von zeek http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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. 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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ @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. @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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Dirk Jesse http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ @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. @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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Don http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Hi, netter Slide. Wie? Wat? –&nbsp; 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 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

]]> 2012-01-18T;11:39:34+00:00 Kommentar von Antonio http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ @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. @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.

]]> 2012-01-18T;11:39:34+00:00 Kommentar von zeek http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ 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… 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…

]]> 2012-01-18T;11:39:34+00:00 Kommentar von David Maciejewski http://www.highresolution.info/weblog/entry/performance_optimierung_barrierefreiheit_beginnt_mit_ladezeiten/ Die Image-Slide könnt ihr euch unter lab.macx.de ansehen. Die Image-Slide könnt ihr euch unter lab.macx.de ansehen.

]]> 2012-01-18T;11:39:34+00:00