Die Front-End-Performance-Herausforderung: Gewinner und Ergebnisse

Vor einigen Wochen haben wir unsere Leser und die Community gebeten, alles zu tun, um ihre Websites und Projekte blitzschnell zu machen. Heute freuen wir uns, die Ergebnisse dieser Herausforderung zu zeigen und den Gewinner bekannt zu geben, der in der Tat mit einigen tollen Preisen ausgezeichnet wird!

Welche Preise, fragen Sie? Der Gewinner gewinnt einen Hin- und Rückflug nach London, eine komplette Unterkunft in einem schicken Hotel, ein Ticket zur SmashingConf London 2018 und nicht zuletzt einen Smashing-Workshop seiner Wahl.

Herausforderung? Welche Herausforderung?

Nun, die Aufgabe war nicht so einfach, wie sie sich anhörte. Die Teilnehmer wurden gebeten, die Leistung einer Website zu verbessern und gleichzeitig das endgültige visuelle Erscheinungsbild vorher und nachher identisch zu halten. Das Laden von Schriftarten durfte unterschiedlich sein, und Umbrüche waren akzeptabel, solange sie auf einem Minimum gehalten wurden.

Bei der Auswahl des glücklichen Gewinners haben wir uns die Ergebnisse von Lighthouse und WebPageTest sowie natürlich die Komplexität der Websites angesehen, an denen unsere Teilnehmer gearbeitet haben. Die erste aussagekräftige Farbe und die Zeit bis zur Interaktion waren die kritischsten Metriken.

Aber jetzt genug harte Fakten. Wir wissen, dass Sie bereits neugierig sind, und wir möchten Sie nicht länger in der Schwebe halten. Hier ist es also, das Siegerprojekt.

Und der Gewinner ist…

Leonardo Losoviz

Die in Leonardos Einreichung vorgestellten Optimierungstechniken sind alle DIY, entworfen und implementiert von Grund auf neu. Er fügte alle Optimierungen zu PoP hinzu, einem Open-Source-Framework zum Erstellen von Websites, und verwendete Agenda Urbana, um die Leistungsverbesserungen in einem tatsächlichen Projekt zu testen.

Wir waren der Meinung, dass diese Einreichung wirklich dem Geist der Herausforderung entsprach, indem sie nicht nur die Leistung einer einzelnen Website verbesserte, sondern auch versuchte, Verbesserungen an einem Framework vorzunehmen, das auf einer Reihe von Websites verwendet wird. Die Tatsache, dass PoP von WordPress unterstützt wird, bedeutete, dass sich Leonardo in einer ähnlichen Situation befand wie viele Menschen, die einige der Dinge, die für ein JavaScript-Framework verfügbar sind, nicht ausführen konnten. Wie er feststellte:

PoP basiert auf WordPress. Das bedeutet, dass viele innovative Optimierungstechniken, die Javascript-Frameworks zur Verfügung stehen, wie z. B. Code-Splitting mit Webpack oder Service Workers über sw-precache, unerreichbar sind (zumindest ohne große Problemumgehung). Daher sind alle unten beschriebenen Optimierungstechniken alle DIY, die von Grund auf neu entworfen und implementiert wurden.

Wenn Sie daran interessiert sind, in alle wesentlichen Details seines Beitrags einzudringen, können Sie dies gerne tun. Wir alle haben es genossen, die Details von Leonardos Optimierungen zu lesen, und hielten ihn aufgrund der schieren Menge an Arbeit, die in diesen Eintrag geflossen war, für einen würdigen Gewinner.

Alle Einreichungen

Wir waren sehr zufrieden mit der Qualität der Einsendungen, die wir erhalten haben, und es war ehrlich gesagt nicht einfach, einen Gewinner auszuwählen. Vielen Dank an alle anderen Einsender – macht weiter so!

Jörg Verweij

Jorgen Verweij präsentierte eine optimierte Version seiner Firmenwebsite Perplex Internetmarketing BV. Zusammen mit einem Team aus einem UX'er, einem Front-End- und einem Back-End-Entwickler sowie einem Systemadministrator machte er sich auf den Weg zur Performance.

