So laden Sie Ihre Websites schneller

  • Erforderliche Kenntnisse: Mittlere CSS und JavaScript , Basic HTML5
  • Benötigt: Eine Website zum Beschleunigen
  • Projektzeit: Stark abhängig von der Website

Dieser Artikel erschien erstmals in Ausgabe 231 des .net-Magazins

Geschwindigkeit sollte für jede Website wichtig sein. Es ist bekannt, dass Google die Geschwindigkeit der Website als Ranking-Metrik für Suchergebnisse verwendet. Dies zeigt uns, dass Besucher schnelle Websites bevorzugen - keine Überraschung!

Jakob Nielsen schrieb 1993 über die drei Grenzen der Reaktionszeiten ;; Obwohl die Forschung nach Internetstandards alt ist, hat sich an unserer Psychologie in den letzten 19 Jahren nicht viel geändert. Er gibt an, dass ein System, das in weniger als 0,1 Sekunden reagiert, als augenblicklich wahrgenommen wird, während Antworten, die schneller als eine Sekunde sind, es dem Gedankenfluss des Benutzers ermöglichen, ununterbrochen zu bleiben. Das Laden einer Webseite in 0,1 Sekunden ist wahrscheinlich unmöglich. Etwa 0,34 Sekunden stellen die beste Ladezeit von Google UK dar. Dies dient als realistischerer (wenn auch ehrgeiziger) Benchmark. Ein Seitenladevorgang im Bereich von 0,34 bis 1 Sekunde ist erreichbar und wichtig.

01. Der Preis für die Verlangsamung

Diese Art von Zielen hat reale Auswirkungen auf Ihre Website und Ihr Unternehmen. Marissa Mayer von Google sprach 2006 über ein Experiment, bei dem die Anzahl der von der Suchmaschine zurückgegebenen Ergebnisse auf 30 erhöht wurde. Dies verlangsamte die Ladezeit der Seite um etwa 500 ms, wobei ein Rückgang des Datenverkehrs um 20% darauf zurückzuführen war. Amazon verzögerte das Laden der Seite künstlich in Schritten von 100 ms und stellte fest, dass „selbst sehr kleine Verzögerungen zu erheblichen und kostspieligen Umsatzrückgängen führen würden“.



Das Browser-Plug-In für die Leistungsbewertung von Open Source-Webseiten YSlow basiert auf den Leistungsempfehlungen der Website des Yahoo Developer Network

Das Browser-Plug-In für die Leistungsbewertung von Open Source-Webseiten YSlow basiert auf den Leistungsempfehlungen der Website des Yahoo Developer Network

Andere nachteilige Assoziationen, die mit langsamen Websites verbunden sind, umfassen verminderte Glaubwürdigkeit, geringere wahrgenommene Qualität und die Website wird als weniger interessant und attraktiv angesehen . Erhöhte Frustration der Benutzer und erhöhter Blutdruck sind zwei weitere Effekte, die wir wahrscheinlich alle irgendwann erlebt haben! Aber wie können wir sicherstellen, dass unsere Websites schnell genug geladen werden, um diese Probleme zu vermeiden?

Eines der ersten Dinge, die Sie sich ansehen sollten, ist die Größe Ihres HTML-Codes. Dies ist wahrscheinlich einer der am meisten übersehenen Bereiche, vielleicht weil die Leute annehmen, dass er bei modernen Breitbandverbindungen nicht mehr so ​​relevant ist. Einige Content-Management-Systeme sind in Bezug auf die Menge, die sie produzieren, ziemlich liberal - ein Grund, warum es besser sein kann, Ihre eigenen Websites von Hand zu erstellen.

Als Richtlinie sollten Sie leicht in der Lage sein, die meisten Seiten einzupassen<50KB of HTML code, and if you’re under 20KB then you’re doing very well. There are obviously exceptions, but this is a fairly good rule of thumb.

