Eine langsame Website iterativ reparieren

Die Leistung einer Website ist potenziell die **wichtigste** Kennzahl. Je besser die Leistung, desto höher die Wahrscheinlichkeit, dass Nutzer auf einer Seite bleiben, Inhalte lesen, Käufe tätigen oder so ziemlich alles tun, was sie tun müssen. Eine Studie von Akamai aus dem Jahr 2017 besagt, dass selbst eine Verzögerung von 100 ms beim Laden einer Seite die Konversionen um 7 % senken und 1 % des Umsatzes kosten kann, für jede 100 ms, die das Laden ihrer Website dauert, was zum Zeitpunkt der Studie 1,6 Milliarden US-Dollar entsprach, wenn die Website nur um eine Sekunde langsamer wurde. Die Branchen-Benchmarks von Google aus dem Jahr 2018 liefern ebenfalls eine aufschlussreiche Aufschlüsselung darüber, wie jede Sekunde Ladezeit die Absprungrate beeinflusst.

Auf der anderen Seite hat Firefox seine Webseiten im Durchschnitt 2,2 Sekunden schneller geladen, was zu 60 Millionen zusätzlichen Firefox-Downloads pro Jahr führte. Die Geschwindigkeit ist auch etwas, das Google bei der Platzierung Ihrer Website in der Suche auf Mobilgeräten berücksichtigt. Eine langsame Website könnte dazu führen, dass Sie unabhängig von anderen Kennzahlen auf Seite 452 der Suchergebnisse landen.

Mit all dem im Hinterkopf dachte ich, dass die Verbesserung der Geschwindigkeit meiner eigenen Version einer langsamen Website eine unterhaltsame Übung wäre. Der Code für die Website ist auf GitHub verfügbar als Referenz.

Dies ist eine sehr einfache Website, die mit einfachem HTML, CSS und JavaScript erstellt wurde. Ich habe mich bewusst bemüht, sie so einfach wie möglich zu halten, was bedeutet, dass die Langsamkeit nichts mit der Komplexität der Website selbst oder mit einem von ihr verwendeten Framework zu tun hat. Das Komplexeste sind einige Social-Media-Buttons, mit denen die Leute die Seite teilen können.

Die Sache ist die: Leistung ist mehr als eine einmalige Aufgabe. Sie ist inhärent mit allem verbunden, was wir bauen und entwickeln. Während es also verlockend ist, alles auf einmal zu lösen, könnte der beste Ansatz zur Leistungsverbesserung ein iterativer sein. Ermitteln Sie, ob es "easy wins" gibt, und finden Sie heraus, was größere oder langfristige Anstrengungen sein könnten. Mit anderen Worten, inkrementelle Verbesserungen sind ein großartiger Weg, um Leistungssiege zu erzielen. Nochmals, jede Millisekunde zählt.

In diesem Sinne konzentriert sich der folgende Artikel mehr auf die inkrementellen Gewinne und weniger auf die Bereitstellung einer umfassenden Liste oder Checkliste von Leistungsstrategien.

Lighthouse

Wir werden mit Lighthouse arbeiten. Viele von Ihnen sind damit vielleicht schon bestens vertraut. Es wurde auch schon oft hier auf CSS-Tricks behandelt. Es ist ein Google-Dienst, der Leistung, Zugänglichkeit, SEO und Best Practices auditiert. Ich werde die Leistung meiner langsamen Website vor und nach den in diesem Artikel behandelten Dingen auditieren. Die Lighthouse-Berichte sind direkt in den Chrome-Entwicklertools zugänglich.

Schauen Sie sich kurz an, was Lighthouse an der Website bemängelt. Es ist gut zu wissen, was behoben werden muss, bevor Sie loslegen.

Das können wir definitiv beheben, also legen wir los!

Verbesserung #1: Weiterleitungen

Bevor wir etwas anderes tun, schauen wir uns an, was passiert, wenn wir die Website zum ersten Mal aufrufen. Sie wird weitergeleitet. Die Website befand sich früher unter einer URL und befindet sich jetzt unter einer anderen. Das bedeutet, dass jeder Link, der auf die alte URL verweist, zur neuen URL weitergeleitet wird.

