Vorheriger Artikel Nächster Artikel

7 Tipps für schnellere Websites: So lässt sich die Wartezeit reduzieren

Aus dem
t3n Magazin Nr. 41

09/2015 - 11/2015

Jetzt kaufen
7 Tipps für schnellere Websites: So lässt sich die Wartezeit reduzieren

Grafik: Ajgul / Shutterstock

Ein schneller Seitenaufbau hat einen erheblichen Anteil an einer guten User-Experience. Dennoch fehlt bei vielen Webentwicklern oder Agenturen das technische Verständnis für einfache Optimierungsmaßnahmen. Wir stellen sieben Methoden vor, mit denen sich die Ladezeit einer Website teilweise drastisch reduzieren lässt.

1. Das Browser-Caching verbessern

In der Regel besteht eine Website aus vielen Elementen, die nicht nur einmalig, sondern gleich auf mehreren Seiten verwendet werden – beispielsweise die Logo-Grafik, übergreifende CSS-Anweisungen oder auch wiederkehrende JavaScript-Dateien. Damit diese nicht immer wieder neu vom Server angefordert werden müssen, besitzt jeder Browser eine Caching-Funktionalität zum Zwischenspeichern von Dateien auf der lokalen Festplatte.

Von Haus aus ist der Browser-Cache allerdings relativ dumm. Dies ist auch kein Wunder, da er ja nicht wissen kann, wie oft eine Datei auf dem Server geändert wird. Im Falle einer dynamischen Web-Anwendung wie Facebook würde es beispielsweise keinen Sinn machen, HTML-Dateien im Cache abzulegen. Anders sähe es bei einer kleinen statischen Info-Webseite aus, auf der sich die Inhalte nur alle paar Monate minimal ändern. Es liegt also in der Verantwortung des Webentwicklers, sämtlichen Dateien ein passendes Ablaufdatum zu vergeben.

Läuft die eigene Website auf einem Apache-Webserver, lässt sich das Browser-Caching in der .htaccess-Datei definieren. Über den Mime-Type kann für jede Dateiart ein Cache-Zeitraum festgelegt werden.

.htaccess

<IfModule mod_expires.c>
ExpiresActive On
ExpiresByType text/html "access plus 1 second"
ExpiresByType text/css "access plus 2 weeks"
ExpiresByType text/javascript "access plus 2 weeks"
ExpiresByType image/jpg "access plus 3 weeks"
ExpiresByType image/png "access plus 3 weeks"
# ...
</IfModule>

Listing 1

In diesem Fall würden HTML-Dateien lediglich eine Sekunde zwischengespeichert werden. CSS- und JavaScript-Dateien blieben zwei Wochen im Cache und Bilder (jpg, png) sogar drei Wochen. Google-PageSpeed-Insights empfiehlt übrigens für statische Ressourcen mindestens eine Haltbarkeit von einer Woche.

2. Dateien automatisch komprimieren

Jeder Webworker wird schon mal mit einem ZIP-Archiv gearbeitet haben. Dieses kann nicht nur mehrere Dateien zusammenführen, sondern wendet auch einen mehr oder weniger komplexen Kompressions-Algorithmus an, um die Größe der ZIP-Datei zu reduzieren. Vereinfacht gesagt, wird bei der Kompression nach wiederkehrenden Zeichenketten gesucht, welche dann in Variablen abgespeichert werden. Je mehr redundante Textmuster in einer Datei existieren, umso größer ist daher die Ersparnis. Deshalb eignen sich HTML-, JavaScript- und vor allem CSS-Dateien auch hervorragend für eine Kompression.

Genau wie bei der Konfiguration des Browser-Caching lässt sich eine serverseitige Komprimierung von statischen Ressourcen über die .htaccess-Datei des Webservers realisieren. Dabei kommen die Apache-Module mod_deflate oder mod_gzip in Frage.

.htaccess

<IfModule mod_deflate.c>
  AddOutputFilterByType DEFLATE text/html
  AddOutputFilterByType DEFLATE text/css
  AddOutputFilterByType DEFLATE text/javascript
  # ...