Es ist auch wichtig zu bedenken, dass Benutzer jetzt häufiger auf mobilen Geräten vollständige Websites durchsuchen. Geschwindigkeitsunterschiede zwischen Standorten, die von einem Mobiltelefon aus betrachtet werden, sind häufig deutlicher, da sie langsamere Übertragungsraten aufweisen als Kabelverbindungen. Zwei konkurrierende Websites mit einem Größenunterschied von 100 KB pro Seite können in einigen langsamen Mobilfunknetzen einen Ladezeitunterschied von mehr als einer Sekunde bedeuten - bis weit in den von Jakob Nielsen festgelegten Bereich des „unterbrochenen Gedankenflusses“. Das Trimmen der schnelleren Website wird viel weniger frustrierend sein, da sie einen deutlichen Wettbewerbsvorteil gegenüber dickeren Websites bietet und einen großen Beitrag zur Förderung wiederholter Besuche leistet.

Es gibt alternative, qualitativ hochwertige Ressourcen zur Messung der Leistung, z. B. das kostenlose webbasierte PageSpeed ​​Online-Tool von Google

Es gibt alternative, qualitativ hochwertige Ressourcen zur Messung der Leistung, z. B. das kostenlose webbasierte PageSpeed ​​Online-Tool von Google

Ein wichtiges Merkmal der meisten Webserver ist die Fähigkeit, HTML in einem komprimierten Format bereitzustellen. Da HTML von Natur aus viele sich wiederholende Daten enthält, ist es ein perfekter Kandidat für die Komprimierung. Beispielsweise wird der 18,1-KB-HTML-Code einer Homepage auf 6,3 KB reduziert, wenn er im komprimierten Format bereitgestellt wird. Das ist eine Ersparnis von 65 Prozent! Komprimierungsalgorithmen steigern die Effizienz, je größer der Text ist, mit dem sie arbeiten müssen, sodass Sie bei größeren HTML-Seiten größere Einsparungen erzielen. Eine 138,1-KB-Seite in einem beliebten Forum wird bei komprimierter Bereitstellung auf 25,7 KB reduziert, was einer Einsparung von über 80 Prozent entspricht. Dies kann die Gesamtübertragungszeiten von Ressourcen erheblich verbessern.

Das Bereitstellen von HTML in dieser Form hat praktisch keine Nachteile. Jeder sollte es für alle seine HTML-Inhalte aktivieren. Einige Webserver verfügen über unterschiedliche Einstellungen zum Komprimieren von statischen und dynamisch generierten Inhalten. Es lohnt sich daher sicherzustellen, dass Sie komprimierte Inhalte nach Möglichkeit für beide bereitstellen.

02. Content Delivery-Netzwerke

Content Delivery Networks (sogenannte CDNs) können auch die Ladezeiten Ihrer Website erheblich verbessern. CDNs sind eine Sammlung von Servern, die auf der ganzen Welt verteilt sind und alle Kopien Ihrer Inhalte enthalten. Wenn ein Benutzer ein Bild von Ihrer Website anfordert, das auf einem CDN gehostet wird, wird der Server im CDN verwendet, der dem Benutzer geografisch am nächsten liegt.

Es sind viele CDN-Dienste verfügbar. Einige davon sind sehr kostspielig, geben jedoch an, dass sie eine bessere Leistung bieten als billigere CDNs. Kostenlose CDN-Dienste tauchen ebenfalls auf und es kann sich lohnen, damit zu experimentieren, um festzustellen, ob sie die Leistung Ihrer Website verbessern können.

Eine wichtige Überlegung bei der Verwendung eines CDN ist, sicherzustellen, dass Sie es richtig eingerichtet haben, damit Sie keinen SEO-Wert verlieren. Abhängig von der Art Ihrer Website erhalten Sie möglicherweise viel Verkehr von Bildern, die auf Ihrer Domain gehostet werden. Wenn Sie diese auf eine externe Domain verschieben, kann dies Ihren Verkehr beeinträchtigen. Mit dem Amazon S3-Dienst können Sie eine Subdomain auf ihr CDN verweisen. Dies ist eine äußerst bevorzugte Funktion in einem CDN.

