Zusammenfassung
Google+ ist responsiv.
Responsive Anzeigen
Auf Google+ kommen Menschen über gemeinsame Interessen zusammen, von Zombie Cats bis hin zu Vintage-Rechnern. Bis vor Kurzem gab es auf Google+ zwei verschiedene Versionen der Website: eine für Computer und eine für das mobile Web, die für ältere Browser entwickelt wurde.
Challenges
Die Verwaltung von zwei Websites brachte eine Reihe von Herausforderungen mit sich. Da es separate Versionen der Website gab, musste jede Funktion zweimal implementiert werden. Dies führte zu einer Menge doppelten Code und zusätzlichem Aufwand bei der Optimierung von zwei Websites für Computer und das mobile Web. Da die Grenzen zwischen den Geräten immer unscharfer wurden – Desktops, die Touchscreen unterstützen, und leistungsfähige Mobilgeräte mit immer größeren Bildschirmen – machte es immer weniger Sinn, unterschiedliche Designs für Desktop-Computer und Mobilgeräte zu erstellen.
Durch die Hinzufügung neuer Funktionen wurde auch unsere alte Desktop-Website langsam und aufgebläht. Anfang des Jahres wiege unsere Startseite etwa 5 MB und gab etwa 250 HTTP-Anfragen aus. Es lief einfach nicht gut. Die Bilder auf der Website waren umfangreich und nicht optimiert, wodurch die Seite weiter verlangsamt wurde. Daher war unser Stream bei langsamen und instabilen Netzwerken fast nicht verfügbar und die Erfahrung für diese Nutzer war bestenfalls enttäuschend. Außerdem war es notwendig, dass wir im mobilen Web ältere Browser unterstützen mussten. So waren wir nicht auf der gesamten Website auf JavaScript angewiesen und konnten keine besonders interaktiven Funktionen implementieren. Wir konnten uns nicht auf die Fortschritte bei mobilen Webbrowsern verlassen.
Lösung
Am Anfang konzentrierten wir uns auf responsives Design: eine Implementierung, die auf Mobiltelefonen, Tablets, Desktop-Computern und anderen Plattformen funktionieren würde. Wir haben uns jede einzelne Funktion, Seite, JavaScript-Bibliothek und CSS-Klasse genau angesehen. Wir wollten ein System entwickeln, das dafür sorgt, dass auf der Website nur das heruntergeladen wird, was für die Funktion unbedingt notwendig ist, es sei denn, der Nutzer wünschte sich mehr. Die Herausforderung bestand darin, eine Website zu erstellen, die auf einem langsameren Mobiltelefon mit Mobilfunkverbindung ordnungsgemäß funktionierte, aber auch auf schnelleren Browsern und größeren Bildschirmen ein großartiges immersives Erlebnis bietet.
Aufgrund dieser Einschränkungen mussten wir jede Codeänderung in Zukunft genau unter die Lupe nehmen. Dazu haben wir eine 6^5-Regel eingeführt, die dafür sorgt, dass beim ersten Seitenaufbau nicht mehr als 60.000 HTML, 60.000 JavaScript und 60 KB an CSS heruntergeladen wurden, unsere Animationen immer 60 fps waren und wir eine durchschnittliche Latenz von 0,6 s hatten.
Dazu haben wir uns für JavaScript- und CSS-Frameworks entschieden, die von Anfang an auf Modularität und Lazy Loading ausgelegt sind. Deshalb achten wir darauf, dass Nutzer JavaScript und CSS nur dann herunterladen, wenn sie die entsprechende Funktion tatsächlich verwenden. Dies geschieht über einen vorlagengesteuerten Ansatz, der mit unserem Build- und Modulsystem kombiniert wird, sodass der Aufwand für Entwickler fast vollständig ist.
Mit diesem neuen Framework begannen wir mit dem Prototyping einer Neuimplementierung von Google+ im Web. Wir begannen damit, „schlechte“ Dinge zu verboten zu machen und strenge Regeln für die Entwicklung aufzustellen. Eine unserer wichtigsten Regeln war, dass alle unsere Seiten sowohl serverseitig als auch clientseitig gerendert werden müssen. Beim serverseitigen Rendering wird sichergestellt, dass der Nutzer mit dem Lesen beginnen kann, sobald der HTML-Code geladen ist und JavaScript nicht ausgeführt werden muss, um den Inhalt der Seite zu aktualisieren. Sobald die Seite geladen ist und der Nutzer auf einen Link klickt, möchten wir keinen vollständigen Roundtrip ausführen, um alles noch einmal zu rendern. Hier kommt das clientseitige Rendering an Bedeutung. Wir müssen nur die Daten und Vorlagen abrufen und die neue Seite auf dem Client rendern. Dies bringt viele Kompromisse mit sich. Daher haben wir ein Framework verwendet, das das server- und clientseitige Rendering einfach macht, ohne den Nachteil, alles zweimal implementieren zu müssen – auf dem Server und auf dem Client.
Andere Regeln besagten, dass Animationen mit Höhe und Breite nicht zulässig sind, was zu neuen Layouts im Browser führen und sich negativ auf die Leistung auswirken würde. Für DOM-Manipulationen und -Animationen haben wir Aufgaben geplant, die synchron mit der Rendering-Aktualisierungsrate des Browsers ausgeführt werden sollen. Wir gruppieren auch alle Messaufgaben, sodass wir teure, wiederholte Stilberechnungen vermeiden. Außerdem haben wir uns stark auf Chrome-Profiler-Tools verlassen, um sicherzustellen, dass alles wie vorgesehen funktioniert. Darüber hinaus haben wir Tools entwickelt, die die Auswirkungen von Codeänderungen auf die JS-Bilanz berechnen, um sicherzustellen, dass wir unsere Seitengröße nicht drastisch vergrößern.
Dies dauerte einige Zeit, aber es wäre viel schwieriger gewesen, wenn wir nicht in der Lage gewesen wären, Probleme bereits während der Entwicklung zu identifizieren und zu beseitigen.
Die Einführung dieser responsiven Implementierung für das mobile Web wurde im Februar 2015 veröffentlicht. So konnten wir die neuen Designs und unseren neuen Prozess überprüfen. Wir haben anhand der Daten aus dieser Markteinführung geprüft, was funktioniert hat und was nicht. Wir haben das Design überarbeitet und auf weitere Geräte ausgeweitet. Im November 2015 haben wir diese neue Implementierung für alle Geräte eingeführt.
Ergebnisse
Google+ konnte ohne Einbußen bei der Leistung eine komplexe Webanwendung mit einer umfangreichen Benutzeroberfläche erstellen. Die Website ist jetzt schneller und schlanker als je zuvor.
Vorher | Nachher | |
---|---|---|
Gesamtgröße der Startseite, mit gzip (mit Bildern) komprimiert | 22.600 KB | 327 KB |
Anzahl der Anfragen | 251 | 45 |
HTML (nicht mit gzip komprimiert) | 1.100 KB | 362 KB |
JavaScript und CSS (mit gzip) | 2.768 KB | 111KB |
Durchschnittliche Ladezeit der gesamten Seite (Latenz) | 12 Sekunden 0,7 Sekunden bis zum ersten Byte |
3 Sekunden 0,1 Sekunden bis zum ersten Byte |