Du hast deinen AdBlocker an?

Es wäre ein Traum, wenn du ihn für t3n.de deaktivierst. Wir zeigen dir gerne, wie das geht. Und natürlich erklären wir dir auch, warum uns das so wichtig ist. Digitales High-five, deine t3n-Redaktion

Software & Infrastruktur

Performance für Einsteiger, Teil 2: Requests reduzieren, Geschwindigkeit erhöhen

In unserer Performance-Einsteiger-Serie verraten wir dir, was es zu beachten gilt und wie du leicht selbst die Performance deiner Webseite verbessern kannst. Heute widmen wir uns der Netzwerk-Technik.

Die Netzwerk Performance ist ein wichtiger Einflussfaktor auf die Performance unserer Webseite. In den meisten Fällen haben wir, als Entwickler, jedoch nur sehr geringen Einfluss auf die Netzwerk-Ebene. Wir können nicht die Einstellungen unserer Besucher ändern und auch die Einstellungen bei unseren „Hostern“ bleiben meist Angelegenheit des Service-Anbieters. Dennoch ist ein gewisses Grundwissen wichtig, um zu verstehen warum einige Websites schneller dargestellt werden können als andere.

Um die Auswirkungen testen zu können, haben wir für dich eine Reihe von Tools zur Reduzierung von Bandbreite,  Erhöhung der Latenz und der Fehlerquote zusammengestellt.

Performance-Killer: Hohe Latenz

Das Grundlegene Verfahren für den Austausch von Daten im Internet ist TCP/IP. Hierbei werden Daten als Strom verschickt und in Pakete unterteilt. Auf der Struktur des Internets basierend, durchlaufen diese Pakete unterschiedliche Routen. Das bedeutet, dass sie meistens nicht in richtiger Reihenfolge beim Client ankommen als sie versendet wurden. Diese einzelnen Pakete werden im Client zwischengespeichert und anschließend in richtiger Reihenfolge wieder zusammengesetzt. Diese Verzögerung zwischen Anforderung einer Information und der letztendlichen Anzeige im Browser nennt man Latenz. Aufgrund davon kann es nämlich passieren, dass fehlerhafte Pakete übertragen werden und so neu angefordert werden müssen, was die Latenz zusätzlich erhöht.

Die Latenz der Verbindung ist eigentlich wichtiger als die Bandbreite. Je höher die Latenz ist, desto länger brauchen wir, bis die Nutzdaten beziehungsweise die „Payload“ – also die Daten, die keine Protokoll- oder Steuerdateien enthalten – übertragen werden. Je mehr Dateien ich habe, desto höher ist die negative Auswirkung auf die Latenz in Bezug auf die Ladezeit meiner Seite. Kurz gesagt: Eine hohe Anzahl an ladenden Dateien erhöht die Zeit bis die Seite geladen wurde. Im schlimmsten Fall müssen gewisse Datenpakete mehrmals geschickt werden, weil sie fehlerhaft am Ziel ankommen.

Latenz vs. Bandbreite
Auswirkungen steigender Latenz und sinkender Bandbreite auf die Ladezeit der Webseite. (Grafik: Orreily)

Besonders deutlich wird das bei mobilen Geräten, die zum Teil schon beachtliche Bandbreiten erreichen und dennoch in der Gesamtperformance nicht immer überzeugen können. Natürlich ist die Bandbreite kein irrelevanter Wert, eine geringere Bandbreite hat aber, verhältnismäßig gesehen, einen geringeren Einfluss auf die Ladezeit unserer Seiten, als eine hohe Latenz.

Bevor eine Verbindung über TCP/IP hergestellt werden kann, muss der Client die IP-Adresse des Servers kennen. Hierfür gibt es DNS – den „Domain-Name-Service“. Um zu wissen, an welchen Server welche Abfragen abgeschickt werden, wendet sich der Client zunächst an den DNS-Server einer Domain, um die IP-Adresse zur Domain abzufragen. So wird www.t3n.de der IP-Adresse 94.198.61.181 zugeordnet.

