Wyzwanie wydajności front-end: zwycięzca i wyniki

Kilka tygodni temu poprosiliśmy naszych czytelników i społeczność, aby wykorzystali wszystko, co mogli, aby ich witryny i projekty działały niesamowicie szybko. Dziś cieszymy się, że możemy pochwalić się wynikami tego wyzwania i ogłosić zwycięzcę, który otrzyma naprawdę wspaniałe nagrody!

Pytasz jakie nagrody? Zwycięzca wygrywa lot w obie strony do Londynu, pełne zakwaterowanie w eleganckim hotelu, bilet na SmashingConf London 2018 i wreszcie wybrane przez siebie warsztaty Smashing.

Wyzwanie? Jakie wyzwanie?

Cóż, zadanie nie było tak proste, jak się wydawało. Uczestników poproszono o poprawę wydajności strony internetowej przy zachowaniu identycznego końcowego wyglądu przed i po. Ładowanie czcionek mogło się różnić, a ponowne wlania tekstu były dopuszczalne, o ile były ograniczone do minimum.

Wybierając szczęśliwego zwycięzcę, przyjrzeliśmy się wynikom prezentowanym przez Lighthouse i WebPageTest, a także oczywiście złożoności stron internetowych, nad którymi pracowali nasi uczestnicy. Najważniejszymi wskaźnikami były pierwsze znaczące malowanie i czas na interakcję .

Ale na razie dość twardych faktów. Wiemy, że jesteś już ciekawy i nie chcemy dłużej trzymać Cię w napięciu. Oto zwycięski projekt.

A zwycięzcą jest…

Leonardo Losoviz

Wszystkie techniki optymalizacji przedstawione w zgłoszeniu Leonarda to majsterkowanie, zaprojektowane i wdrożone od podstaw. Dodał wszystkie optymalizacje do PoP, platformy open source do tworzenia stron internetowych, i wykorzystał Agenda Urbana do testowania ulepszeń wydajności w rzeczywistym projekcie.

Czuliśmy, że to zgłoszenie naprawdę wpisuje się w ducha wyzwania, nie tylko poprawiając wydajność jednej witryny, ale także próbując ulepszyć strukturę używaną w wielu witrynach. Fakt, że PoP jest wspierany przez WordPressa, oznaczał, że Leonardo był w podobnej sytuacji, jak wiele osób, które nie były w stanie zrobić niektórych rzeczy dostępnych w ramach JavaScript. Jak zauważył:

PoP jest oparty na WordPressie. Oznacza to, że wiele innowacyjnych technik optymalizacji dostępnych dla frameworków JavaScript, takich jak dzielenie kodu za pomocą Webpack lub Service Workers poprzez sw-precache, jest poza zasięgiem (przynajmniej bez dużego obejścia). W związku z tym wszystkie opisane poniżej techniki optymalizacji są w całości zaprojektowane i zaimplementowane od podstaw.

Jeśli chcesz zagłębić się we wszystkie najdrobniejsze szczegóły jego zgłoszenia, możesz to zrobić. Wszystkim nam podobało się czytanie szczegółów optymalizacji Leonarda i czuliśmy, że jest godnym zwycięzcą ze względu na ogrom pracy włożony w ten wpis.

Wszystkie zgłoszenia

Byliśmy bardzo zadowoleni z jakości nadesłanych prac i szczerze mówiąc, nie było łatwo wybrać zwycięzcę. Dziękuję wszystkim, którzy przesłali — kontynuuj wspaniałą pracę!

Jorgen Verweij

Jorgen Verweij zaprezentował zoptymalizowaną wersję swojej firmowej strony internetowej Perplex Internetmarketing BV. Wraz z zespołem składającym się z UX'era, programisty front-endowego i back-endowego oraz administratora systemu, rozpoczął przedsięwzięcie wydajnościowe.

Rezultatem jest doskonała implementacja z doskonałymi wynikami wydajności na całym świecie: SpeedIndex znacznie poniżej wyznaczonego celu 1250, czas ładowania poniżej 1 sekundy, rozpoczęcie renderowania w pół sekundy, wynik PageSpeedScore ¹⁰⁰ ⁄ ₁₀₀ i prawie doskonały audyt Lighthouse . W porównaniu ze starą sytuacją czas ładowania jest prawie ośmiokrotnie krótszy. Sława! Możesz przeczytać więcej szczegółów na temat tego procesu w tym obszernym opisie, który przygotował Jorgen.

