121 pomiarów Core Web Vitals. Dwie moje najlepsze hipotezy pomiary odrzuciły

👁 160 przeczytań

Optymalizowałem ten serwis przez kilka dni, robiąc po każdej zmianie serię pomiarów Lighthouse zamiast jednego przebiegu. Efekt był upokarzający: dwie z moich najlepszych hipotez okazały się szkodliwe, a prawdziwego winowajcę znalazłem dopiero wtedy, gdy przestałem wierzyć w pojedynczy wynik. 121 pomiarów w dziewięciu seriach. Oto co z nich wyszło.

Zasada zero: mierz serię, nie pojedynczy przebieg

To brzmi banalnie, ale prawie nikt tego nie robi - i dlatego prawie wszystkie „optymalizacje” w internecie to przypadek.

Uruchomiłem Lighthouse dziesięć razy z rzędu na niezmienionym adresie. Wyniki rozjechały się od 60 do 96 punktów. Gdybym zmienił cokolwiek w kodzie i trafił na przebieg 96 po zmianie i 60 przed, ogłosiłbym sukces. Gdyby wyszło odwrotnie, wycofałbym dobrą poprawkę.

Pro tip: minimum pięć przebiegów na wariant, porównuj mediany i zawsze podawaj pełny zakres. Jeśli zakresy przed i po zachodzą na siebie, nie masz wyniku - masz szum.

Hipoteza 1, odrzucona: sklejanie CSS w jeden plik

Klasyczna rada: mniej żądań HTTP, więc połącz arkusze. Zbudowałem paczkę z kilku plików CSS motywu, sprawdziłem poprawność ścieżek względnych i kolejności importów, wdrożyłem. Pomiar:

Dlaczego to nie zadziałało: pięć osobnych arkuszy to pięć krótkich zadań parsowania, które przeglądarka może przeplatać z innymi. Jeden arkusz 69 KB to jedno długie zadanie, którego nie da się przerwać - a długie zadania to dokładnie to, co mierzy TBT. Zmniejszyłem liczbę żądań i pogorszyłem odczucie płynności.

Pro tip: przy HTTP/2 liczba żądań przestała być problemem. Sklejanie plików to porada z czasów HTTP/1.1 i dziś potrafi zaszkodzić.

Hipoteza 2, odrzucona: odroczenie zapytań w tle

Strona sklepu wysyłała kilka zapytań AJAX przy starcie. Odroczyłem je przez requestIdleCallback z limitem czasu 3000 ms - podręcznikowe rozwiązanie. Pomiar:

• TBT sklepu: 64 ms → 265 ms
• Start zapytań przesunął się z przedziału 183-1329 ms na 383-2411 ms

Dlaczego to nie zadziałało: limit czasu 3000 ms sprawił, że przeglądarka odpaliła wszystkie odroczone zapytania jedną serią - i to dokładnie w oknie, w którym liczony jest TBT. Zamiast rozłożyć pracę, zebrałem ją w jeden korek.

Pro tip: requestIdleCallback z krótkim limitem czasu to nie jest „zrób to później”. To jest „zrób to później, ale na pewno”. Bez limitu albo z bardzo długim zachowuje się inaczej.

Co zadziałało i dlaczego

Jedna linijka, która skasowała 70 ms wymuszonego przeliczenia układu

Skrypt odczytywał pozycję elementu i od razu ją zmieniał. To powoduje wymuszone przeliczenie układu - przeglądarka musi przerwać wszystko i policzyć geometrię strony. Lighthouse wskazywał 70-75 ms w jednej linii.

Poprawka to jedna linijka:

if (window.requestAnimationFrame) requestAnimationFrame(miejsce); else miejsce();

Odczyt przenosi się do momentu, w którym przeglądarka i tak przelicza układ. Koszt spada do zera, a kod robi dokładnie to samo.

Wyrzucenie z krytycznej ścieżki tego, czego strona nie używa

Arkusz szablonów ważył 75 094 bajty i ładował się na każdej podstronie, mimo że większość stron nie używa żadnego z tych szablonów. Wersja podstawowa to 9 708 bajtów - czyli 87% wagi szło na darmo. Podobnie jQuery, ładowane mimo braku jakiegokolwiek konsumenta.

Pro tip: zanim zaczniesz minifikować, sprawdź, czy plik jest w ogóle potrzebny na tej stronie. Usunięcie bije kompresję każdego dnia.

Prawdziwy winowajca: stos reklamowy

Po odrzuceniu obu hipotez zadałem inne pytanie: skąd bierze się rozrzut 60-96 punktów. Zablokowałem domeny reklamowe i zgody i powtórzyłem serię:

Wniosek był brutalny: przez kilka dni optymalizowałem kod, który odpowiadał za ułamek problemu. Rozrzut brał się z zewnętrznych skryptów, na które nie mam wpływu i których nie usunę, bo finansują serwis.

Pro tip, najważniejszy z całego tekstu: zanim zoptymalizujesz cokolwiek, zmierz, ile z wyniku pochodzi od Ciebie, a ile od zewnętrznych skryptów. Zrób serię z zablokowanymi domenami stron trzecich. Jeśli różnica jest duża, Twój realny sufit jest znacznie niżej, niż myślisz - i lepiej to wiedzieć przed trzema dniami pracy niż po.

Dwie pułapki narzędzi, na które trafiłem przy okazji

Pingdom potrafi kłamać o kompresji

Raport twierdził, że serwer nie kompresuje odpowiedzi. Sprawdziłem bezpośrednio: serwer wysyła br i zstd, a gdy poprosić wprost o gzip, oddaje stronę główną w 71 306 bajtach zamiast 289 394 nieskompresowanych. Narzędzie po prostu nie deklarowało obsługi nowszych algorytmów. Nagłówki wygasania też były na miejscu.

Czyszczenie całego cache potrafi zepsuć wygląd

Wtyczka czyściła przy każdej publikacji cały cache razem ze zminifikowanymi plikami CSS. W oknie między skasowaniem a odbudowaniem strona linkowała do arkusza, którego nie było - i przez chwilę wyświetlała się jako goły HTML. Przy kilkunastu wpisach dziennie zdarzało się to regularnie.

Pro tip: po publikacji wpisu czyść punktowo - sam wpis, stronę główną, jego kategorie i kanał RSS. Nowy artykuł nie zmienia zawartości pliku CSS, więc nie ma powodu go kasować.

Lista kontrolna, jeśli chcesz to powtórzyć u siebie

1. Zrób dziesięć pomiarów na niezmienionej stronie. Zapisz medianę i zakres. To jest Twój szum.
2. Powtórz serię z zablokowanymi domenami zewnętrznymi. Różnica to sufit Twoich możliwości.
3. Dopiero teraz zmieniaj po jednej rzeczy naraz i mierz serią, nie pojedynczym przebiegiem.
4. Jeśli zakresy przed i po zachodzą na siebie - wycofaj zmianę. Brak dowodu to nie dowód.
5. Zacznij od usuwania, nie od minifikacji. Plik, którego nie ma, jest zawsze najszybszy.
6. Szukaj wymuszonych przeliczeń układu. Bywają warte 70 ms za jedną linijkę poprawki.

// czytaj dalejGPT-6.1 Terra API: kod w Pythonie i JS, Flex za pół ceny i mój pomiarArtykułyOpenAI twierdzi, że AI obaliło hipotezę ETH i udowodniło istnienie Yanga-Millsa. Co da się już sprawdzićNewsyKomputer do wideo AI: ile VRAM, RAM i jaki dysk (moje pomiary)Artykuły