Weiterleitungen sind oft relativ gering in Bezug auf die Latenz, die sie einer Website hinzufügen, aber sie sind ein leicht zu prüfender erster Schritt und können im Allgemeinen mit geringem Aufwand entfernt werden.

Wir können versuchen, sie zu entfernen, indem wir überall dort, wo wir die vorherige URL der Website verwenden, diese aktualisieren und auf die aktualisierte URL verweisen, damit Benutzer direkt dorthin geleitet werden, anstatt weitergeleitet zu werden. Mit einem Netzwerkinspektor werde ich sehen, ob es etwas gibt, das wir über das Netzwerk-Panel in den Entwicklertools entfernen können. Wir könnten auch ein Tool wie Postman verwenden, wenn wir müssen, aber wir werden unsere Arbeit so weit wie möglich auf die Entwicklertools beschränken, um die Einfachheit zu wahren.

Zuerst prüfen wir, ob es HTTP- oder HTML-Weiterleitungen gibt. Ich benutze gerne Fiddler, und als ich die Netzwerkanfragen inspiziere, sehe ich, dass tatsächlich einige alte URLs und Weiterleitungen herumschwirren.

Ich habe kürzlich meinen GitHub-Namen von **anonrobot** in **kealanparr** geändert, sodass alles gleich ist, außer dem Domainnamen.

Es sieht so aus, als ob die erste Anfrage, auf die wir stoßen, https://anonrobot.github.io/redirect-to-slow-site/ ist, bevor sie per HTML-Weiterleitung zu https://anonrobot.github.io/slow-site/ umgeleitet wird. Wir können alle unsere redirect-to-slow-site-URLs auf die aktualisierte URL umleiten. In den Entwicklertools hilft uns der Netzwerkinspektor auch zu sehen, was die erste Webseite tut. Aus meiner Sicht in Fiddler sieht es so aus:

Das sagt uns, dass die Website eine HTML-Weiterleitung zur nächsten Website verwendet. Ich werde meine referenzierte URL auf die neue Website aktualisieren, um die Latenz zu verringern, die die anfängliche Seitenladung verlangsamt.

Verbesserung #2: Der kritische Renderpfad

Als Nächstes werde ich die Website mit dem Leistungs-Panel in den Entwicklertools profilieren. Ich bin am meisten daran interessiert, die Website vom Rendern von Inhalten so schnell wie möglich zu befreien. Dies ist der Prozess, bei dem HTML, CSS und JavaScript in eine vollwertige, interaktive Website umgewandelt werden.

Es beginnt damit, dass das HTML vom Server abgerufen und in das Document Object Model (DOM) umgewandelt wird. Wir führen jedes Inline-JavaScript aus, sobald wir es sehen, oder laden es herunter, wenn es eine externe Ressource ist, während wir das HTML Zeile für Zeile parsen. Wir erstellen auch das CSS in das CSS Object Model (CSSOM). Das CSSOM und das DOM werden kombiniert, um den Render-Baum zu erstellen. Von dort aus führen wir das Layout aus, das alles an die richtige Stelle auf dem Bildschirm platziert, bevor schließlich das Painting erfolgt.

Dieser Prozess kann "blockiert" werden, wenn er auf Ressourcen warten muss, bevor er ausgeführt wird. Das nennen wir den **kritischen Renderpfad**, und die Dinge, die den Pfad blockieren, sind kritische Ressourcen.

Die gängigsten kritischen Ressourcen sind:

• Ein <script>-Tag, das sich im <head> befindet und kein async-, defer- oder module-Attribut enthält.
• Ein <link rel="stylesheet">, das kein disabled-Attribut hat, um dem Browser mitzuteilen, dass das CSS nicht heruntergeladen werden soll, und kein media-Attribut hat, das dem Gerät des Benutzers entspricht.

Es gibt noch ein paar weitere Ressourcentypen, die den kritischen Renderpfad blockieren können, wie z. B. Schriftarten, aber die beiden oben genannten sind mit Abstand die häufigsten. Diese Ressourcen blockieren das Rendern, weil der Browser denkt, die Seite sei "unvollendet" und wisse nicht, welche Ressourcen er benötigt oder hat. Der Browser weiß nicht, ob die Website etwas herunterladen könnte, das vom Browser noch mehr Arbeit verlangt, wie z. B. Styling oder Farbänderungen; daher ist die Website für den Browser unvollständig, und er geht vom Schlimmsten aus und blockiert das Rendern.