Das kostenlose Tool von Pingdom zur Analyse des Wasserfalls Ihrer Webseite hilft dabei, die Ladezeit jeder Ressource aufzuschlüsseln, um Engpässe aufzuzeigen

Das kostenlose Tool von Pingdom zur Analyse des Wasserfalls Ihrer Webseite hilft dabei, die Ladezeit jeder Ressource aufzuschlüsseln, um Engpässe aufzuzeigen

Das Bereitstellen von Inhalten auf einer anderen Domain (z. B. einem CDN) oder einer Subdomain auf Ihrem eigenen Domainnamen, die keine Cookies setzt, hat einen weiteren entscheidenden Vorteil. Wenn in einer Domäne ein Cookie gesetzt wird, sendet der Browser bei jeder Anforderung Cookie-Daten an jede Ressource in derselben Domäne. In den meisten Fällen sind Cookie-Daten für statische Inhalte wie Bilder, CSS- oder JavaScript-Dateien nicht erforderlich. Die Upload-Raten von Webbenutzern sind häufig viel langsamer als die verfügbaren Download-Raten, was in einigen Fällen zu einer erheblichen Verlangsamung der Ladezeiten von Seiten führen kann. Durch die Verwendung eines anderen Domainnamens zur Bereitstellung Ihrer statischen Inhalte senden Browser diese unnötigen Cookie-Daten nicht, da sie strenge domänenübergreifende Richtlinien haben. Dies kann die Anforderungszeiten für jede Ressource erheblich beschleunigen.

Cookies auf Websites können auch den größten Teil einer HTTP-Anfrage aufnehmen. 1.500 Byte sind ungefähr das am häufigsten verwendete Einzelpaketlimit für große Netzwerke. Wenn Sie also Ihre HTTP-Anforderungen unter diesem Limit halten können, sollte die gesamte HTTP-Anforderung in einem Paket gesendet werden. Dies kann zu Verbesserungen der Ladezeiten von Seiten führen. Google empfiehlt, dass Ihre Cookies weniger als 400 Byte groß sein sollten. Dies trägt wesentlich dazu bei, dass die HTTP-Anforderungen Ihrer Websites unter dem Grenzwert von einem Paket / 1.500 Byte liegen.

03. Weitere Techniken

Es gibt andere, einfacher zu implementierende Techniken, die die Geschwindigkeit Ihrer Website erheblich verbessern können. Eine Möglichkeit besteht darin, Ihre JavaScript-Dateien am Ende Ihres HTML-Dokuments kurz vor dem schließenden Body-Tag zu platzieren, da die Anzahl der Ressourcen, die Browser parallel von demselben Host herunterladen können, begrenzt ist.

Die ursprüngliche HTTP 1.1-Spezifikation aus dem Jahr 1999 empfiehlt, dass Browser nur bis zu zwei Ressourcen parallel von jedem Hostnamen herunterladen sollten. Moderne Browser haben jedoch standardmäßig ein Limit von etwa sechs. Wenn Ihre Webseite über mehr als sechs externe Ressourcen verfügt (z. B. Bilder / JavaScript / CSS-Dateien), bietet sie möglicherweise eine verbesserte Leistung, um sie von mehreren Domänen (z. B. einer Unterdomäne in Ihrem Hauptdomänennamen oder einem CDN) aus bereitzustellen, um den Browser sicherzustellen erreicht bei parallelen Downloads nicht die maximale Grenze.

Sprite-Blätter sind einfach zu implementieren und können die Seitenleistung erheblich verbessern, indem die Gesamtzahl der HTTP-Anforderungen reduziert wird

Sprite-Blätter sind einfach zu implementieren und können die Seitenleistung erheblich verbessern, indem die Gesamtzahl der HTTP-Anforderungen reduziert wird

