Podsumowanie
Google+ szybko się reaguje.
Większa elastyczność
Google+ to miejsce, w którym ludzie dzielą się swoimi zainteresowaniami. Zombie Koty po kalkulatory vintage. Do niedawna usługa Google+ oferowała dwie różne wersje witryny – jedną na komputery i na urządzenia mobilne zaprojektowane z myślą o starszych przeglądarkach.
Wyzwania
Prowadzenie dwóch witryn wiązało się z wyjątkowymi wyzwaniami. Posiadanie osobnych wersji witryny oznacza, że każdą funkcję trzeba wdrożyć 2 razy. Wiąże się to z wieloma duplikatami kodu i dodatkowymi nakładami pracy przy optymalizacji 2 środowisk na komputery i urządzenia mobilne. Granice między urządzeniami stają się coraz bardziej zamazane (w przypadku komputerów, które obsługują dotykowe i zaawansowane urządzenia mobilne z coraz większymi ekranami), dlatego różnicowanie wyglądu strony na komputery i urządzenia mobilne sprawiało, że staje się to coraz mniej sensowne.
W miarę dodawania nowych funkcji starsza wersja strony na komputery też stała się powolna i rozrastająca się. Na początku tego roku ważyła ona około 5 MB i wygenerowała około 250 żądań HTTP. Nie była ona jednak skuteczna. Grafika w witrynie była przeciążona i niezoptymalizowana, co spowalniało jej działanie. W efekcie nasza transmisja była prawie niedostępna w powolnych i niestabilnych sieciach, a wrażenia użytkowników były rozczarowujące. Wymóg obsługi starszych przeglądarek w przeglądarce mobilnej uniemożliwił nam też korzystanie z JavaScriptu w całej witrynie i uniemożliwił wdrożenie wysoce interaktywnych funkcji. Nie mogliśmy liczyć na postępy w przeglądarkach mobilnych.
Rozwiązanie
Zaczęliśmy od elastycznego projektowania stron, które działa na urządzeniach mobilnych, tabletach, komputerach i nie tylko. Dokładnie przyjrzeliśmy się każdej funkcji, stronie, bibliotece JavaScript i klasom CSS. Chcieliśmy zbudować system, który umożliwiłby pobieranie z witryny tylko tych treści, które są absolutnie niezbędne do działania, chyba że użytkownik poprosi o więcej. Wyzwaniem było stworzenie witryny, która działała prawidłowo na wolniejszych telefonach komórkowych z połączeniem komórkowym, a jednocześnie działała świetnie w szybszych przeglądarkach i na większych ekranach.
Ten zestaw ograniczeń oznaczał, że musieliśmy dokładnie kontrolować każdą zmianę w kodzie. W tym celu wprowadziliśmy regułę 6^5, dzięki której przy początkowym wczytywaniu strony nie pobieraliśmy więcej niż 60 tys. kodu HTML, 60 KB kodu JavaScript, 60 tys. kodu CSS, a nasze animacje miały zawsze 60 kl./s, a średni czas oczekiwania wynosił 0,6 s.
Aby to osiągnąć, wybraliśmy platformy JavaScript i CSS, które od samego początku wbudowały modułowość i leniwe ładowanie. Dlatego dbamy o to, aby użytkownicy pobierali JavaScript i CSS tylko wtedy, gdy rzeczywiście korzystają z funkcji, która ich wymaga. Odbywa się to za pomocą podejścia opartego na szablonach, które w połączeniu z naszym systemem kompilacji i modułów, dzięki czemu aplikacja działa niemal bez wysiłku ze strony programistów.
Korzystając z tych nowych rozwiązań, zaczęliśmy tworzyć prototyp reimplementacji Google+ w internecie. Zaczęliśmy zabraniać „złych” rzeczy i ustalać rygorystyczne zasady w zakresie rozwoju. Jedną z naszych głównych zasad było to, że wszystkie nasze strony musiały być renderowane zarówno po stronie serwera, jak i po stronie klienta. Dzięki renderowaniu po stronie serwera użytkownik może rozpocząć odczytywanie od razu po wczytaniu kodu HTML i nie trzeba uruchamiać JavaScriptu, aby zaktualizować zawartość strony. Po wczytaniu strony i kliknięciu linku przez użytkownika nie chcemy przeprowadzać pełnego renderowania w obie strony. W tym przypadku ważna jest renderowanie po stronie klienta, ponieważ trzeba już tylko pobrać dane i szablony, a potem wyrenderować nową stronę na kliencie. Wiąże się to z wieloma kompromisami, dlatego zastosowaliśmy platformę, która ułatwia renderowanie po stronie serwera i klienta. Nie trzeba niczego robić dwa razy – zarówno na serwerze, jak i po stronie klienta.
Inne reguły obejmowały zablokowanie animacji wysokości i szerokości, które powodowałyby ponowne układy przeglądarki i miały negatywny wpływ na wydajność. W przypadku manipulacji i animacji DOM zaplanowaliśmy wykonywanie zadań zsynchronizowanych z częstotliwością odświeżania renderowania w przeglądarce. Łączymy też wszystkie zadania pomiarowe, aby uniknąć kosztownych, powtarzanych obliczeń. Korzystaliśmy też w dużej mierze z narzędzi profilu Chrome, aby mieć pewność, że wszystko działa zgodnie z oczekiwaniami. Ponadto stworzyliśmy narzędzia, które obliczają wpływ zmian w kodzie na ślad JavaScriptu, aby mieć pewność, że nie spowoduje to gwałtownego zwiększenia rozmiaru strony.
Trochę to trwało, ale byłoby znacznie trudniejsze, gdyby nie mieliśmy możliwości identyfikacji i usuwania problemów w trakcie tworzenia.
W lutym 2015 roku udostępniliśmy mobilną wersję tego rozwiązania. Dzięki temu mogliśmy sprawdzić nowe projekty i nasz nowy proces. Na podstawie danych zebranych podczas tego wprowadzenia zweryfikowaliśmy, co działa, a co nie. Ulepszyliśmy jej wygląd i zaczęliśmy rozszerzać ją na kolejne urządzenia. W listopadzie 2015 r. wprowadziliśmy tę nową implementację na wszystkich urządzeniach.
Wyniki
Google+ bez negatywnego wpływu na wydajność udało się stworzyć złożoną aplikację internetową z rozbudowanym interfejsem użytkownika. Strona jest teraz szybsza i udoskonalona niż kiedykolwiek wcześniej.
| Przed | Po | |
|---|---|---|
| Całkowita waga strony głównej, spakowana w formacie gzip (z obrazami) | 22 600 KB | 327 KB |
| Liczba żądań | 251 | 45 |
| HTML (bez pliku gzip) | 1100 KB | 362 KB |
| JavaScript i CSS (gzip) | 2768 KB | 111KB |
| Średni czas wczytywania strony (opóźnienie) | 12 sekund 0,7 sekundy do pierwszego bajtu |
3 sekundy 0,1 sekundy do pierwszego bajtu |