Eine beispielhafte CSS-Datei, die das Rendern nicht blockieren würde, wäre:

<link href="printing.css" rel="stylesheet" media="print">

Das Attribut "media="print" lädt die Stylesheet nur herunter, wenn der Benutzer die Webseite ausdruckt (weil Sie vielleicht Dinge im Druck anders gestalten möchten), was bedeutet, dass die Datei selbst nichts vom Rendern blockiert, bevor sie fertig ist.

Wie Chris gerne sagt, ist ein Frontend-Entwickler sich dessen bewusst. Und sich bewusst zu sein, was eine Seite herunterladen muss, bevor das Rendern beginnt, ist von entscheidender Bedeutung für die Verbesserung der Audit-Scores der Leistung.

Verbesserung #3: Parsing entblockieren

Das Blockieren des Renderpfads ist eine Sache, die wir sofort beschleunigen können, und wir können auch das Parsing blockieren, wenn wir bei unserem JavaScript nicht vorsichtig sind. Parsing ist das, was HTML-Elemente zu einem Teil des DOM macht, und wann immer wir auf JavaScript stoßen, das sofort ausgeführt werden muss, blockieren wir dieses HTML-Parsing.

Ein Teil des JavaScripts auf meiner langsamen Webseite muss das Parsing nicht blockieren. Mit anderen Worten, wir können die Skripte asynchron herunterladen und das Parsen des HTML in das DOM ohne Verzögerung fortsetzen.

Das <async>-Tag ermöglicht es dem Browser, das JavaScript-Asset asynchron herunterzuladen. Das <defer>-Tag führt das JavaScript erst aus, wenn der Seitenaufbau abgeschlossen ist.

Hier gibt es einen Kompromiss zwischen dem Inlining von JavaScript (damit die Ausführung keine Netzwerkanfrage erfordert) und dem Platzieren in einer eigenen JavaScript-Datei (für Modularität und Wiederverwendbarkeit des Codes). Fühlen Sie sich frei, Ihre eigene Entscheidung zu treffen, da der beste Weg vom Anwendungsfall abhängt. Die tatsächliche Leistung bei der Anwendung von CSS und JavaScript auf eine Webseite ist dieselbe, unabhängig davon, ob es sich um ein externes Asset oder um Inline-Code handelt, sobald es angekommen ist. Das Einzige, was wir beim Inlining entfernen, sind die Netzwerkanfragezeiten, um die externen Assets zu erhalten (was manchmal einen großen Unterschied macht).

Das Hauptziel, das wir anstreben, ist, so wenig wie möglich zu tun. Wir wollen Assets beim Laden verzögern und diese Assets gleichzeitig so klein wie möglich machen. All dies wird sich in einem besseren Leistungsergebnis niederschlagen.

Meine langsame Website verkettet mehrere kritische Anfragen, bei denen der Browser die nächste Zeile HTML lesen muss, warten, dann die nächste lesen, um nach einem weiteren Asset zu suchen, dann warten. Die Größe der Assets, wann sie heruntergeladen werden und ob sie blockieren, spielen alle eine riesige Rolle für die Geschwindigkeit, mit der unsere Webseite geladen werden kann.

Ich habe dies angegangen, indem ich die Website im Entwicklertools-Leistungs-Panel profiliert habe, das einfach aufzeichnet, wie die Website im Laufe der Zeit geladen wird. Ich habe kurz mein HTML und was es herunterlud durchgesehen und dann <async> zu jedem externen JavaScript-Skript hinzugefügt, das blockierte (wie das Social-Media-<script>, das nicht vor dem Rendern geladen werden muss).

Es ist interessant, dass Chrome eine Browserbeschränkung hat, bei der es nur sechs gleichzeitige HTTP-Verbindungen pro Domain verarbeiten kann und darauf wartet, dass ein Asset zurückkommt, bevor es ein weiteres anfordert, sobald diese sechs in Bearbeitung sind. Das macht die Anforderung mehrerer kritischer Assets für das HTML-Parsing noch schlimmer. Wenn der Browser weiter parsen kann, verkürzt sich die Zeit, die benötigt wird, um dem Benutzer etwas anzuzeigen, und verbessert unser Leistungs-Audit.