</IfModule>

<IfModule mod_gzip.c>
  mod_gzip_on       Yes
  mod_gzip_dechunk  Yes
  mod_gzip_item_include file      \.(html?|txt|css|js|php|pl)$
  mod_gzip_item_include handler   ^cgi-script$
  mod_gzip_item_include mime      ^text/.*
  mod_gzip_item_include mime      ^application/x-javascript.*
  mod_gzip_item_exclude mime      ^image/.*
  mod_gzip_item_exclude rspheader ^Content-Encoding:.*gzip.*
</IfModule>

Listing 2

In diesem Beispiel werden HTML-, CSS- und JavaScript-Dateien automatisch vom Server komprimiert und an den Browser geschickt. Dateiformate wie .jpg, .png oder .woff, die bereits komprimiert sind, sollten von der serverseitigen Kompression ausgeschlossen werden.

3. Bilder und Grafiken optimieren

Laut httparchive.org waren 2014 durchschnittlich über 50 Bilder oder Grafiken auf jeder einzelnen Webseite eingebunden. Die durch Bilder zu übertragende Dateimenge legte im Vergleich zum Vorjahr sogar um mehr als 20 Prozent zu. Im Zuge einer Pagespeed-Optimierung ist es dementsprechend enorm wichtig, Bild-Dateien so stark wie möglich zu komprimieren.

Dabei unterscheidet man generell zwischen der verlustfreien (lossless) und der verlustbehafteten (lossy) Komprimierung. Erstere entfernt nicht benötigte Meta-Informationen, identische Bildabschnitte werden nur einmal gespeichert. Die eingesparte Dateigröße ist kleiner als bei der verlustbehafteten Kompression. Bei dieser werden unter anderem innerhalb des Bildes Bereiche ausfindig gemacht, die ungefähr dieselben Farbräume haben. Durch eine Angleichung auf exakt denselben Farbwert kann der Algorithmus die Datei anschließend wesentlich stärker komprimieren.

Hat man auf seiner Webseite nur wenige zu optimierende Bilder oder möchte man einzelne Grafiken komprimieren, bevor man sie im Content-Management-System seiner Wahl hochlädt, sind die Online-Tools tinypng.com (für PNGs) und tinyjpg.com (für JPGs) sehr empfehlenswert. Einsparungen bei der Dateigröße um mehr als 50 Prozent sind hier vor allem bei PNGs keine Seltenheit. Einen Unterschied zwischen Original- und optimierter Version ist für Nicht-Grafiker auf den ersten Blick so gut wie nicht erkennbar.

Einsparungen von über 50 Prozent sind bei der Kompression von PNGs keine Seltenheit. Das Tool tinypng hilft dabei.
Einsparungen von über 50 Prozent sind bei der Kompression von PNGs keine Seltenheit. Das Tool tinypng hilft dabei.

Bei einem größeren Projekt mit vielen hundert oder gar tausend Bild-Dateien ist die Nutzung eines Online-Tools nicht mehr sinnvoll. Technisch versierte Web- bzw. Frontend-Entwickler sollten dann eher zu Task-Runnern wie Grunt oder Gulp greifen. Diese erkennen neue Bild-Dateien und führen die Optimierung vollautomatisch aus. Für Grunt steht beispielsweise das Plugin Imagemin auf Github bereit.

4. Unnötigen Ballast entfernen

Beim Entwickeln von CSS-, JavaScript- und HTML-Dateien werden oft Kommentare und umfangreiche Einrückungen genutzt, um den Code verständlich und übersichtlich zu halten. Zwar ist dies für einen selbst oder andere Webentwickler enorm hilfreich, der Browser benötigt diese Informationen aber nicht. Aus diesem Grund lassen sich doppelte Leerzeichen, Tabulatoren, Zeilenumbrüche und auch Kommentare aus dem Quelltext auf dem Produktivsystem vollständig entfernen, ohne die Lauffähigkeit zu beeinträchtigen. Diese Maßnahme mag in Zeiten von VDSL nichtig wirken; Fakt ist aber, dass für jede optimierte Datei Einsparungen im zweistelligen Prozentbereich durchaus realistisch sind.

