Wie Sie die Qualität einer Website sichern · 9 Testen und optimieren 444 Außerdem erlaubt der Internet Explorer ab Version 9, eine Web-site in früheren Versionen des Browsers

9Testen und optimierenWie Sie die Qualität einer Website sichern

E Wie teste ich Websites?

E Wie optimiere ich Ladezeiten?

E Wie überprüfe ich Usability und Accessibility?

9 Testen und optimieren

442


Konzeption, Struktur und Layout, Typografie, Farben, Grafiken – mit all diesen Mitteln haben Sie in den bisherigen Kapiteln gear-beitet, um eine gute Gestaltung zu erreichen. Ein Aspekt fehlt Ihnen noch – und er ist zugleich einer der wichtigsten: Qualitäts-sicherung. Lernen Sie in diesem Kapitel, wie Sie Ihre Website so testen und optimieren können, dass wirklich (fast) nichts mehr schiefgehen kann.

9.1 Funktionalitäten sicherstellen

Jeder Browser ist anders. Es ist daher absolut unmöglich, dass eine Website in allen Browsern gleich aussieht. Ihr Ziel sollte es jedoch sein, dass die Website in jedem Browser gut aussieht und funktioniert – wie das geht, erfahren Sie in diesem Abschnitt.

Browser-Statistiken abfragen

Zunächst einmal sollten Sie sich entscheiden, welche Browser überhaupt getestet werden sollen. Viele Designer möchten dar-auf mit »Alle« antworten – das Problem dabei wäre jedoch, dass Ihnen das tagelange Anpassungen bescheren würde.

Sinnvoller ist es, seine Entscheidung auf Statistiken zu basie-ren. Wenn Sie an einer Neugestaltung einer bestehenden Web-site arbeiten, gibt es häufig Erkenntnisse darüber, mit welchen Browsern die eigenen Nutzer arbeiten – nichts ist besser. Ansons-ten müssen Sie sich an allgemeine Statistiken halten. Gute Quel-len dafür sind die Website http://gs.statcounter.com und das Por-tal https://de.statista.com.

Funktionalitäten sicherstellen 9.1

443

Testumgebung vorbereiten

Da sich viele Browser weitgehend standardkonform verhalten, reicht es normalerweise, die aktuellen beiden Versionen zu tes-ten. Bei einigen Browsern ist es möglich, mehrere Versionen auf einmal zu installieren.

Virtuelle Maschinen und Screenshot-Services | Microsoft hält für Web-Entwickler einen tollen Service unter https://developer.microsoft.com/en-us/microsoft-edge bereit:

E Sie können virtuelle Maschinen herunterladen, mit denen Sie Websites auf unterschiedlichen Versionen von Internet Explo-rer und Edge testen können – beispielsweise mit der kosten-losen Virtualisierungssoftware Virtual Box (auch auf Mac und Linux).