Verbesserung #4: Reduzieren Sie die Payload-Größe

Die Gesamtgröße einer Website ist ein entscheidender Faktor dafür, wie schnell sie geladen wird. Laut web.dev sollten Websites unter 1.600 KB interaktiv innerhalb von 10 Sekunden sein. Große Payloads korrelieren stark mit langen Ladezeiten. Sie können eine große Payload sogar als eine Ausgabe für den Endbenutzer betrachten, da große Downloads möglicherweise größere Datentarife erfordern, die mehr Geld kosten.

Zum jetzigen Zeitpunkt ist meine langsame Website satte 9.701 KB – mehr als das Sechsfache der idealen Größe. Lassen Sie uns das trimmen.

Identifizierung ungenutzter Abhängigkeiten

Zu Beginn meiner Entwicklung dachte ich, ich könnte bestimmte Assets oder Frameworks benötigen. Ich habe sie auf meine Seite heruntergeladen und kann mich jetzt nicht einmal mehr erinnern, welche davon tatsächlich verwendet werden. Ich habe definitiv einige Assets, die nichts tun, als Zeit und Platz zu verschwenden.

Mit dem Netzwerkinspektor in den Entwicklertools (oder einem Tool, mit dem Sie sich wohlfühlen) können wir einige Dinge sehen, die definitiv von der Website entfernt werden können, ohne ihr zugrundeliegendes Verhalten zu ändern. Ich fand viel Wert im Coverage-Panel in den Entwicklertools, da es zeigt, wie viel Code nach dem vollständigen Download verwendet wird.

Wie wir bereits besprochen haben, gibt es immer ein feines Gleichgewicht zwischen dem Inlining von CSS und JavaScript und der Verwendung eines externen Assets. Aber zu diesem genauen Zeitpunkt scheint es sicherlich, dass die Website weitaus mehr herunterlädt, als sie wirklich benötigt.

Eine weitere schnelle Möglichkeit, Dinge zu reduzieren, ist die Feststellung, ob eines der Assets, das die Website zu laden versucht, 404-Fehler zurückgibt. Diese Anfragen können definitiv ohne negative Auswirkungen auf die Website entfernt werden, da sie ohnehin nicht geladen werden. Hier ist, was Fiddler mir zeigt:

Wenn wir uns den Coverage-Bericht noch einmal ansehen, wissen wir, dass es Dinge gibt, die heruntergeladen werden, aber einen erheblichen Teil ungenutzten Codes, der immer noch auf die Seite gelangt. Mit anderen Worten, diese Assets tun etwas, sind aber auch bereit, Dinge zu tun, die wir nicht einmal von ihnen verlangen. Dazu gehören React, jQuery und Vue, die daher ohne wirkliche Auswirkungen von meiner langsamen Website entfernt werden können.

Warum so viele JavaScript-Bibliotheken? Nun, wir wissen, dass es reale Szenarien gibt, in denen wir zu etwas greifen, weil es unseren Anforderungen entspricht; aber dann ändern sich diese Anforderungen und wir müssen nach etwas anderem greifen. Wiederum müssen wir als Frontend-Entwickler wachsam sein, und die ständige Beobachtung, welche Ressourcen für die Website relevant sind, ist Teil dieser allgemeinen Wachsamkeit.

Assets komprimieren, minimieren und cachen

Nur weil wir ein Asset bereitstellen müssen, heißt das nicht, dass wir es in voller Größe bereitstellen oder dasselbe Asset beim nächsten Besuch des Benutzers erneut bereitstellen müssen. Wir können unsere Assets komprimieren, unsere Stile und Skripte minimieren und Dinge verantwortungsbewusst cachen, damit wir dem Benutzer das liefern, was er braucht, auf die effizienteste Weise.