Marco Hengstenberg

Marco Hengstenberg przesłał zoptymalizowaną wersję strony internetowej agencji turystycznej Land in Sicht . Aby poprawić wydajność, Marco użył wielu fajnych sztuczek i technik. Wstępne ładowanie głównego arkusza stylów i krytyczne ładowanie czcionek ze wstępnym ładowaniem w obsługiwanych przeglądarkach to tylko dwa z nich. Zmienił także strukturę kodu HTML, aby był jak najbardziej płaski, semantyczny i dostępny, oraz zmniejszył ilość danych przesyłanych początkowo przy pierwszej wizycie z prawie 3 MB do 1,3 MB na komputerze (a ze względu na użycie responsywnych obrazów dla obrazu bohatera, jest nawet mniej niż na wąskich ekranach).

Aby jeszcze bardziej usprawnić witrynę, Marco usunął Bootstrap, jQuery i Modernizr, skonfigurował proces kompilacji za pomocą Grunta i wprowadził ServiceWorker, który udostępnia witrynę również w trybie offline. Wysiłek był tego wart: rezultatem jest dramatyczny czas TTL, który spadł z 32 sekund do 2 sekund i prawie 50% spadek żądań HTTP i przesyłanych bajtów (patrz także raport Lighthouse, ZIP 251 KB). Wstępne ładowanie i szybkie wstępne renderowanie pomagają w postrzeganym czasie ładowania. Świetna robota!

Gabriel Mariani

Witryna San Diego Christian College była tą, na której Gabriel Mariani zastosował swoje umiejętności wykonawcze. Proces optymalizacji podzielił na cztery kroki. Najpierw przyciął wszystkie obrazy do maksymalnego rozmiaru, w którym były rzeczywiście potrzebne, i stworzył ich wersje w skali mobilnej. Następnie wszystkie obrazy ładował się leniwie. Drugi krok koncentrował się na JavaScript i usunięciu wszystkich wbudowanych skryptów, z którymi pochodziła witryna WordPress oraz jej motyw i wtyczki innych firm. Następnie umieścił w kolejce jak najwięcej skryptów, aby funkcja Autoptimize mogła je pobrać i zminimalizować/połączyć w jeden plik.

Gabriel ograniczył również liczbę używanych czcionek i ustawił czcionki Google tak, aby były ładowane async , tak aby ścieżka krytyczna CSS była ładowana jako pierwsza. Wreszcie, zajął się kilkoma innymi małymi drobiazgami, takimi jak dostosowywanie wtyczek WordPress, więc opierają się na ajaxie zamiast na PHP. To pozwoliło mu włączyć buforowanie stron i ostatecznie włączyć CDN dla witryny. Ostatnim krokiem było przejście na HTTP/2 i HTTPS. Zobacz WebPageTest dla pełnych wyników. Miły!

Aleksander Zarges

Alexander Zarges opracował Cloud Player, jednostronicową aplikację internetową opartą na Angular 4, która umożliwia wyszukiwanie i odtwarzanie aplikacji YouTube i SoundCloud. Zaktualizowana wersja używa kompilatora Angular z wyprzedzeniem, aby osiągnąć czas inicjalizacji około 2,9 sekundy (w porównaniu do 5,2 sekundy w przypadku korzystania z kompilatora just-in-time). Jeśli chcesz zagłębić się w kod, sprawdź towarzyszące repozytorium GitHub.

Bradly drwina

Bradley Taunt potraktował nasze wyzwanie jako okazję do eksperymentowania ze swoją osobistą witryną. Jako podstawę swojego przedsięwzięcia optymalizacyjnego wykorzystał swoją stronę domową i artykuł z obrazami. Aby skrócić czas ładowania artykułu do 4,2 sekundy, Bradley domyślnie używa czcionek systemowych użytkownika, zamiast używać między innymi czcionek internetowych.

