Aufbau eines Website-Performance-Monitors

Vor ein paar Monaten schrieb ich über die Verwendung von WebPageTest, und genauer gesagt über seine RESTful API, zur Überwachung der Website-Performance. Zweifellos können die von ihm bereitgestellten Daten wertvolle Informationen für Ingenieure liefern, um verschiedene Teile eines Systems zu optimieren und es leistungsfähiger zu machen.

Aber wie passt dieses Tool genau in Ihren Entwicklungs-Workflow? Wann sollten Sie Tests durchführen und was genau tun Sie mit den Ergebnissen? Wie visualisieren Sie sie?

Da wir nun die Möglichkeit haben, Performance-Metriken programmatisch über die RESTful API zu erhalten, sollten wir uns nach Wegen umsehen, diese Daten zu speichern und ihre Entwicklung im Laufe der Zeit zu verfolgen. Das bedeutet, dass wir sehen können, wie sich die Ladezeit einer bestimmten Seite durch neue Funktionen, Assets oder Infrastrukturänderungen beeinflusst.

Ich habe mir vorgenommen, ein Tool zu erstellen, das es mir ermöglicht, all diese Informationen zu sammeln und zu visualisieren, und ich wollte es so aufbauen, dass auch andere es tun können.

Die Wunschliste

Ich wollte, dass dieses Tool in der Lage ist,

• Tests manuell auszuführen oder sie durch Dritte auslösen zu lassen, wie z. B. durch einen Webhook, der nach einem GitHub-Release-Commit ausgelöst wird
• Wiederkehrende Tests mit konfigurierbaren Zeitintervallen durchzuführen
• Mehrere URLs zu testen, mit der Möglichkeit, verschiedene Teststandorte, Geräte und Verbindungstypen zu konfigurieren
• Jede beliebige Anzahl von Performance-Metriken zu gruppieren und auf einem Diagramm anzuzeigen
• Budgets für beliebige Performance-Metriken festzulegen und diese auf den Diagrammen neben den Ergebnissen zu visualisieren
• Benachrichtigungen (E-Mail und Slack) zu konfigurieren, die gesendet werden, wenn Metriken ihr Budget überschreiten

Bevor wir weiter fortfahren, muss ich darauf hinweisen, dass es etablierte Lösungen auf dem Markt gibt, die all das oben Genannte bieten. Unternehmen wie SpeedCurve oder Calibre bieten einen professionellen Monitoring-Dienst an, den Sie ernsthaft in Erwägung ziehen sollten, wenn Sie ein Unternehmen führen. Sie verwenden private Instanzen von WebPageTest und sind nicht auf die öffentliche angewiesen, was bedeutet, keine Nutzungslimits und keine unvorhersehbare Verfügbarkeit.

Das von mir entwickelte Tool, das ich Ihnen im Laufe dieses Artikels vorstellen werde, ist eine bescheidene und kostenlose Alternative zu diesen Diensten. Ich habe es entwickelt, weil ich kein Budget habe, das es mir erlaubt, eine monatliche Gebühr für einen Performance-Monitoring-Service zu bezahlen, und ich bin sicher, dass andere Einzelpersonen, gemeinnützige Organisationen und Open-Source-Projekte im selben Boot sitzen. Mein Ziel war es, diese Art von Werkzeugen für Menschen zugänglich zu machen, die sonst vielleicht keinen Zugang dazu hätten.

Die Idee

Das von mir vorgesehene System musste drei Hauptkomponenten haben

1. Eine Anwendung, die auf Testanfragen wartet und mit der WebPageTest API kommuniziert
2. Ein Datenspeicher zur Persistenz der Testergebnisse
3. Eine Visualisierungsschicht zur Anzeige der Ergebnisse, mit einer Reihe von Diagrammen zur Darstellung der Entwicklung der verschiedenen Metriken im Laufe der Zeit

Ich wollte wirklich etwas bauen, das Menschen aller Erfahrungsstufen kostenlos einrichten und nutzen können, und das hat die Entscheidungen, die ich über die Architektur und Infrastruktur der Plattform getroffen habe, stark beeinflusst.