• Komprimierung bedeutet, dass wir eine Datei, wie z. B. ein Bild, auf ihre kleinste Größe optimieren, ohne die visuelle Qualität zu beeinträchtigen. Zum Beispiel ist gzip ein gängiger Komprimierungsalgorithmus, der Assets kleiner macht.
• Minifizierung verbessert die Größe von textbasierten Assets, wie externen Skriptdateien, indem unnötiger Code wie Kommentare und Leerzeichen entfernt wird, um weniger Bytes über das Netz zu senden.
• Caching ermöglicht es uns, ein Asset für eine bestimmte Zeit im Speicher des Browsers zu speichern, sodass es für Benutzer bei nachfolgenden Seitenaufrufen sofort verfügbar ist. Also, einmal laden, mehrmals genießen.

Schauen wir uns drei verschiedene Arten von Assets an und wie wir sie mit diesen Taktiken bearbeiten können.

Textbasierte Assets

Dazu gehören Textdateien wie HTML, CSS und JavaScript. Wir wollen alles tun, um diese so leichtgewichtig wie möglich zu machen, also komprimieren, minimieren und cachen wir sie, wo immer möglich.

Auf sehr hohem Niveau funktioniert gzip, indem es gemeinsame, wiederholte Teile im Inhalt findet, diese Sequenzen einmal speichert und sie dann aus dem Quelltext entfernt. Es behält einen Wörterbuch-ähnlichen Lookup, sodass es die gespeicherten Teile schnell referenzieren und sie wieder an ihren Platz setzen kann, in einem Prozess, der als Gunzipping bekannt ist. Sehen Sie sich dieses mit gzip komprimierte Beispiel einer Datei an, die Gedichte enthält.

Wir tun dies, um alle textbasierten Downloads so klein wie möglich zu machen. Wir nutzen bereits gzip. Ich habe das mit diesem Tool von GIDNetwork überprüft. Es zeigt, dass der Inhalt der langsamen Website zu 59,9 % komprimiert ist. Das bedeutet wahrscheinlich, dass es weitere Möglichkeiten gibt, Dinge noch kleiner zu machen.

Ich habe beschlossen, die mehreren CSS-Dateien zu einer einzigen Datei namens styles.css zusammenzufassen. Auf diese Weise begrenzen wir die Anzahl der erforderlichen Netzwerkanfragen. Außerdem enthielt jede der drei Dateien, wenn wir sie öffneten, nur so wenig CSS, dass die drei Netzwerkanfragen einfach ungerechtfertigt sind.

Und während ich das tat, hatte ich die Gelegenheit, unnötige CSS-Selektoren zu entfernen, die nirgendwo im DOM angewendet wurden, was erneut die Anzahl der an den Benutzer gesendeten Bytes reduziert.

Ilya Grigorik schrieb einen ausgezeichneten Artikel mit Strategien für die Komprimierung von textbasierten Assets.

Bilder

Wir sind auch in der Lage, die Bilder auf der langsamen Website zu optimieren. Wie Berichte durchweg zeigen, sind Bilder die häufigsten Asset-Anfragen. Tatsächlich beträgt die mittlere Datenübertragung für Bilder von 2016 bis 2021 948,1 KB für Desktops und 902 KB für mobile Geräte. Das ist bereits mehr als die Hälfte der idealen 1.600 KB für eine gesamte Seitenladung.

Meine langsame Website liefert nicht so viele Bilder, aber die Bilder, die sie liefert, können kleiner sein. Ich habe die Bilder durch ein Online-Tool namens Squoosh laufen lassen und eine Einsparung von 40 % erzielt (von 18,6 KB auf 11,2 KB). Das ist ein Erfolg! Natürlich können Sie dies entweder vor dem Upload mit einer Desktop-Anwendung wie ImageOptim tun, oder sogar als Teil Ihres Build-Prozesses.

Ich konnte keine visuellen Unterschiede zwischen den Originalbildern und den optimierten Versionen feststellen (was großartig ist!) und ich konnte die Größe sogar weiter reduzieren, indem ich die tatsächliche Datei verkleinerte, die Qualität des Bildes reduzierte und sogar die Farbpalette änderte. Aber das sind Dinge, die ich in Bildbearbeitungssoftware gemacht habe. Idealerweise ist das etwas, das Sie oder ein Designer tun würden, wenn Sie die Assets ursprünglich erstellen.

Caching