Für die kleine statische Webseite stehen auch hier diverse Online-Tools wie jscompress.com (JavaScript), htmlcompressor.com (HTML) oder cssminifier.com (CSS) zur Verfügung. Diese haben jedoch den großen Nachteil, dass Dateien nach einer Änderung erneut verarbeitet und hochgeladen werden müssen. Deshalb ist es, genau wie bei der Optimierung von Bild-Dateien, erstrebenswert, den Optimierungsprozess direkt in seiner Entwicklungsumgebung (IDE) via Task-Runner (etwa Grunt oder Gulp) durchzuführen.

CSS-Dateien lassen sich bei der Verwendung eines Preprocessors wie SASS oder LESS direkt komprimiert ausgeben. Hierfür ist in der Regel lediglich ein Eintrag in der Konfiguration notwendig. Für die JavaScript-Reduzierung sorgen Tools wie UglifyJs oder Closure Compiler von Google. Diese gehen sogar noch einen Schritt weiter und entfernen nicht verwendeten Code oder verkürzen Variablen- und Funktionsnamen.

5. Javascript- und CSS-Dateien zusammenlegen

Ein wichtiger Grundsatz bei der Pagespeed-Optimierung lautet: je weniger http-Requests notwendig sind, desto besser. Dies hat vor allem zwei Gründe: Erstens beschränken selbst moderne Browser die Anzahl an Dateien, welche gleichzeitig von einer Domain heruntergeladen werden dürfen. Mozilla Firefox und Google Chrome erlauben beispielsweise lediglich sechs parallele Downloads. Zweitens werden sowohl bei jeder Anfrage an den Server als auch jeder Antwort an den Browser so genannte Request und Response Header im http-Request mitübertragen – auch, wenn die enthaltenen Informationen gar nicht benötigt werden. Ein schönes Beispiel hierfür sind Cookies, welche beim Anfordern von CSS-, JavaScript- oder Bild-Dateien an den Server mitgesendet werden, obwohl die statischen Dateien gar keine Verwendung für sie haben.

Gerade bei Websites, die auf Content-Management-Systemen wie WordPress basieren und viele Drittanbieter-Plugins im Einsatz haben, sind mehr als ein Dutzend einzeln eingebundene JavaScript- und CSS-Dateien keine Seltenheit. Aus den oben genannten Gründen können Webentwickler durch die Zusammenlegung der Dateien den Seitenaufbau teilweise drastisch beschleunigen.

Bei der Kombination von CSS-Dateien kommen wieder die CSS-Preprozessoren wie SASS oder LESS ins Spiel. Im Falle von SASS/SCSS lassen sich Module hervorragend in eigene Dateien kapseln und anschließend durch Inkludieren in einer Ausgabe-Datei zusammenführen.

style.scss

@include 'inc/header';
@include 'inc/content';
@include 'inc/footer';

Listing 3

Dieser Code würde beispielsweise die drei Dateien _header.scss, _content.scss und _footer.scss aus dem Verzeichnis „inc“ importieren und in einer einzigen Datei ausgeben.

Das Zusammenlegen von JavaScript-Dateien ist meist etwas anspruchsvoller, da hier auf Abhängigkeiten unter den Skripten mehr Rücksicht genommen werden muss. Aber auch diese Aufgabe kann der versierte Webentwickler automatisiert via Task-Runner erledigen lassen. Für Grunt stehen beispielsweise die Plugins UglifyJs oder Concat zur Verfügung. Besonders effektiv ist es, die JavaScript-Dateien erst zu kombinieren und anschließend wie in Schritt 4 beschrieben zu reduzieren.

6. Inhalte erst Laden wenn nötig