Anstatt mehrere Anforderungen auf verschiedene Domänen aufzuteilen, können Sie sie kombinieren. Jeder HTTP-Anforderung ist ein Overhead zugeordnet. Dutzende von Bildern, wie z. B. Symbole auf Ihrer Website, die als separate Ressourcen dienen, verursachen viel verschwenderischen Overhead und führen zu einer Verlangsamung Ihrer Website, die häufig erheblich ist. Durch Kombinieren Ihrer Bilder zu einem Bild, das als 'Sprite Sheet' bezeichnet wird, können Sie die Anzahl der erforderlichen Anforderungen reduzieren. Um das Bild anzuzeigen, definieren Sie es in CSS, indem Sie die Breite und Höhe eines Elements auf die des anzuzeigenden Bilds und anschließend den Hintergrund auf das Sprite-Blatt einstellen. Mit dem Hintergrundposition Eigenschaft können wir das Hintergrund-Sprite-Blatt in Position verschieben, so dass es auf Ihrer Website als das beabsichtigte Bild angezeigt wird.

Sprite-Folien bieten auch andere Vorteile. Wenn Sie Mouseover-Bilder verwenden, bedeutet das Speichern auf demselben Sprite-Blatt, dass beim Starten des Mouseover keine Verzögerung auftritt, da das Mouseover-Bild bereits in das Sprite-Blatt geladen wurde! Dies kann die vom Benutzer wahrgenommene Ladezeit erheblich verbessern und eine viel reaktionsschnellere Website erstellen.

Angeben der Abmessungen anderer Bilder in Tags sind auch ein wichtiger Faktor für die Erhöhung der wahrgenommenen Ladezeit Ihrer Webseite. Es ist üblich, dass Entwickler Breite und Höhe für Bilder auf Seiten nicht explizit festlegen. Dies kann dazu führen, dass sich die Seitengröße in Sprüngen vergrößert, wenn jedes Bild (teilweise) geladen wird, wodurch sich die Dinge träge anfühlen. Wenn explizite Abmessungen festgelegt sind, kann der Browser beim Laden Platz für das Bild reservieren, wodurch die Änderung der Seitengröße gestoppt und die vom Benutzer wahrgenommene Ladezeit manchmal erheblich verbessert wird.

Was können wir also noch tun, um dies zu verbessern? Prefetching ist eine solche Funktion, die in HTML5 verfügbar ist. Das Prefetching ermöglicht das Laden von Seiten und Ressourcen, bevor der Benutzer sie tatsächlich angefordert hat. Die Unterstützung ist derzeit auf Firefox und Chrome (mit einer alternativen Syntax) beschränkt. Die einfache Implementierung und Nützlichkeit bei der Verbesserung der wahrgenommenen Ladezeit Ihrer Webseite ist jedoch so groß, dass eine Implementierung in Betracht gezogen werden sollte.






Es gibt einen Verhaltensunterschied zwischen Prefetching und Prerender. Mozillas Prefetch lädt die Ressource der obersten Ebene für eine bestimmte URL, normalerweise die HTML-Seite selbst, und hier wird das Laden gestoppt. Google Prerender lädt auch untergeordnete Ressourcen und erledigt in Googles Worten 'die gesamte Arbeit, die erforderlich ist, um die Seite dem Benutzer anzuzeigen, ohne sie tatsächlich anzuzeigen, bis der Benutzer klickt'.

Google Analytics enthält mehrere nützliche Tools und Berichte, mit denen Sie die langsamsten Seiten Ihrer Website identifizieren können

Google Analytics enthält mehrere nützliche Tools und Berichte, mit denen Sie die langsamsten Seiten Ihrer Website identifizieren können

04. Überlegungen zum Vorabrufen und Vorrendern

Die Verwendung dieser Funktion bringt jedoch auch wichtige Überlegungen mit sich. Wenn Sie zu viele Assets oder Seiten vorrendern / vorab abrufen, kann die gesamte Browser-Erfahrung des Benutzers darunter leiden. Wenn Sie serverseitige Statistiken haben, können diese stark verzerrt sein. Wenn der Benutzer nicht auf die vorinstallierte Ressource klickt und Ihre Website verlässt, zählt Ihr Statistik-Tracker den Besuch möglicherweise als zwei Seitenaufrufe, nicht als die eigentliche. Dies kann für wichtige Kennzahlen wie Absprungraten irreführend sein.