DNS Rekursion Funktionsweise
DNS Rekursion Funktionsweise. (Grafik: Wikipedia (Wikimedia Commons)

Die DNS-Abfrage ist eine zusätzliche „Belastung“ in der Performance-Kette und sorgt dafür, dass wir zusätzliche Wartezeit in Kauf nehmen müssen. Die Abfrage eines DNS-Eintrages kann durchaus mehrere hundert Millisekunden dauern. Was sich nach wenig anhört, summiert sich allerdings mit anderen Faktoren schnell zu einer spürbaren Ladezeit.

Zwischenfazit: Viele HTTP-Verbindungen reduzieren die Performance

Wir merken uns also: HTTP-Verbindungen verursachen eine zusätzliche Verzögerung, die sich mit jedem zusätzlichen Aufruf weiterer Dateien erhöht. Unser Ziel sollte es also sein, die Anzahl von HTTP-Verbindungen so gering wie möglich zu halten. Dennoch streben wir eine gewisse Parallelität an, da mehrere parallel laufende HTTP-Verbindungen und Downloads logischerweise zu einer schnelleren Performance der Seite führen.

Auch die Anzahl der DNS-Lookups beeinflusst die Performance, sodass in der Regel möglichst wenig verschiede Domains abgefragt werden sollten.

Bessere Parallelität, weniger HTTP-Verbindungen

Moderne Browser stellen normalerweise mehr als die von HTTP 1.1 empfohlenen zwei Verbindungen pro Domain her. Mit dem Einsatz von Schein-Domains kann dieses Verhalten zusätzlich ausgenutzt werden. Hierbei werden DNS-Aliase, so genannte „CNAMES“ angelegt, die auf dieselbe IP-Adresse zeigen. So hätten wir zum Beispiel www1.meineseite.de, www2.meineseite.de etc. zur Verfügung, um die gleichen Inhalte abzufragen.

Der Browser behandelt diese Domain trotz identischer IP-Adresse als verschiedene Server und baut somit zusätzliche Verbindungen zu ihnen auf, sodass eine höhere Parallelität – also mehr gleichzeitige Downloads – beim Abruf der Seiteninhalte erzielt werden können.

Diese Lösung bringt jedoch auch Probleme mit sich. Jede zusätzliche Domain bedeutet einen weiteren DNS-Lookup, also eine weitere Anfrage an einen DNS-Server. Außerdem können Pfade im Dokument nicht mehr relativ angegeben werden, wodurch das Dokument aufgebläht wird und gegebenenfalls erzielte Vorteile, aus der höheren Parallelität, relativiert werden. Auch der Aufwand für die Implementierung einer solchen Lösung ist nicht zu unterschätzen.

„3rd-Party-Content“

2-Klick Social Media Lösung
2-Klick Social Media Lösung

Besonders auf „3rd-Party-Content“ sollte ein Blick geworfen werden. Wenn du beispielsweise Social-Media Buttons in deiner Webseite eingebunden hast, die automatisch auf externe Bibliotheken von Facebook & Co. zugreifen, obwohl die Buttons nur vergleichsweise selten von deinen Usern genutzt werden, solltest du eine Zwei-Klick-Lösung in Erwägung ziehen.

Bei der Zwei-Klick-Lösung werden die Social-Media-Elemente nur als Grafiken eingefügt, die durch einen weiteren Klick ein Nachlade-Ereignis im Browser auslösen und die jeweiligen Social-Media-Skripte zur Webseite hinzufügen. Somit verzichtest du auf unnötige Aufrufe, erhöhst die Geschwindigkeit deiner Seite und musst dir gleichzeitig weniger Sorgen um die Rechtslage, zum direkten Einbinden von Social-Media-Komponenten, machen.

Die Kollegen des „c’t“-Magazins stellen zum Beispiel ihr Zwei-Klick-Plugin für jQuery zum freien Download zur Verfügung.

Höhere Performance durch „Inlining“

Um die Anzahl von HTTP-Verbindungen zusätzlich zu reduzieren, können wir auf das so genannte „Inlining“ zurückgreifen.

Als „Inlining“ bezeichnet man die Positionierung von externalisierbaren Ressourcen wie JavaScript oder CSS innerhalb des HTML-Dokumentes. „Inlining“ ist in der Regel schneller als die Externalisierung solcher Inhalte, da dadurch Abfragen von externer Ressourcen eingespart werden können.

So kannst du anstatt, externe Skripte einzubinden, alle Befehle direkt im <script> tag der Webseite einfügen. Das gleiche gilt auch für CSS.

<html>
<head>
<style>
/*  CSS, das externalisiert werden könnte,
wird direkt ins Dokumente geschrieben
um Aufrufe zu reduzieren */
</style>
</head>
<body>
<h1 style=“color:#fefefe;“>Überschrift mit Inline Styling</h1>
[...]
<script type=“text/javascript“>
/*  JavaScript, das externalisiert werden könnte,
wird direkt ins Dokumente geschrieben
um Aufrufe zu reduzieren */
</script>
</body>
</html>

Ein Nachteil dieser Lösung ist, dass normalerweise nur externe Ressourcen zwischengespeichert werden. Somit ist das „Inlining“ nur für statische Seiten und Landingpages geeignet, die entweder nur selten abgerufen werden, oder bedenkenlos zwischengespeichert werden dürfen.

Bitte beachte unsere Community-Richtlinien

7 Reaktionen
bambam

@benjamin

Das stimmt, jedoch muss man von Fall zu Fall unterscheiden. Wenn es eine Seite ist, wo der Benutzer vielleicht 1x im Monat reinschaut, ist inline code besser.

Antworten
Fehler-Tools

@bejamin.funk: Für javascript das nur an einer Stelle gebraucht wird, bzw. Webseiten die offline funktionieren, ist inlining sicher ok.

Wiederkehrendes Java-Script und alle Dekorations-Elemente hingegen sollte man wirklich auslagern und vielleicht spriten und Expiration passend setzen und vielleicht auch alles wiederkehrende in eine gemeinsame javascript-datei packen die beim Client nur noch einmal pro Woche geladen wird.

Gibt es Tools um die verlorenen Pakete anzuzeigen ? Das muss ja wohl im TCP-Treiber passieren. Dasselbe für Ethernet und Wifi (tiefere Stufen bei Osi-Schichten) wäre auch nett um zu sehen ob / wie man den Empfang verbessern kann.
Sowas müsste jedes Handy und Tablett mitgeliefert haben um zu kontrollieren wo im WiFi-Cafe der Empfang am besten ist oder ob z.B. die Blutooth-Soundbar oder Bluetooth-Headset den Wifi-Empfang verringert oder der Staubsauger neben dem Ethernet-Kabel die Übertragung verschlechtert und daher die Aussetzer bei Youtube oder Mediatheken am SmarTV kommen.

Daher wären Tools ganz nett, um zu sehen wie die Layer und Fehler dort sich verhalten. Windows-Taskmonitor zeigt ja schon mal die Bandbreite an. Resends u.ä. wären auch ganz interessant. Speziell bei WiFi oder vielleicht auch Bluetooth wenn die Soundbar knackst oder der Ton Aussetzer hat.

Antworten
Ilja Zaglov

Hallo Benjamin,

du hast Recht. Grundsätzlich alles zu Inlinen ist nicht nur umständlich in der Entwicklung und Wartung sondern zieht auch die von dir beschriebenen Nachteile mit sich.

Für Landingpages, die z.B. nur einmalig aufgerufen werden, ist diese Vorgehensweise jedoch eine gängige und empfehlenswerte Praxis, um eine schnellere Ladezeit zu erhalten. Wenn solche statischen Seiten dann noch zusätzlich im Cache abgeladen werden, entsteht auch nicht das Problem mit dem ungecachten Code.

Da der JavaScript Code zusammen mit dem HTML-Dokument übertragen wird, trifft das Blocking-Problem nicht auf. Das Problem besteht nur beim Laden von externen ungecachten JavaScript Ressourcen.

Antworten
benjamin.funk

Das "Inlining" von JS und CSS Code ist das schlimmste was man machen kann. Mag sein das der Code schneller geladen wird. Das Problem ist allerdings das der Code jedes Mal geladen werden muss. Code welcher über "Inlining" eingebunden wird kann nicht gecached werden!

Der Nachteil vom nicht gecachetem Javascript Code ist dann das der Browser alle Ladevorgänge nach hinten verschiebt solange dieser noch Javascript Code laden muss. Deswegen sollten man tunlichst darauf achten das Javascript Code gecached werden kann.

Antworten
weddig

Wer sich für Google PageSpeed in dem Zusammenhang interessiert sollte auch mal bei uns im Blog vorbeischauen: http://weddig-keutel.de/blog/mission-overall-pagespeed-100-von-sinn-unsinn-und-einer-kleinen-enttaeuschung/

Antworten
dazzle89

Schöner Artikel.

Die Rechtschreibung ist aber echt grauenvoll. Und das trifft leider auf ganz t3n zu.

Antworten
Enis

Danke für den tollen Artikel! In Zeiten wie in unseren, wo die Geschwindigkeit einer Page auch das Ranking in den Suchmaschinen beeinflusst, sicherlich ein heißer Tipp!

Antworten

Melde dich mit deinem t3n Account an oder fülle die unteren Felder aus.