Es gibt ein technisches Audit, um die Geschwindigkeit des Standorts zu überprüfen und die Ursachen für Verzögerungen zu ermitteln. Es wird empfohlen, dies auch dann durchzuführen, wenn das System ordnungsgemäß zu funktionieren scheint und keine Leistungsprobleme vorliegen. Tatsache ist, dass es noch verbessert werden kann: Durch die Optimierung der Infrastruktur wird die Bereitstellung des Codes beschleunigt, und durch die Umgestaltung der Codebasis können die Wartungskosten gesenkt werden.
In diesem Artikel zeigen wir am Beispiel einer beliebten Nachrichtenressource, die von Zehntausenden von Benutzern pro Stunde besucht wird, wie eine technische Prüfung einer Website abläuft. Betrachten wir die unabhängigen Phasen der Überprüfung und Analyse. Als Ergebnis zeigen wir deutlich, wie Sie das Projekt verbessern und Engpässe beseitigen können, die das Laden von Seiten verlangsamen.
Erfassung von Metriken und Analyse statischer Site-Ressourcen
Stellen Sie sicher, dass Sie Metriken sammeln und alles messen, was Sie mit vorgefertigten Tools wie Google Page Speed, Lighthouse und Web.dev können. Dies ist der schnellste Weg, um Metriken zu erhalten, die als Ausgangspunkt für Ihre Forschung dienen. Mit ihrer Hilfe werden Sie verstehen, worauf es an erster Stelle ankommt, was optimiert werden kann.
Wir empfehlen Ihnen, die Analyse bei ein- und ausgeschaltetem Werbeblocker durchzuführen. Als Ergebnis erfahren Sie, wie schnell das erste Rendern von Inhalten erfolgt und wie viele Skripts von Drittanbietern auf der Site verbunden sind.
In dieser Phase sehen Sie auch, wie viele grundlegende Vorgänge beim Rendern der Site ausgeführt werden:
Die gesammelten Metriken geben wahrscheinlich Platz für die Verbesserung statischer Site-Assets an: Bilder, Videos, Skripte, Stile und Schriftarten. Analysieren Sie diese Daten und stellen Sie sicher, dass Sie die allgemeinen Vorgehensweisen für die Arbeit mit statischen Ressourcen befolgen. Denken Sie jedoch daran, dass dies nur Richtlinien sind, keine strengen Anforderungen.
In unserem Beispiel werden alle Bilder im JPG-Format gespeichert. Wenn Sie webp verwenden, das von Browsern perfekt unterstützt wird, wird die Dateigröße um durchschnittlich 20% reduziert. Sie können die automatische Webp-Komprimierung nur für hochauflösende Bilder konfigurieren. Es wird empfohlen, hochauflösende Videos für Browser, die dieses Format unterstützen, in webm zu konvertieren. Um die Belastung des Netzwerks zu verringern, ist es ratsam, die automatische Wiedergabe von Videos zu deaktivieren, die nicht sichtbar sind. Dies kann mithilfe der Intersection Observer-API erfolgen.
Stellen Sie sicher, dass Ihre Site über progressive Downloads verfügt, und fügen Sie nach Möglichkeit überall Komprimierung hinzu. Stellen Sie sicher, dass Sie moderne Skriptkomprimierungstechniken wie brotli, gzip und deflate verwenden.
Laden Sie nicht, was nicht verwendet wird. Dies kann für Code, Stile, Symbole und Bilder gelten. Wenn die Site beispielsweise über eine Schaltfläche verfügt, die in einem von tausend Fällen angezeigt wird, sollte das Skript, das sie verarbeitet, nur bei Bedarf verbunden werden.
Im obigen Beispiel sehen Sie, dass ~ 93% des gesamten Codes nicht verwendet werden (~ 340 kb). Ein Bundle mit einem Code wird als ideal angesehen, wenn seine Abdeckung 100% beträgt, während alle Fälle abgedeckt werden, ohne die Seite neu zu laden. Dies kann passieren, wenn der Code überhaupt nicht verwendet wird oder wenn die Codeaufteilung falsch konfiguriert ist oder wenn er verwendet wird, aber auf anderen Seiten oder wenn ein bestimmtes Szenario erreicht ist.
Die Lösung für dieses Problem besteht darin, die wiederverwendbaren Komponenten in separate Dateien (Chunks) zu verschieben, die dann nur an den Stellen verbunden werden, an denen sie benötigt werden.
Wie bereits erwähnt, sind diese Anforderungen optional, aber die Optimierung statischer Ressourcen ist wichtig, da der Benutzer sie zuerst bemerkt.
Nehmen wir als Beispiel Schriftarten - bei diesem Projekt dauerte das Laden zu lange. Da wir nicht möchten, dass der Benutzer Standardschriftarten sieht, laden wir sie ganz am Anfang im Abschnitt "Critical-CSS". Wie kann man dieses Problem lösen? Sie können Schriftarten auf Codeebene optimieren, die Verbindungsreihenfolge ändern und ttf durch woff2 ersetzen.
Sie können auch versuchen, die Anzahl der verwendeten Schriftarten zu reduzieren, was zu einer Neugestaltung führt. Dies ist jedoch nicht immer gerechtfertigt. Wenn die Website die Google Fonts-Bibliothek verwendet und nicht verwendete Zeichen aus den Dateien entfernt, ist dies nicht urheberrechtlich geschützt.
Aber manchmal ist es einfacher, die Dinge so zu lassen, wie sie sind, und sich auf andere Möglichkeiten zu konzentrieren.
Untersuchen von HTTP-Anforderungen
In diesem Stadium prüfen wir, ob das Frontend korrekt mit dem Backend interagiert, nämlich:
- konfigurierte Komprimierung für API-Anforderungen;
- Es gibt keine parasitären Abfragen, die die Verbindung laden, deren Ergebnisse nirgendwo verwendet werden.
- Es gibt keine Anforderungen, die mit einem Fehler zurückgegeben werden, ohne dass der Benutzer einen bestimmten Geschäftsfall abgeschlossen hat.
- Beim erstmaligen Laden der Seite sendet der Browser keine Anforderungen an die API (wenn die Site wie in unserem Beispiel serverseitiges Rendering verwendet).
- Es gibt keine doppelten Anforderungen. Wenn beim Aufrufen einer Seite eine Anfrage gestellt wird, ist es besser, diese einmal zu senden und die Daten zur Wiederverwendung zu speichern.
- pending , . , , , . , — , .
Blockierte Anforderungen werden rot hervorgehoben, aber die Site funktioniert weiterhin.
Bei der Analyse von Anforderungen können auch Fehler auftreten. Auf diese Weise ist der falsche Betrieb der Frontend-Anwendung aufgetreten, bei dem mehr als 100 Anforderungen pro Sekunde gesendet werden konnten, wodurch der Server stark belastet wurde. Der Bildschirm blinkte, der Lader drehte sich endlos usw. Der Grund wurde in einer falsch implementierten Schriftrolle versteckt. Der Browser behielt seine Position am Ende der Seite bei, wenn neue Elemente angezeigt wurden. Das heißt, beim Scrollen durch die Seite wurde ein Loader gestartet, aufgrund dessen die Seite nach unten verschoben wurde. Der Javascript-Handler hat die Anforderung erneut gesendet, was wiederum die Loader-Animation erneut verursachte, aufgrund derer sich die Seitengröße geändert hat, und so weiter bis ins Unendliche.
Aufgrund einer fehlerhaften Bedienung des Loaders wächst die Anzahl der Anforderungen unendlich
Analyse externer Skripte und Ressourcen
In dieser Phase sollten Sie festlegen, welche Ressourcen von Websites von Drittanbietern am längsten geladen werden.
Im modernen Web können Sie Downloads priorisieren. Oft werden Metriken und Anzeigen geladen, bevor die Seite angezeigt wird. Dies ist an sich nicht sinnvoll, da der Nutzer die Anzeige immer noch nicht sehen kann, das Laden der Website jedoch länger dauert. Wir empfehlen, Anzeigen sofort nach dem Rendern der Website zu schalten, da dies die Statistiken in keiner Weise beeinflusst. Andernfalls wird dem Nutzer für einige Zeit ein weißer Bildschirm angezeigt.
Profiling-Seiten
Verwenden Sie die Chrome Dev-Tools, um Ihre Websiteseiten zu profilieren und lange Anforderungen und eine erhöhte CPU-Auslastung zu verfolgen. Als Ergebnis sehen Sie, was die Site deutlich lädt.
Der Screenshot zeigt, dass das Laden von Jquery 19 Millisekunden dauert, was derzeit nicht benötigt wird. Besser ist es, jquery nach Hauptressourcen zu laden, vorzugsweise nach einem erfolgreichen Ladeereignis (z. B. Onload, Domcontentloaded).
Analyse der Anzahl und Dauer von Anfragen
In diesem Stadium werden wir untersuchen, wie das Frontend mit dem Backend interagiert. Dazu müssen Sie die Anzahl und Dauer aller Anfragen analysieren. Um ein vollständigeres Bild zu erhalten, müssen Sie die durchschnittliche Antwortzeit für eine Anfrage und für parallele Anfragen messen.
Kombinieren Sie aus Gründen der Übersichtlichkeit die erhaltenen Daten zu einem Übersichtsdiagramm. Auf diese Weise können Sie schnell feststellen, welche Abfragen viel länger dauern als andere.
Wenn die Site auf einem leistungsstarken Server installiert ist, sollte die Ausführungszeit für 100 parallele Anforderungen die Ausführungszeit für eine Anforderung nicht wesentlich überschreiten. Im Beispiel sehen wir einen 30-fachen Unterschied. Die am längsten laufenden Abfragen sollten zuerst untersucht werden.
In diesem Projekt trat bei einigen Anforderungen ein Gateway-Timeout auf, dh die Antwort vom Server kam überhaupt nicht.
Overhead bei Hochlastprojekten ist normal. Sie sollten jedoch nach Möglichkeit versuchen, Anforderungen in ihre Bestandteile zu zerlegen, wenn eine Anforderung für mehrere Aktionen verantwortlich ist. Führen Sie diese Teile in parallelen Threads aus.
Was kann getan werden, um den Server zu verbessern? Verbinden Sie die Bibliothek, um den Server zu überwachen und die Anwendung neu zu starten (im Fall von node.js ist dies pm2). Es wird auch empfohlen, ein Fehlerüberwachungstool wie Sentry anzuschließen. Konfigurieren Sie die Fehlerausgabe und die Absturzprotokollierung. Auf diese Weise können Sie Ausfallzeiten für Ihre Anwendung verfolgen.
Richten Sie im Idealfall einen asynchronen Protokollierer ein, um alle Aktivitäten auf der Site zu überwachen (API-Anforderungen, Anforderungen an die Datenbank, externe APIs, an das Dateisystem oder Dienste für die Arbeit mit dem Dateisystem), der sie in einer separaten Datenbank protokolliert.
Statische Analyse des Quellcodes
Diese Analyse wird von Dienstprogrammen durchgeführt, die auf den falschen Code hinweisen und dabei helfen, den "toten Code" zu beseitigen. Es ist erwähnenswert, dass diese Tools während der Entwicklung automatisch verwendet werden sollten, aber Sie müssen sich nicht immer auf die Integrität der Entwickler verlassen, daher ist es am besten, diese Prüfung nicht zu überspringen.
Um statische Analysen durchzuführen, müssen Sie Eslint-Linters und andere Dienstprogramme zur Codeformatierung wie Prettier und Sonar verwenden, mit denen Codeverletzungen verfolgt werden.
Infolgedessen können Sie basierend auf den identifizierten Verstößen ein Dokument erstellen:
Normalerweise beeinträchtigen solche Verstöße die Leistung der Website nicht, erschweren jedoch das Lesen und Schreiben des Codes, was bedeutet, dass die Wartung teurer wird. Zum Beispiel haben wir bei diesem Projekt eine Funktion gefunden, bei der es drei Argumente gab, von denen eines nicht verwendet wurde - solche Kleinigkeiten zusammen erhöhen die technische Verschuldung des Projekts.
Semantische Analyse des Quellcodes
Zu diesem Zeitpunkt muss der Programmierer die Projektdateien manuell untersuchen. Es ist erwähnenswert, dass nur offensichtliche Fehler im Verhalten des Quellcodes ausgewertet werden. Für eine eingehendere Analyse müssen Sie die Logik des Projekts gut kennen. In dieser Phase finden Sie sich wiederholenden Code, der an eine Stelle (Klasse, Funktion oder Konstante) verschoben werden kann, um die Anzahl der Zeilen zu verringern und reduzieren Sie die Möglichkeit von Fehlern.
Manchmal hilft diese Analyse festzustellen, ob das Entwicklungsteam Probleme hat. Anhand von Codezeilen von Git können Sie bestimmen, wer der Autor ist, und die Leistung einzelner Mitarbeiter bestimmen. Möglicherweise bezieht sich mehr als die Hälfte der Kommentare auf einen Entwickler.
Hier haben wir beispielsweise zehn asynchrone Vorgänge identifiziert, die die Datenbank aktualisieren, die jedoch einzeln ausgeführt wurden, ohne miteinander verbunden zu sein. Dies bedeutet, dass ihre Leistung verdoppelt werden kann, indem sie parallel ausgeführt werden. Verwenden Sie nach Möglichkeit Parallelität, da Sie selbst in aktuellen PHP-Versionen die künstliche Parallelität optimieren können, um die Systemleistung zu verbessern.
Ergebnis
Die Softwareentwicklung birgt viele Risiken, und in der Realität müssen Sie häufig Kompromisse eingehen, um ein Projekt pünktlich zum Laufen zu bringen. Daher wird die Dokumentation in der Regel rückwirkend erstellt und die Optimierung der Website bis zum allerletzten Moment verschoben.
Es ist jedoch nie zu spät, um Leistungsverbesserungen in Angriff zu nehmen. Durch die Beschleunigung Ihrer Website wird die Benutzererfahrung verbessert und eine positive Reaktion des Publikums erzielt. Mithilfe eines technischen Audits können Sie feststellen, was zu Verzögerungen bei der Arbeit der Site führt - einer Front-End- oder Back-End-Anwendung. Hier wurden Empfehlungen zur Durchführung eines Frontend-Audits gesammelt. Sie sind allgemeiner Natur und eignen sich zum Testen jedes Standorts.
In unserer nächsten Veröffentlichung erfahren Sie in Kürze, wie Sie ein technisches Audit des Backends durchführen.