Wir haben uns mit Minifizierung und Komprimierung befasst und was wir tun können, um diese zu unserem Vorteil zu nutzen. Das Letzte, was wir prüfen können, ist Caching.

Ich habe die langsame Website immer wieder angefordert, und bisher sehe ich, dass sie jedes Mal frisch angefordert wird, ohne jegliches Caching. Ich habe mir den HTML-Code angesehen und festgestellt, dass das Caching hier deaktiviert war:

<meta http-equiv="Cache-Control" content="no-cache, no-store, must-revalidate">

Ich habe diese Zeile entfernt, sodass das Browser-Caching nun stattfinden kann und die Inhalte noch schneller ausgeliefert werden.

Verbesserung #5: Verwenden Sie ein CDN

Eine weitere große Verbesserung, die wir bei jeder Website vornehmen können, ist die Bereitstellung so vieler Inhalte wie möglich über ein Content Delivery Network (CDN). David Attard hat einen sehr ausführlichen Beitrag darüber, wie man ein CDN hinzufügt und nutzt. Der traditionelle Weg der Inhaltsbereitstellung besteht darin, den Server anzusprechen, Daten anzufordern und auf deren Rückkehr zu warten. Aber wenn der Benutzer Daten von der anderen Seite der Welt anfordert, von wo Ihre Daten bereitgestellt werden, dann fügt das Zeit hinzu. Wenn die Bytes weiter reisen, kann die Antwort des Servers zu großen Geschwindigkeitsverlusten führen, selbst wenn alles andere blitzschnell ist.

Ein CDN ist eine Gruppe von verteilten Servern auf der ganzen Welt, die in der Lage sind, Inhalte intelligent näher am Benutzer bereitzustellen, da sie mehrere Standorte zur Auswahl haben, von denen sie liefern können.

Wir haben zuvor besprochen, wie ich den Benutzer dazu brachte, jQuery herunterzuladen, obwohl der heruntergeladene Code nicht tatsächlich verwendet wurde, und wir haben ihn entfernt. Eine einfache Lösung hier wäre, wenn ich jQuery tatsächlich benötigt hätte, das Asset von einem CDN anzufordern. Warum?

• Ein Benutzer hat das Asset möglicherweise bereits durch den Besuch einer anderen Website heruntergeladen, sodass wir eine zwischengespeicherte Antwort vom CDN bereitstellen können. 75,49 % der Top-Millionen-Websites verwenden immer noch jQuery, schließlich. Im Jahr 2020 haben Browser (Safari, Chrome) begonnen, "Cache-Partitionierung" durchzuführen, was bedeutet, dass Assets nicht zwischen verschiedenen Websites zwischengespeichert werden, sodass dieser potenzielle Vorteil wegfällt. Die Datei wird weiterhin pro Website zwischengespeichert.
• Es muss nicht so weit vom Benutzer entfernt reisen, der die Daten anfordert.

Wir können etwas so Einfaches tun, wie jQuery von Googles CDN zu beziehen, das sie jedem zur Verfügung stellen, um es auf seinen eigenen Websites zu referenzieren.

<head>
  <script src="https://ajax.googleapis.com/ajax/libs/jquery/3.5.1/jquery.min.js"></script>
</head>

Das liefert jQuery deutlich schneller als eine Standardanfrage von meinem Server, das ist sicher.

Sind die Dinge besser?

Wenn Sie bisher mit mir mitgemacht haben oder einfach nur gelesen haben, ist es an der Zeit, erneut zu profilieren und zu sehen, ob wir mit dem bisher Getanen Verbesserungen erzielt haben.

Erinnern Sie sich, wo wir angefangen haben

Nach unseren Änderungen

---

Ich hoffe, dies war hilfreich und ermutigt Sie, selbst nach inkrementellen Leistungssteigerungen auf Ihrer eigenen Website zu suchen. Indem wir Assets optimal anfordern, einige Assets beim Laden verzögern und die Gesamtgröße der Website reduzieren, stellen wir dem Benutzer so schnell wie möglich eine funktionale, vollständig interaktive Website zur Verfügung.

Möchten Sie die Konversation fortsetzen? Ich teile meine Artikel auf Twitter, wenn Sie mehr sehen oder sich vernetzen möchten.