E Sie können sich Screenshots einer Website in einigen Brow-sern erstellen lassen. Dabei arbeitet Microsoft mit Browser-Stack (www.browserstack.com) zusammen – einem Service, bei dem Sie Websites für wenig Geld in über 1.000 Browser-Ver-sionen testen können. Eine Alternative ist der Service Cross-BrowserTesting (https://crossbrowsertesting.com).

E Eine Schnellanalyse liefert Ihnen erste Anhaltspunkte zur Optimierung.

F Abbildung 9.1 Browser-Marktanteile in Deutschland im Septem-ber 2016

BonusFalls Sie noch für ältere Versionen des Internet Explorers optimieren möchten, finden Sie im Bonus-Kapitel »optimie-ren-internet-explorer.pdf« einige Hinweise.


444

Außerdem erlaubt der Internet Explorer ab Version 9, eine Web-site in früheren Versionen des Browsers anzuschauen: Öffnen Sie dazu die Entwicklertools im Menü Extras, und wählen Sie unter Browsermodus die gewünschte IE-Version aus.

Alle Browser haben umfangreiche Entwicklertools an Bord, mit denen Sie verschiedenste Situationen simulieren können. Es lohnt sich, einen Blick in die Dokumentation und die Online-Kurse zu werfen, die von den Browser-Herstellern zur Verfügung gestellt werden – hier lernt man immer wieder Kniffe, die das Testen ver-einfachen. Für Google Chrome erreichen Sie diese beispielsweise unter https://developers.google.com/web/tools/chrome-devtools/.

Breakpoints testen | Responsive Webdesign stellt Sie vor die Her-ausforderung, neben verschiedenen Browsern auch unterschiedli-che Viewport-Breiten testen zu müssen. Ein sehr gutes Hilfsmittel ist das kleine Bookmarklet »Viewport Resizer« von Malte Was-sermann, das Sie unter http://lab.maltewassermann.com/viewport-resizer finden. Ziehen Sie den blauen Button einfach in die Lesezei-chen-Leiste Ihres Browsers – schon ist das Tool einsatzbereit. Zum Testen öffnen Sie einfach die zu analysierende Website und klicken

Abbildung 9.2 H Umstellen des Browser-Modus im Internet Explorer

Weitere ToolsWeitere Tipps für Tools zum Testen responsiver Websites finden Sie im Dokument »quellen-le-setipps.pdf« im Down-load-Bereich.


445

auf das Bookmarklet. In der Steuerleiste können Sie nun entweder eine der Vorgaben wählen oder eine freie Größe eintragen.

Außerdem bringen viele Browser mittlerweile eigene Tools mit. Abbildung 9.4 zeigt dies am Beispiel von Chrome. Mit einem Klick auf 3 wird das Tool zum Testen von Responsive Designs aktiviert. Anschließend lässt sich das Browser-Fenster im Bereich 1 manu-ell anpassen. Alternativ stehen unter 2 verschiedene Voreinstel-lungen für Viewport, Zoomstufe und Pixeldichte bereit.

Geräte simulieren | Solche Browser-Tools sind ein gutes Hilfs-mittel zum Testen von Breakpoints. Allerdings berücksichtigen sie nicht alle Aspekte, die für die User Experience auf mobilen Geräten relevant sind. Ein typisches Beispiel sind Formularfel-der. Während ein Browser-Tool letztlich nicht das Verhalten des Browsers verändert, blendet ein Smartphone beim Aktivieren des Felds eine passende Tastatur ein.

In der App-Entwicklung arbeiten Programmierer mit Simula-toren und Emulatoren, die Teil der Entwicklungsumgebungen sind – damit lassen sich auch Websites testen. Die Möglichkeiten hängen dabei von der verwendeten Plattform ab. So stellt Apple seine Entwicklungssoftware Xcode ausschließlich für Macs bereit.

G Abbildung 9.3 Viewport-Resizer-Book-marklet

F Abbildung 9.4 Testen des Responsive Designs mit Hilfe von Chrome

32

1

G Abbildung 9.5 Testen des Responsive De -signs mit Hilfe von Chrome- E-Mail-Formularfeld mit HTML5 auf dem iPhone-Simulator


446

Sie lässt sich kostenlos aus dem App Store herunterladen. Nach der Installation findet sich der iPhone-Simulator unter Xcode • Open Developer Tools • Simulator.

Die Entwicklungsumgebung für Android (»Android Studio«) steht hingegen für Mac, Windows und Linux unter https://deve-loper.android.com/studio/index.html zur Verfügung. Die Software kommt mit einem umfangreichen Emulator, der virtuelle Geräte in allen möglichen Konfigurationen erlaubt. Google stellt unter https://developer.android.com/studio/run/emulator.html Informati-onen bereit, wie das Tool konfiguriert werden kann.

Natürlich verfügt auch Microsoft über eine eigene Entwick-lungsumgebung namens »Visual Studio« (www.visualstudio.com/de/downloads).

Testen auf echten Geräten | Sinnvoll ist außerdem das Testen auf echten Geräten. Dazu haben sich sogenannte Device Labs etab-liert – Testlabore, die Zugang zu verschiedenen Geräten bieten. Eine tolle Initiative ist »Open Device Lab« (http://opendevicelabs.com): Sie können dort nach öffentlich zugänglichen Testlaboren suchen und natürlich auch selbst Geräte spenden, die Sie nicht mehr benötigen. Besonders in größeren Städten können Sie dort fündig werden.

Die Alternative dazu lautet, sich ein eigenes kleines Device-Lab aufzubauen (»Own Device Lab«). Auf jeden Fall sollten Sie alte

GebrauchtmärkteAuch auf Gebrauchtmärk-ten wie eBay können Sie zu geringen Preisen fün-dig werden – auch, weil es für ein Device Lab überhaupt kein Problem darstellt, wenn das Dis-play eines Geräts ge-sprungen ist oder der Akku nicht mehr allzu lange durchhält. Achten Sie dabei auf eine sinn-volle Auswahl von Gerä-ten aller Preisklassen – auch einige exotische Kandidaten sollten dabei sein.

G Abbildung 9.7 Suche nach Open Device Labs im Raum Köln

G Abbildung 9.6 Destiny Montague und Lara Hogan haben mit »Building a Device Lab« ein ganzes Buch zum Thema kostenlos zur Ver-fügung gestellt (http://build-ingadevicelab.com).


447

Smartphones und Tablets nicht wegwerfen, sondern ihnen eine Zweitkarriere als Testgeräte spendieren.

Nun, da Sie mögliche Darstellungs- und UX-Probleme identi-fizieren können, taucht die nächste Frage auf: Wie kann ich dar-auf reagieren?

Feature-Unterstützung prüfen und reagieren

Ihr Ziel sollte sein, allen Nutzern eine positive User Experience zu ermöglichen. Statt einzelne Browser anzusprechen, konzentrieren sich Web-Entwickler eher darauf, welche Features unterstützt werden, und liefern alternative Stilangaben – wichtig ist, was ein Browser kann, nicht, wie er heißt.

Die wichtigste Plattform mit Informationen zur Browser-Unter-stützung ist »Can I use« (http://caniuse.com) – dort können Sie ein beliebiges Feature eingeben und die Unterstützung prüfen. Was aber macht man, wenn eine relevante Zahl von Besuchern noch mit alten Browser-Versionen unterwegs ist, die eine wich-tige CSS-Eigenschaft nicht unterstützen? Sie brauchen eine Mög-lichkeit, die unterstützten Features abzufragen.

Modernizr | Das Skript Modernizr wurde 2009 von Paul Irish, Faruk Ates, Alex Sexton, Ryan Seddon und Alexander Farkas ent-wickelt und hat sich seitdem als kleiner Helfer in vielen Projekten durchgesetzt. Das Skript wird heruntergeladen und im Head der HTML-Dokumente referenziert:

<script src="js/modernizr.js"></script>

G Listing 9.1 Einbindung von Modernizr in <head>

Modernizr überprüft anschließend automatisch beim Aufruf einer Seite, ob der Browser der Nutzerinnen moderne CSS-Features unterstützt. Wenn ja, fügt das Skript spezifische Klassen wie css-columns, border-radius oder box-shadow dem html-Element hinzu. Diese Klassen erlauben es dann, CSS-Eigenschaften nur dann zu spezifizieren, wenn sie auch unterstützt werden.

Ein Praxisbeispiel: Sie möchten ein Bild mit einem Text in einer ähnlichen Farbe überlagern und ihn mit einem Textschatten vom Hintergrund abheben (text-shadow: 2px 5px 10px black;).

Vendor PrefixesIn den letzten Jahren haben Browser neue CSS-Eigenschaften oft zu-nächst mit speziellen Vor-silben eingeführt, den sogenannten Vendor Pre-fixes. Die Idee war, dass Entwickler mit den neuen CSS-Eigenschaften expe-rimentieren konnten, al-lerdings bewegt sich der Trend von der Verwen-dung dieses Verfahrens weg. Hintergründe zu dieser Thematik erfahren Sie im Bonus-Beitrag »vendor-prefixes.pdf« im Download-Bereich.

G Abbildung 9.8 Modernizr erlaubt es, Brow-ser-Features zu erkennen und darauf zu reagieren.

Sie finden das Bei-spiel unter https://codepen.io/rohles/

pen/NdqYaY oder im Ordner Kapitel_09 • Modernizr – die Idee dazu lieferte Scott Jehl in »Responsible Respon-sive Web Design«.


448

Das sieht in Browsern mit Unterstützung für text-shadow gut aus – aber ohne dieses Feature wird der Text nahezu unsichtbar (etwa im IE 9):

In solchen Fällen ist Modernizr eine Lösung: Browser mit Unter-stützung für text-shadow können Sie mit der zusätzlichen Klasse .textshadow auf html gezielt ansprechen – allen anderen geben Sie eine alternative Textfarbe mit größerem Kontrast:

p { color: rgb(40, 36, 28); }

.textshadow p {

color: rgb(167, 100, 79);

text-shadow: 2px 5px 10px black;

}

G Listing 9.2 Browser mit Modernizr unterscheiden

Feature Queries mit @supports | Modernizr funktioniert gut, allerdings fühlt es sich komisch an, ein JavaScript auszuführen, um CSS-Eigenschaften zu erkennen. Eine Alternative ist die Erken-nung von CSS-Features in CSS selbst, die mit @supports möglich wird.

So können Sie beispielsweise prüfen, ob der Browser die CSS-Flexbox unterstützt, und sie erst dann aktivieren, wenn das der Fall ist – in allen anderen Fällen greifen alternative Regeln. Hier ist ein Beispiel, das ein responsives Raster auf Basis von Flexbox akti-viert, sofern diese Technologie unterstützt wird:

G Abbildung 9.9 Mit text-shadow in Ordnung …

G Abbildung 9.10 … ohne jedoch nicht.

G Abbildung 9.11 Sinnvoller Fallback für Brow-ser ohne text-shadow

Usability und Accessibility testen 9.2

449

.row { … } /* Standardangaben: Grid mit float… */

@supports ( display: flex ) {

.row { display: flex; } /* …Grid mit der Flexbox… */

}

G Listing 9.3 Erkennung von CSS-Features direkt in CSS

@supports erlaubt auch komplexere Abfragen mit den Operatoren AND, OR und NOT. Die Browser-Unterstützung für @supports ist bereits hoch, allerdings ist der Internet Explorer 11 noch ein gro-ßes Hindernis für die flächendeckende Verwendung. Selbstver-ständlich gibt es verschiedene Hilfsmittel, mit denen das Feature dank JavaScript auch in älteren Browsern ergänzt werden kann, etwa unter https://gist.github.com/codler/03a0995195aa2859465f, https://github.com/termi/CSS.supports oder unter https://github.com/kjarmicki/fq-polyfill.

Neben den rein technischen Browser-Tests sollten Sie auch an Ihre Nutzer denken: Sind Usability und Accessibility wirklich so gut wie geplant? Praktischerweise tun Sie mit den entsprechen-den Tests gewissermaßen »nebenbei« noch etwas für eine gute Auffindbarkeit Ihrer Website in den Suchmaschinen.

9.2 Usability und Accessibility testen

Zur Evaluation von Usability und Accessibility können Sie auf eine Reihe von Hilfsmitteln zurückgreifen. Außerdem können Sie mit fortlaufenden Tests für eine stetige Verbesserung sorgen.

Accessibility mit Tools testen

Automatisierte Tests können Sie mit einer Reihe von Werkzeugen durchführen. Ein sehr guter Vertreter dieser Gattung ist das Tool WAVE unter http://wave.webaim.org. Sie können es jedoch nur auf bereits veröffentlichte Websites anwenden, da Sie eine URL benötigen.

Nachdem Sie die URL in das Textfeld eingegeben haben, zeigt Ihnen WAVE eine Analyse möglicher Accessibility-Probleme an. Mit den Schaltflächen 1 können Sie die Website mit und ohne CSS anschauen. Der Bereich Summary 2 listet die gefundenen

Suchmaschinen-optimierungEine Einführung in die Suchmaschinenoptimie-rung finden Sie im Doku-ment »suchmaschinenop-timierung.pdf« im Download-Bereich.


450

Fehler nach Kategorie sortiert auf. Wichtig sind hier natürlich alle Angaben unter Errors, denn dabei handelt es sich um klare Feh-ler. Die anderen Bereiche sollten Sie genau prüfen, denn es han-delt sich um Hinweise auf häufige Fehlerquellen. Durch einen Klick auf eines der Symbole 3 erhalten Sie Details zu den prob-lematischen Aspekten. Die Kontrast-Fehler können Sie sehr gut analysieren, wenn Sie die Schaltfläche Contrast unter 1 wählen.

Eine weitere gute Möglichkeit ist die Arbeit mit Browser-Erwei-terungen wie den Chrome Accessibility Developer Tools (https://rohl.es/accessibility-toolbar-chrome). Damit lassen sich Accessibi-lity-Audits direkt im Browser durchführen. Natürlich kann ein Test wie dieser nicht alle Schwachstellen finden – er kann Ihnen zwar sagen, ob ein alt-Text bei einem Bild vorhanden ist, nicht aber, ob sein Inhalt für den Nutzer Sinn macht. Bei solchen Fragen hilft Ihnen eine manuelle Analyse.

Websites ohne CSS und Bilder analysieren

Ein praktisches Werkzeug für Ihren Google Chrome ist die Erwei-terung »Web Developer«, die Sie im Chrome Web Store unter https://chrome.google.com/webstore finden können. Nach der Ins-tallation können Sie damit Bilder und CSS mit einem Klick deak-tivieren.

Prüfen Sie nun, ob die Website noch sinnvoll nutzbar ist. Stimmt die Reihenfolge der Elemente? Geht auch ohne Design nichts Wesentliches an Inhalt verloren? Zudem können Sie die

Abbildung 9.12 H Analyse möglicher Accessibi-lity-Probleme mit WAVE

c

a

b

Lynx-BrowserAlternativ können Sie einen Text-Browser wie Lynx zum Testen verwen-den (http://lynx.invisible-island.net9.

Usability und Accessibility testen 9.2

451

Sprachausgabe Ihres Betriebssystems aktivieren und evaluieren, ob der Inhalt verständlich bleibt.

Analytics

Ein weiterer Tipp: Wenn Sie eine Analyse-Software wie beispiels-weise Google Analytics (www.google.com/analytics) verwenden, können Sie sehr genau erkennen, welche Bereiche Ihrer Web-site für die Nutzer interessant sind – und daran lassen sich oft Problemstellen finden, beispielsweise wenn in einem Shop nach dem Aufruf des Warenkorbs nicht gekauft, sondern abgebrochen wurde.

Usability überprüfen

Der wichtigste Faktor bei der Usability-Optimierung bleibt natür-lich der Nutzer selbst. Mit Usability-Tests können Sie Erkennt-nisse über das Verhalten Ihrer Nutzer auf der Website gewinnen – so etwas lässt sich auch ohne Probleme selbst durchführen. Der Tool-Anbieter UXPin hat mit »The Guide to Usability Testing« ein E-Book mit vielen Tipps zu diesem Thema veröffentlicht, das Sie unter https://www.uxpin.com/studio/ebooks/guide-to-usability- testing kostenlos (gegen eine E-Mail-Adresse) herunterladen können. Es enthält viele wissenswerte Informationen über unter-schiedlichste Testmethoden, deren Beschreibung den Rahmen dieses Buches bei Weitem sprengen würden.

Fortwährende TestsUsability ist ein fortwäh-rendes Thema für jeden Website-Betreiber: Sie müssen immer wieder daran feilen. Am besten nehmen Sie sich regelmä-ßig einige Minuten Zeit, um Ihre Website auf mögliche Schwachstellen zu überprüfen – das gilt insbesondere, wenn sich regelmäßig etwas an der Struktur verändert.

F Abbildung 9.13 Nur eine von vielen Möglich-keiten – beim »Usability Test-essen« werden Probanden zu Pizza und Bier eingeladen und liefern den Organisatoren im Austausch wertvolles Feed-back (http://usability-testes-sen.de).


452

Im Laufe der Zeit werden Sie außerdem Rückmeldungen von Ihren Nutzern erhalten – nehmen Sie deren Aussagen sehr ernst.

Eine Alternative können Remote-Usability-Tests sein, die online aus der Distanz durchgeführt werden können. Die Hürden sind hierbei geringer, weil Probanden zu Hause oder am Arbeits-platz teilnehmen können. Tipps für entsprechende Anbieter fin-den Sie im Dokument »quellen-lesetipps.pdf« im Download-Bereich.

Neben solchen Usability-Tests gibt es natürlich auch die Mög-lichkeit, eine Website mit kritischem Blick durchzugehen und selbst auf häufige Fehler zu achten. Man bezeichnet dies als heu-ristische Evaluation, weil sie sich an etablierten Usability-Prinzi-pien (den Heuristiken) orientiert. Im Laufe dieses Buches haben Sie zahlreiche dieser Prinzipien bereits kennengelernt. Der UX-Experte Joe Natoli hat unter https://rohl.es/natoli-ux-checkliste eine praktische Checkliste erstellt, die Sie als Einstieg in eine Überprüfung nutzen können.

HTML und CSS validieren

HTML und CSS folgen klaren Regeln, und hin und wieder macht jeder Webdesigner einen Fehler. Bei der Suche danach hilft ein sogenannter Validator, dessen Aufgabe es ist, den HTML-Quelltext nach kleinen Schnitzern zu durchsuchen. Für validen Code spre-chen zahlreiche Gründe, z. B. bessere Accessibility und Auffindbar-keit durch Suchmaschinen, konsistente Interpretation durch alle Browser sowie einfachere Wartbarkeit und Fehler suche.

Die offiziellen Validatoren des W3C für HTML (http://validator.w3.org) sowie CSS (https://jigsaw.w3.org/css-validator), der Living Validator (http://html5.validator.nu) oder Total Validator (www.totalvalidator.com) helfen Ihnen bei der Validierung. Den Quell-text zieht sich das Tool wahlweise per URL, Datei-Upload oder Direkteingabe. Nach kurzer Analyse erhalten Sie eine Übersicht von Fehlern.

Beachten Sie dabei: Validatoren sind Hilfsmittel, die typische Fehler wie falsche Verschachtelungen oder ungültige Elemente erkennen können. Sie liefern jedoch keine absoluten Wahrheiten – auch eine valide Seite kann unzugänglich oder unbenutzbar sein.

JSLintBei der Qualitätssiche-rung von JavaScript-Code kann beispielsweise JSLint (http://jslint.com) helfen.

Performance: Ladezeiten im Griff 9.3

453

9.3 Performance: Ladezeiten im Griff

Zu guter Usability und Accessibility gehören auch möglichst kurze Ladezeiten. Nutzer sind im Internet eher ungeduldig und haben wenig Verständnis für langsame Websites. Zum Glück gibt es einige Techniken, die Sie zur Reduzierung der Ladezeit einsetzen können. Performance ist daher ein fundamentaler Bestandteil der User Experience.

Performance als Design-Entscheidung

Um der immer weiter steigenden Bedeutung von Performance Rechnung zu tragen, hat der Web-Entwickler Tim Kadlec die Idee des Performance-Budgets vorgeschlagen. Dabei geht es darum, performance-relevante Messwerte möglichst früh im Projekt als zentrale Aspekte zu definieren – jede Design-Entscheidung hat Auswirkungen auf die Website-Performance. Damit vermeiden Sie, Performance nur ganz am Ende eines Projekts in den Blick zu nehmen, wenn viele relevante Entscheidungen bereits getroffen wurden.

In der Praxis kann das so aussehen, dass Sie einen festen Richt-wert festlegen, der nicht überschritten werden darf. Es gibt ver-schiedene Möglichkeiten, ein Performance-Budget zu definieren:

E basierend auf dem Browser: »Diese Seite soll die Gesamtgröße von 400 kB nicht überschreiten und maximal 15 Requests aus-führen.«

E basierend auf der User Experience: »Unsere Seite soll eine Ladezeit von unter 1,5 Sekunden (bei DSL 16.000) haben.«

E basierend auf dem Wettbewerb: »Unsere Seite soll 20 % schneller laden als die unserer Mitbewerber.«

Sinnvoll ist es auch, das Performance-Budget in kleinere Bau-steine zu unterteilen. So könnten Sie beispielsweise festlegen, dass alle eingesetzten Webfonts zusammen maximal 100 kB groß sein dürfen.

Der Vorteil eines Performance-Budgets liegt darin, dass Sie die Auswirkungen von Design- und Content-Entscheidungen auf die Performance möglichst früh diskutieren können. Soll auf einer Seite ein neues Feature eingebaut werden (z. B. ein weiteres

Auswirkungen guter PerformanceUnter https://wpostats.com finden Sie zahlreiche Statistiken zur Bedeutung guter Website-Perfor-mance. Onlineshopper erwarten beispielsweise, dass eine Seite in zwei Sekunden geladen ist – bereits nach drei Sekun-den brechen viele von ihnen den Vorgang ab.

Mobile PerformanceMobile Verbindungsge-schwindigkeiten variieren sehr stark in unterschied-lichen Regionen – und das wird auch noch eine Weile so bleiben (www.ericsson.com/assets/ local/mobility-report/documents/ 2016/ericsson-mobility-report-november- 2016.pdf).


454

Carousel), das die festgelegte Grenze überschreitet, muss opti-miert werden oder ein anderes Feature weichen. Damit wirken Sie dem Phänomen des »Feature Creep« entgegen: Im Laufe der Zeit werden immer wieder neue Funktionen eingeführt – nach und nach geht damit die Performance in den Keller.

Eine Frage des Protokolls

Natürlich gibt es eine Vielzahl weiterer Maßnahmen zur Verbes-serung der Performance. Welche davon geeignet sind, hängt stark davon ab, welches Übertragungsprotokoll verwendet wird.

Wenn Sie im Browser eine Website aufrufen, werden alle Daten über das Protokoll HTTP (»Hypertext Transfer Protocol«) über-tragen. HTTP/1.1 ist seit vielen Jahren zuverlässig im Einsatz, hat allerdings aus heutiger Sicht seine Tücken. Der im Mai 2015 ver-abschiedete Nachfolger HTTP/2 möchte mit diesen Begrenzun-gen aufräumen. So kann der Server Dateien aktiv an den Brow-ser schicken, statt darauf zu warten, dass der Browser die Dateien selbst anfordert. Besonders wichtig ist auch die Multiplex-Über-tragung, bei der mehrere Dateien mit einer Verbindung übertra-gen werden, statt jedes Mal eine neue Verbindung aufzubauen. Konkret heißt das: Während Sie bei HTTP/1.1 versuchen sollten, möglichst wenige Requests auszuführen, profitiert HTTP/2 eher davon, Ressourcen in verschiedene Dateien aufzuspalten.

In den folgenden Abschnitten werde ich mich auf Verfahren konzentrieren, die besonders beim älteren HTTP/1.1-Protokoll sinnvoll sind – es ist derzeit noch vorherrschend. Bedenken Sie jedoch, dass eine Optimierung für HTTP/2 anders aussieht. Wei-

AutomatisierenWenn Sie die Auslastung Ihres Performance-Bud-gets nicht immer wieder selbst nachrechnen möchten, hat Tim Kadlec unter https://timkadlec.com/2014/05/perfor-mance-budgeting-with-grunt eine Möglichkeit beschrieben, den Prozess mit Hilfe des Tools Grunt zu automatisieren.

Abbildung 9.14 E Trotz seines jungen Alters unterstützen bereits zahlrei-che Browser HTTP/2 (http://caniuse.com/#feat=http2).


455

terführende Artikel dazu finden Sie im Dokument »quellen-lese-tipps.pdf« im Download-Bereich.

Speed-Tests nutzen

Google bietet mit Page Speed ein Werkzeug an, das Tipps zur Optimierung gibt. Sie erreichen es unter https://developers.google.com/speed/pagespeed/insights. Eine weitere Möglichkeit ist die Browser-Erweiterung YSlow von Yahoo (http://yslow.org). Beide Tools geben Ihnen neben Anhaltspunkten in Form von Noten auch ganz konkrete Empfehlungen.

Empfehlenswert ist außerdem der »Service Web Page Test« (www.webpagetest.org), der die effektive Ladezeit einer Website misst und mit einem Diagramm die Ladereihenfolge und -dauer verschiedener Ressourcen darstellt. Ein Blick in die Dokumenta-tion (https://sites.google.com/a/webpagetest.org/docs/using-web-pagetest/quick-start-quide) lohnt sich, denn Web Page Test ist ein sehr mächtiges Werkzeug für die Performance-Analyse.

Ungenutzten Code entfernen

Ein erster Schritt bei der Performance-Optimierung von Websites ist, unnötigen Datenballast zu entfernen. Dazu zählt, den Quell-text zu überprüfen und aufzuräumen sowie die Dateigröße selbst zu reduzieren.

Während der Entwicklung sowie im Livebetrieb schleicht sich immer mal wieder Code ein, der später nicht mehr genutzt wird

Unterstützung von HTTP/2 prüfenHTTP/2 erfreut sich be-reits jetzt einer hohen Unterstützung durch Browser und ist stark auf dem Vormarsch. Für die Nutzung des Protokolls ist es notwendig, die pas-sende Server-Version bzw. das passende Ser-ver-Modul zu installieren und zu konfigurieren. Sprechen Sie diesbezüg-lich mit Ihrem Hosting-Provider. KeyCDN hat unter https://tools.key-cdn.com/http2-test ein Tool online gestellt, das HTTP/2-Unterstützung prüft.

F Abbildung 9.15 Google Page Speed


456

und entfernt werden kann. Mit Tools wie »Unused CSS« (https://unused-css.com, kostenpflichtig) oder der Firefox-Erweiterung »Dust-Me« (https://addons.mozilla.org/de/firefox/addon/dust-me-selectors) lässt sich das CSS auf ungenutzte Selektoren und Anga-ben untersuchen. Auch im Hinblick auf JavaScript sowie Erwei-terungen von Content-Management-Systemen sollten Sie die Performance im Auge behalten und nur verwenden, was wirklich notwendig ist.

Requests reduzieren

Wie erwähnt, ist die Reduzierung der Anzahl von HTTP-Requests sehr wichtig, wenn das HTTP/1.1-Protokoll verwendet wird. Dazu gibt es einige Maßnahmen.

Schmuckbilder mit CSS-Sprites optimieren | Stellen Sie sich vor, Sie haben auf einer Website viele kleine Icons sowie einige Hinter-grund-Grafiken, die oft wiederholt werden. Für jede dieser Grafi-ken muss der Browser eine Anfrage schicken und die Datei einzeln herunterladen. Das ist nicht gerade effektiv.

CSS-Sprites können dafür eine Lösung sein. Sie machen sich background-position zunutze. Das Prinzip beruht darauf, alle Grafiken in einer einzigen Datei zusammenzufassen und dann mittels background-position zu verschieben, bis nur noch die gewünschten Teile zu sehen sind. Das kann beispielsweise so aus-sehen:

.sprite1 {

background:url('css-sprite.jpg) no-repeat;

background-position: 0 0;

}

.sprite2 {

background:url('css-sprite.jpg) no-repeat;

background-position: 0 -100px;

}

CSS-Sprites können sehr komplex werden, wenn Sie viele schmü-ckende Grafiken verwenden. Ein sehr gutes Hilfsmittel ist der CSS Sprite Generator unter http://csssprites.com.

G Abbildung 9.16 CSS-Sprite von YouTube

Sie finden das Bei-spiel unter https://codepen.io/rohles/

pen/GrgOrv oder im Ordner Kapitel_09 • CSS-Sprites.

Listing 9.4 E Beide Grafiken wurden in einer CSS-Sprite zusammen-gefasst.


457

Requests mit Data-URIs reduzieren | Eine weitere Möglichkeit zum Einsparen von HTTP-Requests ist die Arbeit mit Data-URIs. Das lässt sich beispielsweise bei Grafiken oder Webfonts nutzen.Dabei werden die Grafiken nicht im CSS oder HTML referenziert, sondern direkt dort eingebettet – und zwar in einer Base64-codierten Form. Diese Zeichenketten sind extrem lang und unübersichtlich:

<img width="100" height="200" alt="Flugzeug beim Start"

src="data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAGQAAAD

ICAYAAAAePET[…]" />

G Listing 9.5 Data-URI als src

Die Syntax einer Data-URI startet stets mit data:. Es folgen Anga-ben zu Dateityp und Codierung, schließlich ein Komma und die Rohdaten des Bildes. Bei der Konvertierung helfen die Online-Tools unter http://websemantics.co.uk/online_tools/image_to_data_uri_convertor, http://dataurl.net oder https://boazsender.git-hub.io/datauri.

Data-URIs geben Ihrer Website einen Performance-Boost, haben jedoch auch eine Reihe von Nachteilen:

E Die Arbeit mit ihnen ist unübersichtlich, da im Quelltext sehr lange Zeichenketten auftauchen.

E Außerdem ist es nun wesentlich aufwendiger, ein Bild auszu-tauschen – statt es per FTP einfach zu überschreiben, muss es neu codiert und an allen referenzierten Stellen ausgetauscht werden.

F Abbildung 9.17 CSS Sprite Generator

Tipp für Nutzer von CSS-PräprozessorenEin CSS-Präprozessor wie Sass kann Ihnen bei der Arbeit mit Data-URIs sehr behilflich sein, beispiels-weise die Funktion in-line-image() für Com-pass mit Sass: http://compass-style.org/refe-rence/compass/helpers/in-line-data.


458

E Data-URIs sparen Requests, sind aber auch oft etwas größer als die Ursprungsdateien. Hier hilft Komprimierung mit gzip.

E Ihre Verwendung sollte mit gutem Caching verbunden wer-den: Wenn Data-URIs beispielsweise im CSS eingebunden sind, vergrößert sich dadurch das Dokument und dessen Lade-zeit – das CSS wird daher erst später ausgewertet. Hier hilft es also, das CSS für spätere Verwendung großzügig zu cachen.

Skripte und CSS-Dateien zusammenfassen und minimieren | Während der Entwicklung und zur Wartung hat die Aufteilung

von Skripten und CSS in mehrere Dateien große Vorteile – das ist

viel übersichtlicher, vereinfacht die Zusammenarbeit im Team und

erlaubt flexiblere Arbeitsweisen. Häufig bringen auch das CMS

selbst sowie diverse Erweiterungen eigene Skript- und CSS-Dateien

mit. Hinzu kommen externe Bibliotheken und Services, etwa Biblio-

theken wie jQuery oder Share-Buttons für Facebook und Co.

Schnell kommen auf diese Weise Dutzende Requests zusam-men, die eine Website verlangsamen können. Im Livebetrieb ist es daher besser, wenn die Angaben in eine einzige Datei hineinko-piert werden. Achten Sie dabei auf die richtige Reihenfolge, damit nicht aus Versehen eine wichtige Angabe überschrieben wird.

Neben dem Zusammenfassen können die Dateien auch noch minimiert werden. Dabei werden Leerzeichen, Absätze und Kom-mentare entfernt – das Ergebnis ist eine spürbare Reduzierung der Dateigröße. In jedem Fall sollten Sie jedoch eine nicht mini-mierte Kopie der Dateien aufheben, denn die minimierten Versio-nen sind zu unübersichtlich, um mit ihnen zu entwickeln.

Share-ButtonsAuch die so beliebten Share-Buttons sind bis-weilen eine Performance-Bremse – zudem kommu-nizieren sie auch dann mit ihren Servern, wenn ein Nutzer gar nicht dar-auf geklickt hat. Shariff von Heise kann daher eine Lösung sein (https://github.com/heiseonline/shariff), denn hier werden die Buttons nur auf An-forderung aktiviert.

Abbildung 9.18 E Kaum zu lesen, aber deutlich kleiner – das Ergebnis des JavaScript-Minifier


459

Manuell ist dieser Prozess natürlich ein sehr hoher Aufwand. Zum Glück gibt es jedoch Helfer wie den Minifier (www.minifier.org), die diese Aufgabe übernehmen können. Weitere Tool-Tipps finden Sie im Dokument »quellen-lesetipps.pdf« im Download-Bereich.

Dateigröße optimieren

Ein weiteres Ziel ist, die Größe einer Website so klein wie möglich zu machen – wenn weniger übertragen werden muss, wirkt sich dies ebenfalls positiv auf die Performance aus. In den vorherigen Abschnitten haben Sie bereits einige Maßnahmen zur Reduzie-rung der Größe kennengelernt. Es gibt aber noch weitere Mög-lichkeiten.

Daten komprimieren | Mit dem Komprimierungsverfahren gzip steht eine Technologie zur Verfügung, mit der im Schnitt 70 % der Daten eingespart werden können. Das Verfahren greift besonders bei Texten und spart einiges an Zeichen, indem auf bereits vor-handene Informationen verwiesen wird, statt sie erneut zu über-tragen. Gzip ist ein verlustfreies Verfahren und wird von allen modernen Browsern verstanden.

Der Aufwand ist erfreulich gering: Ob gzip auf Ihrem Ser-ver funktioniert, können Sie mit www.gziptest.com ausprobie-ren. Wenn Ihre Website auf einem Apache-Server läuft (das ist meistens der Fall), lässt es sich sehr einfach mit einer Anpassung der ».htaccess«-Datei aktivieren – dabei handelt es sich um eine Konfigurationsdatei des Servers. Es gibt zwei Module (mod_gzip und mod_deflate), die sich dazu eignen – beide hat Patrick Sexton unter https://varvy.com/pagespeed/enable-compression.html mit den erforderlichen Code-Schnipseln erläutert. Der Artikel enthält außerdem die Anweisungen für Server mit nginx und Litespeed. Im Zweifel hilft Ihnen der Administrator Ihres Hosting-Anbieters sicher gerne weiter.

Caching | Trotz aller Optimierungsmaßnahmen ist es immer noch mühsam, Dateien immer wieder neu laden zu müssen, wenn sie mehrmals benötigt werden. So werden beim Aufruf der Home-page beispielsweise viele Dateien geladen, die auch auf Untersei-

Daten-KostenAuf https://whatdoesmy-sitecost.com erhalten Sie eine Einschätzung, was der Aufruf einer Website in verschiedenen Ländern der Welt kostet (in $).

BeispielGregor Meier bringt in seinem Buch »Pagespeed Optimierung« (Hanser, 2016) folgendes einfache Beispiel: Aus dem Satz »Auch ein kleiner Beitrag ist ein Beitrag« kann durch Komprimierung der Satz »Auch ein klei-ner Beitrag ist -4 -3« wer-den. Statt schon einmal genannte Wörter zu wie-derholen, wird also nur noch auf ihre Position verwiesen – das spart selbst in diesem einfa-chen Beispiel schon sie-ben Zeichen.


460

ten benötigt werden. Auch gibt es Dateien, die sich nicht verän-dert haben, wenn eine Besucherin einige Tage später erneut auf einer Website landet. In Fällen wie diesen kommt der Browser-Cache zum Einsatz. Hier landen Inhalte im lokalen System und werden von dort genutzt, statt sie erneut vom Server anzufragen. Moderne Browser cachen Inhalte automatisch, allerdings können Web-Entwickler ein bisschen nachhelfen. Man kann dem Brow-ser nämlich einen Richtwert mitgeben, wie lange die einzelnen Inhalte im lokalen Speicher gültig sein sollen.

Diese Richtwerte werden auf einem Apache-Server in die ».htaccess«-Datei geschrieben. Dateien, die sich selten ändern, werden mit langen Werten versehen (etwa 1 month oder 1 year), andere Dateitypen wie HTML werden nicht gecacht. Das kann so aussehen:

<IfModule mod_expires.c>

ExpiresActive On

ExpiresByType image/gif "access plus 1 year"

ExpiresByType image/png "access plus 1 year"

ExpiresByType image/jpeg "access plus 1 year"

ExpiresByType text/css "access plus 1 year"

ExpiresByType text/javascript "access plus 1 year"

ExpiresByType application/javascript "access plus 1

year"

ExpiresByType application/x-javascript "access plus 1

year"

</IfModule>

Nach Ablauf der angegebenen Zeitdauer würde ein Browser die Datei erneut anfordern. Die Anweisungen funktionieren nur, wenn das Modul Expires aktiviert ist – sprechen Sie im Zweifel mit Ihrem Hosting-Provider. Nachdem Sie diese Angaben in die ».htaccess« Ihres Servers geschrieben haben, können Sie mit Google Page Speed prüfen, ob der Browser-Cache aktiv ist.

Falls Sie nach Aktivierung des Browser-Caches doch noch ein-mal etwas an den Dateien ändern möchten, können Sie eine Ver-sionsnummer an den Dateinamen (Fingerprinting, z. B. »image_v1.png«) oder als Parameter an die URL anhängen (z. B. »image.png?v=1«). Damit weiß der Browser Ihrer Besucher, dass er die neue Version herunterladen soll.

Server-CacheAuch der Server selbst verfügt über einen Cache, in dem er häufig benötig-te Dateien ablegen kann. Dies ist besonders bei dy-namisch erzeugten Web-seiten sinnvoll. Viele Content-Management-Systeme bieten entweder von Haus aus oder mit-tels Erweiterungen (etwa dem »WP Super Cache« für WordPress) die Mög-lichkeit, den Server-Cache zu aktivieren. Zudem gibt es spezielle Caching-Server wie bei-spielsweise Varnish.

Listing 9.6 E Angaben zum Browser-Caching in der ».htaccess«


461

Webseiten so schnell wie möglich rendern

Mit performance-orientiertem Design, Reduzierung der Requests und Optimierung der Dateigröße haben Sie wichtige Schritte für eine gute Performance unternommen. Trotz allem wird jedoch noch immer etwas heruntergeladen. Aber auch während dieser Ladezeit können Sie die User Experience Ihrer Besucher opti-mieren.

Ein Crashkurs über das Rendering von Webseiten | Zunächst lohnt sich ein kurzer Abstecher in die Funktionsweise eines Brow-sers. Wie kommt ein Browser von dem Code, den Sie auf einem Server ablegen, dazu, eine fertige Webseite anzuzeigen?

E Beim Aufruf einer URL empfängt der Browser zunächst ein HTML-Dokument.

E Aus diesem HTML muss er nun etwas konstruieren, das er auf dem Bildschirm anzeigen kann. Dazu muss er den Quelltext interpretieren und in das Document Object Model (DOM) umwandeln. Der Begriff beschreibt, was der Browser aus Ihrem Quellcode herausinterpretiert – er wird beispielsweise bei einem Fehler versuchen, den Quelltext in sinnvoller Weise zu ergänzen. Das DOM enthält den gesamten Inhalt der Seite. Je einfacher Ihr Quelltext strukturiert ist, desto schneller ist der Browser mit dem Interpretieren. Das ist der Grund, warum Sie einfaches Markup mit möglichst wenigen Verschachtelun-gen bevorzugen sollten – es steigert die Performance.

E Noch kann der Browser den Inhalt jedoch nicht auf dem Bild-schirm anzeigen – er weiß ja noch gar nicht, wie er aussehen soll. Daher lädt er das CSS herunter (sofern vorhanden), inter-pretiert es und erstellt ein weiteres Modell: das CSS Object

H Abbildung 9.19 Rendering-Prozess des Browsers

DOM

JavaScript

CSS CSSOM

Render Tree Layout Darstellung

HTML


462

Model (CSSOM). Erst wenn das gesamte CSS verarbeitet wurde, kann der Browser überhaupt daran denken, irgendet-was auf dem Bildschirm anzuzeigen. Daher bezeichnet man CSS auch als render-blocking – die Anzeige von Inhalten wird so lange blockiert, bis das CSS abgearbeitet wurde. Auch hier gilt daher: Je kompakter und einfacher das CSS ist, desto schneller kann der Browser es verstehen. Verschachteln Sie Ihre CSS-Selektoren also nicht stärker als notwendig.

E Content ist da, Gestaltung ist da – reicht das aus, um eine Webseite darzustellen? Noch nicht, denn zuerst muss der Ren-der-Tree erstellt werden. DOM und CSSOM enthalten nämlich noch Inhalte, die gar nicht sichtbar sind – meta-Angaben im HTML oder mit CSS ausgeblendete Inhalte beispielsweise.

E Schließlich erzeugt der Browser das Layout, indem er die Grö-ßenverhältnisse errechnet. Ein article mit width: 50% würde beispielsweise bei einem 320 px-Viewport 160 px groß sein, auf einem 1200 px-Viewport jedoch 600 px.

E Mit diesen Informationen hat der Browser alles, was er zur Anzeige einer Webseite benötigt. Ein Browser durchläuft diese Schritte jedoch mehrmals. So muss er beispielsweise das Lay-out neu aufbauen, wenn ein Nutzer scrollt.

JavaScript verändert diesen Prozess ein wenig: Sie können damit Inhalte erzeugen oder auch die Anzeige von Elementen steuern – JavaScript kann also sowohl das DOM als auch das CSSOM ver-ändern. Nehmen wir einmal an, ein Browser hat ein HTML-Doku-ment gefunden und beginnt damit, das DOM zu konstruieren. Irgendwo entdeckt er ein JavaScript. Was muss er tun?

E Ohne das Skript zu kennen, kann der Browser nicht wissen, ob es das DOM verändern möchte, das er gerade konstruiert. Also muss er mit der Konstruktion des DOMs aufhören, das Skript herunterladen (sofern es in einer externen Datei liegt) und interpretieren, bevor er fortfahren kann.

E JavaScript ist also parser-blocking, weil es die Konstruktion des DOMs verzögert.

E Gleichzeitig kann der Browser das JavaScript nicht ausfüh-ren, bevor er auch das CSSOM aufgebaut hat – es könnte ja genauso gut sein, dass mit dem Skript die Darstellung beein-flusst werden soll.


463

Kritisches CSS auslagern | Aus diesem Rendering-Verhalten erge-ben sich einige Optimierungsmöglichkeiten, beispielsweise die Arbeit mit kritischem CSS. Huch, kritisches CSS? Was ist das? Man versteht darunter alle CSS-Angaben, die für die unmittelbar beim Aufruf einer Seite sichtbaren Inhalte benötigt werden. Ein Blick in das Verhalten eines Browsers beim Aufruf einer Website verdeutlicht das Verfahren:

E Externe Stylesheets blockieren die Anzeige von Inhalten (render-blocking). Der Browser lädt also zunächst die HTML-Dateien und fordert dann die Stylesheets an – er zeigt jedoch noch keine Inhalte, bis er mit dem Herunterladen der Stilan-gaben fertig ist.

E Prinzipiell ist dieses Vorgehen sinnvoll, denn schließlich wüsste der Browser zwar, was er zeigen soll, aber noch nicht, wie. Gerade bei komplexen Stylesheets verlängert sich die Warte-zeit jedoch deutlich, besonders in Mobilfunknetzen.

E Die Idee von »kritischem CSS« ist nun, das CSS in zwei Teile aufzusplitten: alles, was für die direkt sichtbaren Inhalte not-wendig ist, sowie alles andere.

Das klingt an dieser Stelle seltsam – haben wir unsere CSS-Dateien nicht gerade erst zusammengefügt, um weniger Requests zu erzeugen? Ja, genau – und deshalb soll das kritische CSS als style-Block direkt in die HTML-Seiten hineingeschrieben wer-den, während das übrige CSS wie gewohnt über eine externe Datei nachgeladen wird. Die Idee dahinter: Es gibt keinen Grund, warum ein Nutzer auf Style-Angaben warten sollte, wenn er sie sowieso noch nicht sehen kann. Der Browser kann somit schon früher mit dem Rendern des oberen Contents beginnen und dann alles andere nachladen.

Prinzipiell sieht das Vorgehen so aus:

<!doctype html>

<head>

<style> /* kritisches CSS inline */ </style>

<script> loadCSS("pfad/zu/nichtkritischen/styles.css");

</script>

</head>

<body>...</body>

</html>

kritisches CSS

nicht-kritischesCSS

G Abbildung 9.20 Kritisch ist CSS immer dann, wenn es für die Anzeige im aktuellen Viewport notwen-dig ist (www.amazeelabs.com/de) – diese Stile sollten so schnell wie möglich bereit-stehen.

F Listing 9.7 Prinzip des kritischen CSS


464

Manuell ist das sehr aufwendig: Sie müssten sich Ihre Website bei verschiedenen Viewport-Größen anschauen und alle CSS-Angaben identifizieren, die für den sichtbaren Bereich nötig sind. Anschließend kopieren Sie diese aus der CSS-Datei direkt ins HTML. Glücklicherweise hat Jonas Ohlsson mit dem »Critical Path CSS Generator« ein Tool entworfen, das dies übernimmt. Dazu geben Sie zunächst unter 1 die URL der Webseite ein und kopieren anschließend unter 3 das gesamte CSS hinein. Ein Klick auf den Button 2 extrahiert nun die kritischen Stilangaben. Diese kopieren Sie anschließend in den <head> Ihrer Webseite, während das übrige CSS asynchron geladen wird. Dieses Beispiel verwen-det dazu das JavaScript »loadCSS«, das unter https://github.com/filamentgroup/loadCSS ausführlich dokumentiert ist. Anschließend heißt es Testen, Testen, ob das Tool alles richtig erkannt hat.

Natürlich müssten Sie diesen Schritt für jede Seite und bei jeder Änderung wiederholen. In der Praxis arbeiten Entwickler daher meist mit Automatisierungstools wie beispielsweise:

E https://github.com/addyosmani/critical E https://github.com/filamentgroup/criticalCSS E https://github.com/pocketjoso/penthouse

JavaScript asynchron laden | Auch JavaScript blockiert den Brow-ser dabei, das DOM aufzubauen. Um das zu vermeiden, sollten JavaScript-Dateien entweder ganz unten im Quelltext (vor dem schließenden </body>) eingebunden oder asynchron geladen werden:

Tipp: Lieber doppelte Angaben behaltenTheoretisch könnten Sie das kritische CSS aus der externen Datei entfernen, sobald es im <head> der HTML-Datei unterge-bracht ist. Ich rate Ihnen jedoch, eher davon abzu-sehen, denn die Wartbar-keit würde darunter doch arg leiden, und die Er-sparnis in der Dateigröße wäre selten groß.

Abbildung 9.21 E Critical Path CSS Generator (https://jonassebastianohlsson.com/criticalpathcssgenerator)

a

3

2

Tipp für Server-AdministratorenGoogle Page Speed bietet zudem Module an, die auf einem Server instal-liert werden können (https://developers.google.com/speed/pagespeed/module/?csw=1).


465

<script src="analytics.js" async></script>

G Listing 9.8 Asynchrones Laden von JavaScript

Das async-Attribut sorgt dafür, dass JavaScript die Konstruktion des DOMs nicht mehr blockiert – der Browser fährt mit dem Auf-bau des DOMs fort, während er das Skript herunterlädt. async garantiert jedoch nicht, dass das DOM auch fertig aufgebaut ist, wenn das Skript ausgeführt wird – es könnte also sein, dass das Skript etwas verändern möchte, von dem der Browser noch gar nichts weiß. Sollte das Skript also auf das DOM zugreifen wol-len, können Sie es mit dem defer-Attribut versehen (statt async) – der Browser lädt es nun parallel zur Konstruktion des DOMs herunter, führt es jedoch erst aus, nachdem das Dokument auf-gebaut wurde.

Lazy Loading | Schließlich gibt es »Lazy Loading«. Bei diesem Ver-fahren lädt ein Browser Ressourcen nicht direkt beim Aufruf der Seite, sondern erst, wenn sie auch tatsächlich benötigt werden. Das wird bei Bildern häufig eingesetzt, die außerhalb des gerade sichtbaren Bereichs des Viewports angezeigt werden.

Es gibt verschiedene Möglichkeiten der Umsetzung. Eine sehr gute Lösung ist das Skript »lazysizes« von Alexander Far-kas (https://github.com/aFarkas/lazysizes). Dort findet sich eine umfangreiche Dokumentation mit Anwendungsbeispielen. Prin-zipiell sieht das Procedere so aus:

E Laden Sie das Skript herunter, und binden Sie es in die Web-seite ein.

E Anstelle der in Kapitel 8 erläuterten Attribute setzen Sie nun die alternativen Attribute data-src und data-srcset inner-halb des img-Elements ein. Lazysizes kümmert sich automa-tisch um das Laden der entsprechenden Grafiken, sobald sich die Scrollposition den Bildern nähert. Bei responsiven Bildern sieht das beispielsweise so aus:

<img data-sizes="auto" alt="…" data-src="image2.jpg" data-

srcset="image1.jpg 300w, image2.jpg 600w, image3.jpg 900w"

class="lazyload" />

G Listing 9.9 Einbindung von Bildern mit dem data-src-Attribut

Alternativen zur UmsetzungNatürlich gibt es viele weitere Möglichkeiten, Lazy Loading umzuset-zen. Einige bekannte Bei-spiele sind:

E Unveil von Luis Almei-da (https://luis-almeida.github.io/unveil)

E Lazy Load von Mika Tuupola (http://www.appelsiini.net/projects/lazyload)

E ImageLoader aus der YUI-Bibliothek (http://yuilibrary.com/yui/docs/imageloader)

Praktische ChecklistePerformance-Optimie-rung ist ein riesiges Feld. Viele weitere Tipps hat Vitaly Friedman in einer Performance-Checkliste (www.smashingmagazine.com/2016/12/front-end-performance-checklist-2017-pdf-pages) zusam-mengetragen.


466

E Deaktiviertes JavaScript kann unterstützt werden, indem das img-Element in einem noscript-Block wiederholt wird:

<noscript>

<img src="image.jpg" alt="…"/>

</noscript>

G Listing 9.10 Fallback bei deaktiviertem JavaScript

Mit dem Performance-Aspekt haben Sie nun das letzte Puzzle-Stück in der Hand, das Sie für ein richtig gutes Webdesign benö-tigen. Im folgenden Kapitel haben Sie die Möglichkeit, alle bisher gelernten Aspekte im Zusammenhang zu erleben – es soll Ihnen helfen, einen Einstieg in Ihre eigene Gestaltung zu finden.

Sonderformate für größere PerformanceSpeziell für Optimierun-gen im mobilen Netz sind in den letzten Monaten einige Sonderformate entstanden, beispielswei-se Googles AMP-Techno-logie. Eine kurze Einfüh-rung mit weiteren Lesetipps finden Sie im Dokument »sonderfor-mate-performance.pdf« im Download-Bereich.

Documents

Wie Sie die Qualität einer Website sichern · 9 Testen und optimieren 444 Außerdem erlaubt der Internet Explorer ab Version 9, eine Web-site in früheren Versionen des Browsers