Das Ergebnis ist eine hervorragende Implementierung mit hervorragenden Leistungsergebnissen auf ganzer Linie: SpeedIndex weit unter dem gesetzten Ziel von 1250, eine Ladezeit von weniger als 1 Sekunde, Start-Rendering in einer halben Sekunde, ein ¹⁰⁰ ⁄ ₁₀₀ PageSpeedscore und ein nahezu perfektes Lighthouse-Audit . Im Vergleich zur alten Situation ist die Ladezeit fast achtmal schneller. Hut ab! Sie können weitere Details über den Prozess in diesem umfassenden Bericht lesen, den Jorgen zusammengestellt hat.

Marco Hengstenberg

Marco Hengstenberg hat eine optimierte Version der Tourismusagentur-Website Land in Sicht eingereicht. Um die Leistung zu verbessern, hat Marco eine Menge raffinierter kleiner Tricks und Techniken angewendet. Das Vorabladen des Haupt-Stylesheets und das Laden kritischer Schriftarten mit Vorabladen in unterstützenden Browsern sind nur zwei davon. Er strukturierte auch den HTML-Code um, um ihn so flach, semantisch und zugänglich wie möglich zu machen, und reduzierte die anfänglich beim ersten Besuch übertragene Datenmenge von fast 3 MB auf 1,3 MB auf dem Desktop (und aufgrund der Verwendung von responsiven Bildern für das Hero-Bild, es ist sogar noch geringer als bei schmalen Bildschirmen).

Um die Seite noch weiter zu rationalisieren, entfernte Marco Bootstrap, jQuery und Modernizr, richtete einen Build-Prozess mit Grunt ein und führte einen ServiceWorker ein, der die Seite auch offline verfügbar macht. Der Aufwand hat sich gelohnt: Das Ergebnis ist eine dramatische TTL, die von 32 Sekunden auf 2 Sekunden gesunken ist, und eine fast 50-prozentige Verringerung der HTTP-Anfragen und übertragenen Bytes (siehe auch den Lighthouse-Bericht, ZIP 251KB). Vorladen und schnelles anfängliches Rendern tragen beide zur wahrgenommenen Ladezeit bei. Gute Arbeit!

Gabriel Mariani

Die Website des San Diego Christian College war diejenige, auf der Gabriel Mariani seine Performance-Fähigkeiten anwandte. Er unterteilte den Optimierungsprozess in vier Schritte. Zunächst schnitt er alle Bilder auf die maximale Größe zu, in der sie tatsächlich benötigt wurden, und erstellte mobil skalierte Versionen davon. Er hat dann alle Bilder lazy load gemacht. Der zweite Schritt konzentrierte sich auf JavaScript und das Entfernen aller Inline-Skripte, mit denen die WordPress-Site und ihre Themes und Plugins von Drittanbietern geliefert wurden. Dann stellte er so viele Skripte wie möglich in die Warteschlange, damit Autoptimize sie aufnehmen und zu einer einzigen Datei verkleinern/kombinieren konnte.

Gabriel hat auch die Anzahl der verwendeten Schriftarten reduziert und die Google-Schriftarten so eingestellt, dass sie async geladen werden, sodass das CSS des kritischen Pfads zuerst geladen wird. Zu guter Letzt ging er auf einige andere Kleinigkeiten ein, wie das Anpassen von WordPress-Plugins, sodass sie auf Ajax statt auf PHP setzen. Dadurch konnte er das Seiten-Caching aktivieren und schließlich ein CDN für die Website aktivieren. Eine Umstellung auf HTTP/2 und HTTPS war der letzte Schritt. Siehe WebPageTest für die vollständigen Ergebnisse. Hübsch!

Alexander Zarge

Alexander Zarges hat Cloud Player entwickelt, eine auf Angular 4 basierende Single-Page-Webanwendung, mit der Sie YouTube- und SoundCloud-Apps suchen und abspielen können. Die aktualisierte Version verwendet den Angular-Ahead-of-Time-Compiler, um eine Initialisierungszeit von etwa 2,9 Sekunden zu erreichen (im Vergleich zu 5,2 Sekunden bei Verwendung des Just-in-Time-Compilers). Wenn Sie tiefer in den Code eintauchen möchten, sehen Sie sich das begleitende GitHub-Repository an.

Bradly Spott

Bradley Taunt nahm unsere Herausforderung zum Anlass, mit seiner persönlichen Seite zu experimentieren. Als Grundlage für sein Optimierungsvorhaben diente ihm seine Homepage und ein bildlastiger Artikel. Um die Ladezeit des Artikels auf 4,2 Sekunden zu verkürzen, verwendet Bradley unter anderem standardmäßig die OS System Fonts des Benutzers, anstatt Webfonts zu verwenden.