Die meisten Webseiten laden direkt alle verfügbaren Ressourcen, auch wenn sie erst nach einer Aktion oder einem Scroll-Vorgang sichtbar werden. Um die initial zu ladende Dateimenge so klein wie möglich zu halten, bietet es sich an, Ressourcen asynchron nachzuladen. Diese Technik wird auch als „Lazy Loading“ bezeichnet.

Der häufigste Anwendungsfall dürfte wohl das Nachladen von Bildern und Grafiken sein, sobald sie nach dem Scrollen in den sichtbaren Bereich gelangen. Für diverse Content-Management-Systeme gibt es hier bereits fertige Lösungen, etwa „Crazy Lazy“ für WordPress. Wer etwas mehr Freiheit bei der Entwicklung benötigt, setzt eher auf jQuery-Plugins wie Unveil.js. Bei größeren professionellen Webprojekten lohnt sich die Entwicklung eines eigenen Lazy-Loading-Scripts. Eine simple, aber noch nicht für den Produktiveinsatz geeignete Variante könnte wie folgt aussehen:

lazyload.html

<img class="lazyload" xsrc="data:image/gif;base64,R0lGODlhAQABAIAAAAAAAP///yH5BAEAAAAALAAAAAABAAEAAAIBRAA7" data-src="picture.jpg" alt="" />

<script>
    $(window).on('scroll.lazyload', function(){
        $('img.lazyload').each(function(){
            var $img = $(this);
            if($(document).scrollTop() + $(window).height() >= $img.offset().top) {
                $img.removeClass('lazyload').attr('src', $img.data('src'));
            }  
        });
    });
</script>

Listing 4

Aber nicht nur Bilder, sondern auch große Skripte oder langsame Datenbank-Abfragen kann JavaScript problemlos nachladen:

load-script.js

$(window).on('load', function(){
    $.getScript('/external-advertising.js', function(){
        $('div.ads').show();    
    });    
});

$('a.get-slow-database-query').on('click', function(){
    $.get('/slow-database-query.php', function(html){
        $('div.slow-database-query').html(html);    
    });    
});

Listing 5

Einzelne JavaScript-Dateien lassen sich in modernen Browsern (Chrome, Firefox, Safari, Opera, IE ab Version 10) sogar noch bequemer asynchron laden. Dafür ergänzt man das jeweilige <script>-Element einfach um das async-Attribut. Dies ist unter anderem sinnvoll, um externe Skripte von Werbe-Anbietern oder sozialen Netzwerken auf der eigenen Website zu verbauen.

like-button-async.html

<div id="fb-root"></div>
<script>(function(d, s, id) {
  var js, fjs = d.getElementsByTagName(s)[0];
  if (d.getElementById(id)) return;
  js = d.createElement(s); js.id = id;
  js.async = 1; /* Diese Zeile wurde hinzugefügt */
  js.src = "//connect.facebook.net/de_DE/sdk.js#xfbml=1&version=v2.30847";
  fjs.parentNode.insertBefore(js, fjs);
}(document, 'script', 'facebook-jssdk'));</script>

Listing 6

Hier wurde der Standard-Code des Facebook Like Buttons um die Zeile „js.async = 1;“ erweitert. Dadurch lädt das externe Skript erst, sobald die wichtigen Webseiten-Inhalte vorhanden sind.

7. Der Above-the-Fold-Bereich

Dieser Punkt stellt selbst erfahrene Webentwickler immer wieder vor große Herausforderungen. Die Rede ist vom Critical-Rendering-Path. Ziel des Ganzen ist es, dem Browser die wirklich wichtigen Ressourcen (vor allem JavaScript und CSS) für den Above-the-fold-Bereich unmittelbar zur Verfügung zu stellen. Alle anderen Dateien werden erst im Anschluss vom Server angefordert.