Es mag wie ein ungewöhnlicher Ansatz erscheinen, aber GitHub ist tatsächlich eine ziemlich interessante Wahl, um #2 und #3 zu erreichen. Mit der GitHub-API können Sie problemlos Dateien aus einem Repository lesen und in dieses schreiben, sodass Sie es effektiv als persistenten Datenspeicher nutzen können. Darüber hinaus macht GitHub Pages dasselbe Repository zu einem großartigen Ort, um eine Website zu hosten. Sie erhalten einen schnellen und sicheren Hosting-Service mit der Option, eine benutzerdefinierte Domain zu verwenden. All dies ist kostenlos, wenn Sie mit einem öffentlichen Repository einverstanden sind.

Für #1 habe ich eine kleine Node.js-Anwendung entwickelt, die Testanfragen empfängt, an WebPageTest sendet, die Ergebnisse abruft und sie als Datendateien in ein GitHub-Repository pusht, die dann von der Visualisierungsschicht übernommen werden. Diesen Ansatz habe ich bereits bei der Entwicklung von Staticman verwendet und er hat sehr gut funktioniert.

Das folgende Diagramm zeigt die Grundidee.

Ach ja, irgendwann brauchte ich einen Namen. Ich nannte es SpeedTracker.

Sie können es in Aktion sehen hier oder direkt mit der Nutzung beginnen, indem Sie diesem Link folgen. Wenn Sie mehr darüber erfahren möchten, wie es im Detail funktioniert, wie es entwickelt wurde und wohin ich es führen sehe, dann lesen Sie weiter.

Aufbau des Dashboards

Ich bin ein großer Fan von Jekyll. Für diejenigen unter Ihnen, die es nicht kennen: Jekyll ist ein Programm, das strukturierte Inhalte aus Dateien in verschiedenen Formaten (Markdown, JSON, YAML oder sogar CSV) nimmt und HTML-Seiten generiert. Es ist Teil einer größeren Familie von statischen Website-Generatoren.

Es ist für dieses Projekt besonders relevant wegen seiner nativen Integration mit GitHub Pages, die es jedem Repository ermöglicht, automatisch eine Jekyll-Website zu erstellen, jedes Mal, wenn es neue oder aktualisierte Inhalte erhält, und die generierten HTML-Dateien sofort unter einer bestimmten URL zu hosten. In diesem Sinne könnte ich die API-Schicht so gestalten, dass sie die Testergebnisse in JSON-Dateien schreibt und Jekyll diese dann liest und auf einer Webseite ausgibt.

Durch die Speicherung der Daten in einem GitHub-Repository geben wir den Nutzern die Kontrolle über ihre Daten. Sie sind nicht irgendwo in der Datenbank eines Dienstes versteckt, sondern in einem kostenlosen, offenen Repository, das einfach als ZIP-Datei heruntergeladen werden kann. Und durch die Verwendung von JSON wählen wir ein universell anerkanntes Format für die Daten, was die Wiederverwendung an anderer Stelle erleichtert.

Um die Anforderung zu erfüllen, mehrere Websites mit unterschiedlichen Geräten, Verbindungstypen und Standorten testen zu können, habe ich das Konzept der Profile eingeführt. Jeder Test muss gegen ein Profil ausgeführt werden, das aus einer Datei besteht (Beispiel ansehen), die Informationen über die zu testende URL und alle an WebPageTest zu übergebenden Parameter enthält.

In dieser Datei können Sie auch ein Intervall in Stunden definieren, in dem die Tests für das jeweilige Profil wiederholt werden. Sie können diesen Wert ändern oder geplante Tests ganz entfernen, indem Sie die Eigenschaft interval in der Profildatei ändern.

Die Herausforderung bestand nun darin, Ergebnisse für mehrere Profile zu liefern und eine grundlegende Datumsfilterung (wie z. B. die Möglichkeit, Ergebnisse der letzten Woche, des letzten Monats oder des letzten Jahres anzuzeigen) von einer statischen Website aus bereitzustellen, die von einer Reihe von JSON-Dateien gesichert wird. Ich konnte nicht einfach Jekyll alle Datensätze auf einer Seite ausgeben lassen, da die generierten HTML-Dateien sonst schnell unerschwinglich groß werden würden.

Jekyll trifft React

Ich begann damit, die Dateien in einer Ordner- und Dateistruktur zu organisieren, sodass die Testergebnisse nach Datum und Profil gruppiert wurden. Jekyll konnte diese Struktur durchlaufen und eine Liste aller verfügbaren Datendateien für jede Website zusammen mit ihren vollständigen Pfaden generieren.

Mit dieser Liste konnte ich eine clientseitige Anwendung erstellen, die, gegeben ein Profil und einen Datumsbereich, asynchron nur die für die Anzeige der betroffenen Ergebnisse benötigten Dateien abrufen, die verschiedenen Metriken extrahieren und kompilieren und sie in einer Reihe von interaktiven Diagrammen darstellen konnte.