Für einen zusätzlichen Schub integriert die optimierte Version auch kritisches CSS, stellt responsive Bilder bereit und nutzt CDN-Caching. Einen detaillierteren Blick hinter die Kulissen erhalten Sie in dem Blogbeitrag, den Bradley darüber geschrieben hat, wie er die Herausforderung gemeistert hat.

John Beales

John Beales hat sich selbst herausgefordert, 4RoadService.com einen Leistungsschub zu geben. Als er anfing, gab es bereits einige Optimierungen. Statische Bilder wurden beispielsweise über ImageOptim ausgeführt, CSS und JS wurden minimiert, sie führten ein CDN über CloudFlare aus, und die Site verwendete bereits einen Single-Page-App-Style-Loader, sodass neue Inhalte immer von XHR abgerufen werden und die Seite ist nie komplett neu gezeichnet.

Für diese Herausforderung hat John die Bildoptimierung und die WebP-Komprimierung in Cloudflare aktiviert. Die aktualisierte Website verwendet jetzt HTTP/2 Server Push, um die wichtigsten CSS- und JS-Dateien beim anfänglichen Laden der Seite zu versenden, und verlässt sich für die JPEG-Komprimierung auf Guetzli. Um das Caching zu optimieren, aktualisierte er die URLs aller statischen Assets, sodass sich die URL bei jeder Änderung des Assets ändert, und legte dann fest, dass alle statischen Assets ein Jahr lang zwischengespeichert werden. Für ein verbessertes Bild-Caching hat John auch die URLs von dynamisch angepassten Bildern aktualisiert, sodass CloudFlare denkt, dass es sich um statische Bilddateien handelt.

Das Ergebnis: Das erste sinnvolle Paint fiel von 2.220 ms auf 1.290 ms und das First Interactive von 5.480 ms auf 3.040 ms. Die vollständigen Ergebnisse des Lightbox- und Webseiten-Tests können Sie hier einsehen.

Shaun O’Connell

Shaun O'Connels Eintrag war die Arbeit, die er auf kiwi.ruby.nz gemacht hat. Ziel war es, die Konferenz-Website in eine PWA umzuwandeln, damit Konferenzteilnehmer alle Informationen zur Veranstaltung offline abrufen können. Einige der Dinge, die er getan hat: Ersetzen eines typischen Google Maps-Iframes durch Google Static Maps, selbsthostende Untergruppen von Schriftarten, Verschieben von CSS inline, um die erste Anfrage unter 14 KB zu halten, Entfernen von Abhängigkeiten, Hinzufügen von Pre-Cache-Service-Workern und Hinzufügen von Turbolinks für Snappy Seitenübergänge. Dadurch sank die anfängliche Renderzeit von 3,9 Sekunden auf 0,3 Sekunden.

Weitere Einzelheiten finden Sie in den WebPageTests.

Ruslan Julbarissow

Ruslan Julbarissow reichte seine persönliche Website zerofy.de ein. Da er seine Optimierungsarbeit kurz vor der Veröffentlichung des Wettbewerbs abgeschlossen hat, gibt es leider keine detaillierten Vorher-Ergebnisse, aber Ruslan hat gut aufgeschrieben, wie seine Optimierungen zu einer Seitengröße von 1,6 KB und einer TTFB von 197 ms führten. Abgesehen von Caching, Minimierung, GZIP- und jQuery-Optimierungen lädt er anschließend Schriftarten, um eine Renderblockierung zu vermeiden, und indem er FontAwesome durch einen benutzerdefinierten IcoMoon-Satz von 10 Symbolen ersetzte, gelang es ihm, weitere 130 KB einzusparen.

Um den Speed-Index-Score zu erhöhen und das schnellstmögliche Erlebnis zu erzielen, erstellte er außerdem eine separate PHP-Datei, die alle CSS-Stile enthält, die sich auf die „above the fold“-Ansicht auswirken. Nettes Detail: Mit dem winzigen Skript Barba.js kann er Seitenübergänge erstellen, ohne die ganze Seite neu zu laden.

Vielen Dank an alle für die Teilnahme

Puh! Das war in der Tat eine ziemliche Herausforderung! Für diejenigen unter Ihnen, die hin und wieder eine so gute Herausforderung und einen Gehirnkitzel genießen, bleiben Sie dran für die nächste Herausforderung. Wir werden uns in kürzester Zeit ein weiteres einfallen lassen – das ist sicher!