Beim Start mit einem frischen Projekt ist die beste Vorgehensweise, seine CSS- und JavaScript-Dateien direkt in „critical“ und „noncritical“ aufzuteilen. CSS-Selektoren, die zum Beispiel den Seitenkopf betreffen, wandern in die kritische, Seitenfuß-Eigenschaften hingegen in die nicht kritische Datei. Beim JavaScript können sämtliche Events (Scrollen, Klicken, Fenstergröße ändern) meist ohne Probleme in der nicht kritischen Datei geladen werden, da sie beim Seitenaufbau noch nicht unmittelbar zur Verfügung stehen müssen. Skripte, die hingegen ein Slider-Element aufbauen oder etwas anderes am DOM verändern, was den Browser zu einem Repaint zwingt, sollten direkt geladen werden.

Sind beide Typen sauber voneinander getrennt, ist die Integration vergleichsweise simpel. Die kritischen CSS-Eigenschaften und Skripte werden direkt Inline (via <style>...</style> beziehungsweise <script>...</script>) im <head>-Element platziert. Die nicht kritische Ressourcen werden hingegen regulär vor dem schließenden <body>-Element eingefügt. Im Falle der JavaScript-Datei kann das <script>-Element sogar noch um das async-Attribut erweitert werden. Ob die Trennung zwischen kritischen und nicht kritischen Ressourcen korrekt war, lässt sich ganz leicht testen, indem man die nicht kritischen Dateien einfach auskommentiert und die Webseite anschließend neu lädt. An der initialen Darstellung des Above-the-fold-Bereiches dürfte sich nichts ändern.

critical-rendering-path.html

<html>
    <head>
        <style>/* critical */</style>
        <script>/* critical */</script>
    </head>
    <body>
        ...
        <link rel="stylesheet" href="/css/noncritical.css" type="text/css">
        <script xsrc="/js/noncritical.js" async></script>
    </body>
</html>

Listing 7

Was sich in der Theorie noch recht simpel anhören mag, ist in der praktischen Umsetzung alles andere als einfach. Auf die folgenden Fragen gibt es nämlich keine pauschalen Antworten, vielmehr müssen projektspezifische Entscheidungen getroffen werden.

  • Wo hört mein Above-the-Fold-Bereich eigentlich auf?
  • Ist der Above-the-Fold-Bereich auf mobilen Geräten nicht ein ganz anderer?
  • Meine Unterseiten haben teilweise einen anderen Seitenaufbau. Wie gehe ich hiermit am besten um?
  • Meine Besucher rufen in der Regel mehrere Unterseiten auf. Ist eine Inline-Platzierung von CSS und JavaScript überhaupt sinnvoll oder sind mir bereits gecachte Ressourcen beim zweiten Seitenaufruf wichtiger?

Pagespeed-Optimierung und die Rolle der Analyse-Tools

100 / 100 Punkten sind zwar schön anzusehen, aber lange nicht so wichtig wie die reale Ladezeit einer Webseite.
100 / 100 Punkten sind zwar schön anzusehen, aber lange nicht so wichtig wie die reale Ladezeit einer Webseite.

Viele Artikel zur Pagespeed-Optimierung starten mit der Erwähnung des allseits bekannten Google-PageSpeed-Insights-Tool, welches für Websites ein Ranking zwischen 1 und 100 aufstellt. Darauf habe ich in diesem Beitrag aus zwei Gründen verzichtet.

Erstens ist das Thema Geschwindigkeit viel zu wichtig, um es etwa nach einem Relaunch noch schnell im Anschluss dranzuhängen. Tools wie PageSpeed-Insights lassen schnell den Eindruck entstehen, Pagespeed-Optimierung wäre nichts weiter als eine Checkliste zum schnellen Abarbeiten.

Zweitens ist PageSpeed-Insights gar nicht in der Lage, die reale Geschwindigkeit oder Ladezeit einer Webseite zu messen. Vielmehr analysiert der Algorithmus simple technische Muster und zieht daraus seine Rückschlüsse. Dies geschieht zudem nur auf Basis einer einzelnen Seite und nie im Kontext des gesamten Web-Projekts beziehungsweise ohne Berücksichtigung der Tatsache, dass ein Besucher wiederkehren oder mehrere Unterseiten aufrufen könnte.