Das habe ich mit React umgesetzt.

Performance-Budgets

Ein guter Weg, um ein Team für Web-Performance zu sensibilisieren, ist die Definition von Budgets für eine oder mehrere Metriken und deren konsequente Einhaltung. Tim Kadlec erklärt es in diesem Artikel weitaus besser als ich es je könnte, aber die Grundidee ist, dass Sie festlegen, dass Ihre Website auf einer bestimmten Verbindungstyp unter einer bestimmten Zeit geladen werden muss.

Diese Schwelle muss dann jedes Mal berücksichtigt werden, wenn Sie planen, ein neues Feature oder Asset zur Website hinzuzufügen. Wenn die neue Ergänzung das Budget überschreitet, müssen Sie sie aufgeben oder einen Weg finden, eine bestehende Funktion oder ein Asset zu entfernen oder zu optimieren, um Platz für das neue zu schaffen.

Ich wollte Budgets einen prominenten Platz auf der Plattform einräumen. Beim Erstellen eines Profils können Sie ein Budget für jede der erfassten Metriken festlegen, und eine horizontale Linie wird in dem jeweiligen Diagramm neben den Daten angezeigt, was Ihnen eine visuelle Anzeige gibt, wie gut Ihre Website abschneidet.

Es ist auch möglich, Benachrichtigungen zu definieren, die ausgelöst werden, wenn eines der Budgets überschritten wird, damit Sie und Ihr Team sofort per E-Mail oder Slack benachrichtigt werden können, wenn die Dinge nicht so gut aussehen.

Ein zentralisierter Dienst

Die Kernidee hinter diesem Projekt war, diese Art von Werkzeugen für jedermann kostenlos und zugänglich zu machen. Open-Source zu machen ist offensichtlich ein großer erster Schritt, und die Tatsache, dass man kostenlose Dienste nutzen kann, um sowohl das Frontend (GitHub Pages oder Netlify) als auch das Backend (Heroku oder now) bereitzustellen, hilft definitiv. Aber trotzdem hatte ich das Gefühl, dass die Installation und Bereitstellung der API-Schicht für weniger erfahrene Leute Hürden darstellen würde.

Aus diesem Grund habe ich die Anwendung so aufgebaut, dass eine einzige Instanz verwendet werden kann, um Testergebnisse für mehrere Websites und GitHub-Repositories bereitzustellen. Sie kann also effektiv als zentralisierter Dienst fungieren, den viele Leute nutzen können. Es gibt einen Server, der eine öffentliche Instanz der API ausführt, die jedem kostenlos zur Verfügung steht.

Das bedeutet, dass Sie alles, was Sie brauchen, um loszulegen, ist, die Jekyll-Website in einem GitHub-Repository zu installieren, den Benutzernamen speedtracker-bot als Mitarbeiter hinzuzufügen, ein Profil und ein paar andere Dinge zu konfigurieren, und schon sind Sie bereit.

Das folgende Screencast kann Sie durch den Prozess führen.

Wie geht es weiter?

Wenn dieses Tool einigen von Ihnen hilft, die Performance ihrer Websites zu verbessern, werde ich sehr glücklich sein. Wenn Sie es nutzen und beschließen, Ihre Zeit zu spenden, um es für alle besser zu machen, werde ich noch glücklicher sein!

Sofort fallen mir einige Dinge ein, die ich gerne sehen würde

• Unterstützung für Annotationen in den Diagrammen hinzufügen, um bestimmte Ereignisse zu markieren, wie z. B. eine infrastrukturelle Änderung oder die Veröffentlichung eines wichtigen Features
• Es ist bereits möglich, einen GitHub-Webhook zu haben, der einen neuen Test auslöst, aber wir könnten einen Schritt weiter gehen und die Inhalte der Webhook-Payload tatsächlich lesen, um Annotationen in den Diagrammen zu erstellen, die einen Commit oder Release markieren
• Die Anzeige von benutzerdefinierten Metriken erleichtern
• Unterstützung für Scripting hinzufügen
• Bessere Dokumentation und Tests

Wenn Sie das Gefühl haben, helfen zu können, dann machen Sie mit. Wenn Sie Fragen haben oder Schwierigkeiten beim Einstieg haben, schicken Sie mir einen Tweet.

Viel Spaß beim Testen!