Dla dodatkowego przyspieszenia, zoptymalizowana wersja zawiera również krytyczne CSS, obsługuje responsywne obrazy i wykorzystuje buforowanie CDN. Możesz bardziej szczegółowo zajrzeć za kulisy w poście na blogu, który Bradley napisał o tym, jak poradził sobie z wyzwaniem.

John Beales

John Beales rzucił sobie wyzwanie, aby zwiększyć wydajność 4RoadService.com. Kiedy zaczynał, istniały już pewne optymalizacje. Obrazy statyczne były uruchamiane przez ImageOptim, na przykład CSS i JS zostały zminimalizowane, uruchomiono CDN przez CloudFlare, a witryna używała już programu ładującego w stylu aplikacji pojedynczej strony, więc nowa treść jest zawsze pobierana przez XHR, a strona jest nigdy całkowicie przerysowany.

W tym wyzwaniu John włączył Optymalizację obrazu i kompresję WebP w Cloudflare. Zaktualizowana witryna używa teraz protokołu HTTP/2 Server Push do wysyłania głównych plików CSS i JS z początkowym ładowaniem strony i wykorzystuje Guetzli do kompresji JPEG. Aby zoptymalizować buforowanie, zaktualizował adresy URL wszystkich zasobów statycznych, aby adres URL zmieniał się przy każdej zmianie zasobu, a następnie ustawił wszystkie zasoby statyczne na buforowanie na rok. Aby poprawić buforowanie obrazów, John zaktualizował również adresy URL obrazów o dynamicznie zmienianych rozmiarach, aby CloudFlare myślał, że są to statyczne pliki obrazów.

Wynik: pierwszy znaczący czas malowania spadł z 2220 ms do 1290 ms, a First Interactive z 5480 ms do 3040 ms. Tutaj możesz wyświetlić pełne wyniki testów Lightbox i strony internetowej.

Shaun O'Connell

Wpis Shauna O'Connela to praca, którą wykonał na kiwi.ruby.nz. Celem było przekształcenie strony internetowej konferencji w PWA, aby uczestnicy konferencji mogli przeglądać wszystkie informacje dotyczące wydarzenia w trybie offline. Niektóre z rzeczy, które zrobił: zastąpienie typowego elementu iframe w Mapach Google mapami statycznymi Google, samodzielne hostowanie podzbiorów czcionek, przenoszenie kodu CSS w wierszu, aby pierwsze żądanie nie przekraczało 14 KB, usuwanie zależności, dodawanie pre-cache Service Workers i dodawanie Turbolinków dla zgryźliwych przejścia między stronami. Dzięki temu początkowy czas renderowania spadł z 3,9 sekundy do 0,3 sekundy.

Więcej szczegółów znajdziesz w WebPageTests.

Rusłan Julbarissow

Ruslan Julbarissow przesłał swoją osobistą stronę internetową zerofy.de. Ponieważ zakończył pracę nad optymalizacją na krótko przed opublikowaniem konkursu, niestety nie ma szczegółowych wyników przed ogłoszeniem, ale Ruslan dobrze napisał, w jaki sposób jego poprawki doprowadziły do ​​rozmiaru strony 1,6 KB i TTFB 197 ms. Oprócz buforowania, minifikacji, poprawek GZIP i jQuery, ładuje czcionki później, aby uniknąć blokowania renderowania, a zastępując FontAwesome niestandardowym zestawem 10 ikon IcoMoon, udało mu się zaoszczędzić dodatkowe 130 KB.

Aby zwiększyć wynik indeksu szybkości i uzyskać jak najszybsze wrażenia, stworzył również osobny plik PHP, który zawiera wszystkie style CSS wpływające na widok strony u góry. Miły szczegół: maleńki skrypt Barba.js pozwala mu tworzyć przejścia między stronami bez przeładowywania całej witryny.

Dziękuję wszystkim za udział

Uff! To było naprawdę nie lada wyzwanie! Dla tych z was, którzy lubią tak dobre wyzwanie i łaskotanie mózgu od czasu do czasu, czekajcie na kolejne wyzwanie. Wkrótce wymyślimy kolejny — to na pewno!