Einen Schritt weiter gehen die Tools Pingdom oder GTmetrix. Generell kann aber kein Tool den geschulten Blick in die Entwickler-Werkzeuge eines Browsers ersetzen, in dessen Network- oder Timeline-Reitern sich alle benötigten Informationen finden.

Dass eine Optimierung der Ladezeit- und -geschwindigkeit wichtig und für E-Commerce-Projekte sogar essentiell ist, dürfte mittlerweile jedem Verantwortlichen bewusst sein. Viel wichtiger als blind den Empfehlungen eines Tools zu folgen ist es aber, sich als Webentwickler tiefgreifende Erkenntnisse im Bereich der Pagespeed-Optimierung anzueignen und als stetigen Prozess bereits in der Entwicklung eines Projekts zu verankern.

Newsletter

Bleibe immer up-to-date. Sichere dir deinen Wissensvorsprung!

Vorheriger Artikel Zurück zur Startseite Nächster Artikel
4 Antworten
  1. von florence.maurice am 24.03.2016 (16:09 Uhr)

    bei den Tools würde ich aber schon http://www.webpagetest.org/ erwähnen, was ja wesentlich differenzierter ist als Google Pagespeed insights ...

    Antworten Teilen
  2. von Torben Leuschner am 24.03.2016 (16:16 Uhr)

    Hallo Florence,

    ich bin da wie im Artikel erwähnt eher bei Pingdom oder GTmetrix. Mit Webpagetest.org werde ich persönlich nicht wirklich warm.

    Beste Grüße,
    Torben

    Antworten Teilen
  3. von www.quadronet.de am 24.03.2016 (18:14 Uhr)

    In der Tat ein nicht einfaches Unterfangen für Webmaster, hier trennt sich die Speu vom Weizen, in Verbindung mit einem CM/S wie TYPO3 eine noch größere Herausforderungen i.V.m. Responsive Images. Der Beruf Webmaster wird immer komplexer und die Pilze die in den Jahren aus den Boden geschossen sind lichten sich ;-). Toller Artikel!

    Antworten Teilen
  4. von Holger am 24.03.2016 (18:27 Uhr)

    Vor allem Wordpress Nutzer welche viele Plugins nutzen, haben oft Performance Probleme. Öfters mal entschlacken hilft hier schon sehr oder man überlegt sich Funktionen ins Template zu integrieren. Vielmals gibt es einfachere Lösungen mit wenig Code.

    Antworten Teilen
Deine Meinung

Bitte melde dich an!

Du musst angemeldet sein, um einen Kommentar schreiben zu können.

Jetzt anmelden

Aktuelles aus dem Bereich Tipps
Infinite Scrolling: 9 Tipps, die du berücksichtigen musst
Infinite Scrolling: 9 Tipps, die du berücksichtigen musst

Die klassischen, mehrseitigen und verschachtelten Websites verabschieden sich immer mehr von uns und gehen in Richtung One-Pager und Infinite Scrolling – aber wie gut ist endloses Scrollen … » weiterlesen

10 Tipps für eine bessere Stellenanzeige mit mehr Traffic
10 Tipps für eine bessere Stellenanzeige mit mehr Traffic

Was macht eine gute Stellenausschreibung aus und wie erreicht man bestmöglich und gezielt viel Traffic? Diese Checkliste zeigt, worauf ihr bei einer Stellenausschreibung achten solltet, um viele … » weiterlesen

Konzentration, bitte! Mit diesen Tipps kannst du endlich fokussiert arbeiten
Konzentration, bitte! Mit diesen Tipps kannst du endlich fokussiert arbeiten

Eine E-Mail hier, ein Plausch dort und zwischendurch noch kurz Facebook checken – wir lenken uns nur allzu gerne von unserer Arbeit ab. Doch wie können wir uns selbst bändigen? Wir haben sieben … » weiterlesen

Alle Hefte Jetzt abonnieren – für nur 35 €

Kennst Du schon unser t3n Magazin?