Jak sprawdzić szybkość witryny

Szybki sposób: uruchom test w prawdziwej przeglądarce

Wpisz adres URL w test szybkości strony i pozwól mu wczytać stronę w prawdziwej przeglądarce, zamiast szacować wynik. Dobry raport daje Ci zrzut ekranu tego, co się wyrenderowało, ogólne czasy oraz podział na poszczególne żądania, pokazujący, który obraz, skrypt albo wywołanie firmy trzeciej było wolne. Ten podział zamienia "strona jest wolna" w "ten jeden plik czcionki blokuje renderowanie przez 1,8 sekundy".

Uruchamiaj go zaraz po wdrożeniu, po aktualizacji wtyczki albo motywu, i przed zdecydowaniem się na zmianę hostingu albo CDN. To momenty, w których szybkość się zmienia, a nikt tego nie zauważa.

Mierzenie tego samodzielnie z linii poleceń

Do strony serwerowej tej historii w ogóle nie potrzebujesz przeglądarki. curl może wypisać własny podział czasowy:

curl -o /dev/null -sS -w   "dns:%{time_namelookup}s connect:%{time_connect}s tls:%{time_appconnect}s ttfb:%{time_starttransfer}s total:%{time_total}s\n"   https://example.com/

To mierzy jedno żądanie, tylko dla dokumentu HTML, więc zawsze będzie wyglądać szybciej niż prawdziwa strona. Dokładnie dlatego jest to przydatne: izoluje serwer od przeglądarki. Jeśli ttfb jest tu wysokie, żadna optymalizacja obrazów nie pomoże. Jeśli ttfb jest niskie, a strona wciąż wydaje się wolna, problem leży w tym, co przeglądarka musi zrobić po dotarciu HTML-a.

Co oznaczają TTFB, LCP i pełne wczytanie

• Czas do pierwszego bajtu (TTFB). Jak długo serwer potrzebował, żeby zacząć odpowiadać, licząc DNS, nawiązanie połączenia, TLS i własne przetwarzanie serwera. Wysoki TTFB wskazuje na hosting, zapytania do bazy danych albo kod backendu, a nie na zasoby strony.
• Largest Contentful Paint (LCP). Moment, w którym największy widoczny element w obszarze widoku skończył się renderować, zwykle duży obraz, plakat wideo albo duży blok tekstu. To liczba najbliższa temu, co odwiedzający nazwałby "kiedy strona się pojawiła". Google uznaje 2,5 sekundy lub mniej za dobry wynik.
• Czas wczytania / pełnego wczytania. Moment, w którym przeglądarka skończyła wczytywać dokument i blokujące go zasoby. Wszystko, co widzi odwiedzający, jest normalnie gotowe dużo wcześniej.
• Całkowity czas do uspokojenia. Czas wczytania plus wszystko, co jeszcze działa potem, na przykład skrypty pobierające dane, gdy strona wygląda już na gotową. Strona może wyglądać na skończoną, a wciąż być zajęta, i ta praca konkuruje z pierwszym przewinięciem albo kliknięciem odwiedzającego.
• Żądania i przesłane bajty. Ile plików pobrała strona i ile danych zostało ściągniętych. To dźwignie stojące za niemal każdą liczbą powyżej.

Czytaj je razem. Niskie TTFB z wysokim LCP oznacza, że przeglądarka robi zbyt dużo: za dużo żądań, skrypty blokujące renderowanie albo ogromny duży obraz. Wysokie TTFB, przy reszcie w normie, oznacza, że wąskim gardłem jest serwer, jeszcze zanim w ogóle zaangażuje się przeglądarka.

Dlaczego jeden test z jednego miejsca wprowadza w błąd

To normalne, że ten sam adres URL przetestowany dwa razy daje dwa różne wyniki i żaden z nich nie jest błędny. Za większość rozrzutu odpowiadają trzy rzeczy:

• Odległość. Test uruchomiony blisko serwera ma krótszą trasę sieciową niż taki uruchomiony na innym kontynencie. Jeśli Twoi odwiedzający są w Europie, a Ty testujesz z tego samego miasta co serwer, mierzysz najlepszy przypadek, a nie typowy.
• Profil urządzenia. Test może symulować urządzenie mobilne z mniejszym obszarem widoku, innym user agentem i spowolnionym połączeniem. Strona dostrojona pod komputer stacjonarny ocenia się bardzo różnie w symulacji mobilnej, i tak ma być.
• Buforowanie i rozgrzanie. Pierwsze żądanie może trafić na zimną pamięć podręczną CDN albo aplikacji; drugie jest obsługiwane już na ciepło. Uruchom stronę dwa lub trzy razy i patrz na wzorzec, a nie na pojedynczy najszybszy przebieg.

Pojedynczy test wciąż warto uruchomić. To po prostu oznacza, że liczba ma sens tylko razem z warunkami, w jakich została zmierzona.

Jak czytać wykres wodospadowy

Wykres wodospadowy to oś czasu poszczególnych żądań, jeden pasek na plik, uporządkowany według momentu rozpoczęcia. Regularnie pojawiają się cztery wzorce:

1. Długi pierwszy pasek, zanim zacznie się cokolwiek innego. To TTFB dla HTML-a, a wszystko inne czeka za nim w kolejce.
2. Schodki, gdzie każde żądanie zaczyna się dopiero, gdy kończy się poprzednie. To łańcuch zależności, zwykle skrypt wczytujący kolejny skrypt, który wczytuje właściwą treść. Łańcuchy to najkosztowniejszy wzorzec na wykresie.
3. Szeroki pasek pośrodku z domeny firmy trzeciej. Reklamy, widżety czatu, analityka i czcionki siedzą tutaj, a wolna firma trzecia opóźnia Twoją własną stronę, jeśli jest wczytywana synchronicznie.
4. Gęste skupisko maleńkich pasków. Dziesiątki małych plików, każdy z własnym narzutem połączenia. Mniej, większych, buforowanych plików zwykle bije wiele małych.

Paski w czerwieni albo z kodami 4xx i 5xx zasługują na uwagę nawet, gdy strona wygląda dobrze, bo nieudane żądanie i tak kosztuje czas, zanim zawiedzie.

Wyłapanie spowolnienia, którego nikt nie szukał

Pojedynczy test mówi, jak strona zachowała się raz, z jednego miejsca, na jednym profilu urządzenia. Tego właśnie chcesz, gdy debugujesz coś konkretnego. To nie jest to, czego chcesz, gdy celem jest w ogóle zauważyć spowolnienie: strony stają się cięższe po jednej aktualizacji naraz, a nikt nie uruchamia ręcznego testu w spokojny wtorek. Zaplanowany monitoring szybkości strony uruchamia ten sam test z tych samych lokalizacji według harmonogramu, przechowuje historię i alarmuje, gdy liczby przekroczą próg. Uruchom jeden teraz za pomocą testu szybkości strony, a jeśli okaże się, że wolną częścią jest serwer, zobacz czas odpowiedzi serwera.