Chrome Prerender hat eine weitere Einschränkung, die Entwickler beachten müssen, da die vorgerenderte Seite JavaScript ausführt. Der Prerender lädt die Seite fast genauso, als ob der Benutzer auf den Link geklickt hätte. Chrome sendet keine speziellen HTTP-Header mit einem Prerender. Mit der API für die Sichtbarkeit von Seiten können Sie jedoch unterscheiden, ob die Seite vorgerendert wird. Dies ist wiederum von entscheidender Bedeutung für alle von Ihnen verwendeten Skripte von Drittanbietern, z. B. Werbeskripte und Statistik-Tracker (Google Analytics verwendet bereits die API für die Sichtbarkeit von Seiten, sodass Sie sich darüber keine Gedanken machen müssen). Wenn Sie diese Assets erneut mit der Page Visibility-API falsch behandeln, besteht die Gefahr, dass wichtige Metriken verzerrt werden.

Verwenden von Prefetch und Prerender Bei paginierten Inhalten handelt es sich wahrscheinlich um eine sichere und nützliche Implementierung - beispielsweise auf einer Tutorials-Webseite, die in mehrere Abschnitte unterteilt ist. Insbesondere bei Inhalten wie Tutorials ist es wahrscheinlich wichtig, innerhalb der Grenzen von Nielsens „ununterbrochenem Gedankenfluss“ zu bleiben.

Google Analytics kann auch wertvolle Hinweise geben, welche Seiten Sie möglicherweise vorrendern / vorab abrufen möchten. Mithilfe der In-Page-Analyse können Sie bestimmen, auf welchen Link auf Ihrer Homepage am wahrscheinlichsten geklickt wird. In einigen Fällen mit genau definierten Handlungsaufforderungen kann dieser Prozentsatz extrem hoch sein - was ihn zu einem hervorragenden Kandidaten für das Vorladen macht.

Sowohl das Vorabrufen als auch das Vorrendern funktionieren domänenübergreifend - eine ungewöhnlich liberale Haltung für Browser, die beim domänenübergreifenden Zugriff normalerweise äußerst streng sind. Dies wirkt sich jedoch wahrscheinlich zu Gunsten von Google und Mozilla aus, da sie auf verschiedene Weise ein schnelleres Surferlebnis für ihre Nutzer schaffen können und einen erheblichen Wettbewerbsvorteil gegenüber anderen Browsern bieten, die solche Funktionen noch nicht unterstützen.

Ein Screenshot vom IIS7-Webserver zeigt, wie einfach es ist, statische und dynamische Inhalte zu komprimieren

Ein Screenshot vom IIS7-Webserver zeigt, wie einfach es ist, statische und dynamische Inhalte zu komprimieren

Prefetching und insbesondere Prerendering sind leistungsstarke Tools, mit denen sich die wahrgenommenen Ladezeiten von Webseiten erheblich verbessern lassen. Es ist jedoch wichtig zu verstehen, wie sie funktionieren, damit das Surferlebnis Ihrer Benutzer nicht direkt und negativ beeinflusst wird.

05. Ajax-Inhalt wird geladen

Eine andere Möglichkeit, die Ladezeiten zu verbessern, besteht darin, Ajax zum Laden von Inhalten zu verwenden, anstatt die gesamte Seite erneut zu laden. Effizienter, da nur die Änderungen geladen werden, nicht die Boilerplate, die den Inhalt jedes Mal umgibt.

Das Problem beim Laden von Ajax ist, dass es sich wie ein unnatürliches Surferlebnis anfühlt. Wenn sie nicht ordnungsgemäß ausgeführt werden, funktionieren die Schaltflächen 'Zurück' und 'Vorwärts' nicht wie vom Benutzer erwartet. Aktionen wie das Lesezeichen von Seiten oder das Aktualisieren der Seite verhalten sich ebenfalls unerwartet. Beim Entwerfen von Websites ist es ratsam, solche Verhaltensweisen auf niedriger Ebene nicht zu beeinträchtigen - dies ist sehr beunruhigend und für Benutzer unfreundlich. Ein Paradebeispiel hierfür wären die Bemühungen einiger Websites, das Klicken mit der rechten Maustaste auf ihre Webseiten zu deaktivieren, um Urheberrechtsverletzungen zu verhindern. Obwohl die Implementierung von Ajax den Betrieb des Browsers mit der gleichen Absicht, das Klicken mit der rechten Maustaste zu deaktivieren, nicht beeinträchtigt, sind die Auswirkungen ähnlich.

HTML5 behebt diese Probleme mit der Verlaufs-API. Es wird in Browsern gut unterstützt (abgesehen von Internet Explorer, obwohl geplant ist, dass es in IE10 unterstützt wird). Mit der HTML5-Verlaufs-API können wir Inhalte mit Ajax laden und gleichzeitig eine „normale“ Browser-Erfahrung für Benutzer simulieren. Bei ordnungsgemäßer Verwendung funktionieren die Schaltflächen Zurück, Vorwärts und Aktualisieren wie erwartet. Die URL der Adressleiste kann ebenfalls aktualisiert werden, sodass das Lesezeichen jetzt wieder ordnungsgemäß funktioniert. Bei korrekter Implementierung können Sie viele wiederholte Ladevorgänge von Ressourcen entfernen und für Browser mit deaktiviertem JavaScript ordnungsgemäße Fallbacks verwenden.

Der Chrome Web Store lädt viele Inhalte mit Ajax auf eine Weise, die sich wie ein schnelles, natürliches Surferlebnis anfühlt

Der Chrome Web Store lädt viele Inhalte mit Ajax auf eine Weise, die sich wie ein schnelles, natürliches Surferlebnis anfühlt

Es gibt jedoch einen großen Nachteil: Abhängig von der Komplexität und Funktion der Site, die Sie erstellen möchten, ist es schwierig, das Laden von Ajax-Inhalten mit der Verlaufs-API auf eine Weise zu implementieren, die für den Benutzer unsichtbar ist. Wenn die Site auch serverseitiges Scripting verwendet, schreiben Sie möglicherweise auch zweimal: einmal in JavaScript und erneut auf dem Server - was zu Wartungsproblemen und Inkonsistenzen führen kann. Es kann schwierig und zeitaufwändig sein, es zu perfektionieren, aber wenn es wie beabsichtigt funktioniert, können Sie die tatsächlichen und wahrgenommenen Ladezeiten für den Benutzer erheblich reduzieren.

Wenn Sie versuchen, die Geschwindigkeit Ihrer Website zu verbessern, können unlösbare Probleme auftreten. Wie am Anfang dieses Artikels erwähnt, ist es kein Geheimnis, dass Google die Seitengeschwindigkeit als Ranking-Metrik verwendet. Dies sollte eine wichtige Motivation sein, um die Geschwindigkeit Ihrer Website zu verbessern. Möglicherweise stellen Sie jedoch fest, dass bei Verwendung von Ressourcen wie den Seitengeschwindigkeitsberichten der Google Webmaster-Tools langsamere Ladezeiten als erwartet gemeldet werden.

Die Ursache können Skripte von Drittanbietern sein, z. B. Facebook Like-Schaltflächen oder Tweet-Schaltflächen. Diese können häufig Wartezeiten im Bereich von Hunderten von Millisekunden haben, was die Ladezeit Ihrer gesamten Website erheblich verkürzen kann. Dies ist jedoch kein Argument, um diese Skripte zu entfernen. Es ist wahrscheinlich wichtiger, die Social-Media-Schaltflächen auf Ihrer Website zu haben. Diese Schaltflächen nehmen normalerweise relativ wenig Platz auf Ihrer Seite ein und wirken sich daher nicht wesentlich auf die vom Besucher wahrgenommene Ladezeit aus. Dies sollten wir in erster Linie bei Geschwindigkeitsoptimierungen berücksichtigen.

Tom Gullen ist Gründer von Scirra Ltd, einem Startup, das Tools zur Erstellung von Spielen entwickelt: www.scirra.com/

Mochte dies? Lese das!