Metryka Speed Index

TL;DR — Speed Index to wynik Lighthouse pokazujący, jak szybko pojawiają się elementy na stronie podczas jej ładowania. Mniej (czyli szybciej) znaczy lepiej, a wynik mierzy się w sekundach. Na urządzeniach mobilnych wynik poniżej 3,4 s jest dobry. Speed Index nie jest Core Web Vital i nie wpływa bezpośrednio na pozycje w Google — ale poprawki, które go ulepszają, zwykle pomagają także metrykom, które mają znaczenie.

Czym jest Speed Index

Gdy uruchamiasz stronę przez Lighthouse lub PageSpeed Insights, jedną z otrzymanych liczb jest Speed Index. Odpowiada on na proste pytanie: jak szybko wypełnia się widoczna część strony?

Większość metryk szybkości wskazuje jeden moment — na przykład pojawienie się pierwszego fragmentu treści (First Contentful Paint) albo największego elementu (Largest Contentful Paint). Speed Index jest inny. Obserwuje całe ładowanie i podaje średnią szybkość, z jaką kolejne elementy stają się widoczne. Strona, która niemal natychmiast renderuje wszystko, otrzymuje niski (dobry) wynik; strona, która pozostaje pusta, a potem powoli dozuje treść, otrzymuje wysoki (zły) wynik.

Jak czytać wynik

Lighthouse ocenia Speed Index na urządzeniach mobilnych w następujący sposób:

• Good: 0–3,4 s (zielony)
• Needs improvement: 3,4–5,8 s (pomarańczowy)
• Poor: powyżej 5,8 s (czerwony)

Desktop jest znacznie bardziej rygorystyczny — dobry wynik to mniej więcej poniżej 1,3 s — ponieważ Lighthouse testuje urządzenia mobilne na symulowanym, wolniejszym urządzeniu. Nie porównuj więc liczby desktopowej z mobilną; są mierzone w różnych skalach.

Czy ma to znaczenie dla SEO?

Oto część, którą ludzie często rozumieją źle. Speed Index nie jest Core Web Vital i nie jest czynnikiem rankingowym Google. Sygnały Google dotyczące doświadczenia strony pochodzą z Core Web Vitals (LCP, INP i CLS) mierzonych u rzeczywistych użytkowników. Speed Index nie należy do tego zestawu i nie jest nawet mierzony u prawdziwych użytkowników — wymaga nagrania wideo ładowania, które powstaje wyłącznie w narzędziach testowych.

To nie czyni go bezużytecznym. Poprawki ulepszające Speed Index — szybszy serwer, mniej plików blokujących renderowanie i tekst pozostający widoczny podczas ładowania fontów — są tymi samymi poprawkami, które ulepszają FCP i LCP. Dlatego lepszy Speed Index zwykle idzie w parze z lepszym LCP, które ma znaczenie.

Jeśli chcesz poznać wzór, historię WebPageTest, miejsce tej metryki w wyniku Lighthouse oraz ograniczenia, na które trzeba uważać, przejdź do karty Advanced.

TL;DR — Speed Index mierzy, jak szybko treść jest wizualnie wyświetlana podczas ładowania strony — średni moment pojawienia się widocznej treści, wyrażony w sekundach (mniej znaczy lepiej). Jest obliczany na podstawie filmu z ładowania przez sumowanie obszaru powyżej krzywej postępu wizualnego, dzięki czemu jest metryką wyłącznie laboratoryjną (nie występuje w CrUX, terenowych danych PSI ani Search Console). Powstał w WebPageTest (Pat Meenan); Lighthouse oblicza go za pomocą modułu open source Speedline. Nie jest Core Web Vital ani czynnikiem rankingowym — to jedna z pięciu metryk Lighthouse, ważona w Lighthouse 10 na 10 %. Urządzenia mobilne: Good ≤ 3,4 s, Needs improvement ≤ 5,8 s, Poor > 5,8 s; desktop: Good ≤ ~1,3 s. Nie może być szybszy niż FCP, zależy od viewportu i poprawia się dzięki tym samym poprawkom co FCP/LCP.

Co naprawdę mierzy Speed Index

Definicja Google mieści się w jednym zdaniu: “Speed Index measures how quickly content is visually displayed during page load.” („Speed Index mierzy, jak szybko treść jest wizualnie wyświetlana podczas ładowania strony”). Kluczowe słowo to wizualnie. Speed Index nie jest pojedynczym znacznikiem czasu, tak jak First Contentful Paint i Largest Contentful Paint — to wynik zbiorczy, który przedstawia średni moment wyświetlenia widocznych części strony. Mniej znaczy lepiej, a wynik jest raportowany w sekundach.

Najbardziej przejrzysty model mentalny wygląda tak: narysuj wykres, na którego osi X znajduje się czas, a na osi Y „procent strony ukończonej wizualnie”, rosnący od 0 % do 100 %. Speed Index to obszar nad tą krzywą. Im szybciej krzywa dociera do 100 %, tym mniejszy jest obszar i tym lepszy wynik. Strona pusta przez pewien czas zostawia nad linią duży prostokąt pustego obszaru; strona szybko renderująca treść pozostawia go prawie wcale.

Jak jest obliczany

Lighthouse nagrywa film z ładowania strony i oblicza postęp wizualny między klatkami. Każdy przedział czasu otrzymuje wagę zależną od tego, jak nieukończona jest wtedy strona — całkowicie pusta klatka liczy się w 100 %, a klatka w większości wyrenderowana ma bardzo mały udział. Oryginalny wzór WebPageTest wygląda tak:

Speed Index = Σ ( interval × (1 − visual completeness% / 100) )

Przykład z konkretnymi liczbami ułatwia zrozumienie. DebugBear przedstawia jedno ładowanie tak:

• Ukończenie 0 % (0–253 ms) → wkład 253,0 ms
• Ukończenie 43 % (253–403 ms) → wkład 85,5 ms
• Ukończenie 98 % (403–536 ms) → wkład 2,7 ms
• Ukończenie 99 % (536–653 ms) → wkład 1,2 ms
• Łącznie: 342,3 ms

Zwróć uwagę na pierwszy fragment: gdy nic nie jest widoczne, cały ten czas liczy się z pełną wagą. Dlatego Speed Index nigdy nie może być szybszy niż First Contentful Paint — każda milisekunda przed wyrenderowaniem pierwszej treści liczy się w 100 %.

Lighthouse nie tworzy tu własnej implementacji. Uruchamia open-source’owy moduł Speedline (pierwotnie autorstwa Paula Irisha), który stosuje tę samą metodologię postępu wizualnego z filmu co WebPageTest, korzystając ze śladów Chrome DevTools z włączonymi zrzutami ekranu. Speedline może obliczać standardowy Speed Index (różnicę histogramów między bieżącą a końcową klatką) albo wariant percepcyjny wykorzystujący SSIM; zwykle widzisz ten standardowy.

Jaki wynik jest dobry

Lighthouse 10 ocenia Speed Index na podstawie danych z rzeczywistych witryn z HTTP Archive, a progi znacznie różnią się zależnie od urządzenia, ponieważ Lighthouse domyślnie symuluje urządzenie mobilne średniej klasy z ograniczeniem przepustowości:

Jeśli widziałeś krążący dawny benchmark "under 1,000 ms is good" („poniżej 1 000 ms jest dobrze”), to historyczna wskazówka WebPageTest dla konkretnej epoki i profilu połączenia — nie aktualny próg mobilny Lighthouse. Zawsze sprawdzaj, jakie narzędzie oraz ustawienia urządzenia i sieci wygenerowały analizowaną liczbę, ponieważ ta sama strona otrzymuje różne wyniki w Lighthouse, WebPageTest i GTmetrix.

Miejsce w wyniku Lighthouse

Speed Index jest jedną z pięciu metryk wyniku Lighthouse 10 Performance i ma wagę 10 % — taką samą jak FCP, czyli najniższą:

Praktyczny wniosek: gonienie za Speed Index w izolacji ma niski ROI. Total Blocking Time (30 %) oraz LCP i CLS (po 25 %) znacznie mocniej zmieniają ogólny wynik. Jeśli Speed Index nie jest metryką, która konkretnie nie przechodzi, zwykle więcej zyskasz, poprawiając LCP i TBT — a Speed Index poprawi się przy okazji. W PageSpeed Insights znajdziesz Speed Index w sekcji laboratoryjnej (Lighthouse), a nie w znajdującej się wyżej sekcji danych terenowych.

Czy Speed Index jest Core Web Vital albo czynnikiem rankingowym?

Nie w żadnym z tych znaczeń, a rozróżnienie ma znaczenie, gdy wyjaśniasz raport osobie decyzyjnej.

• Nie jest Core Web Vital. Core Web Vitals to LCP, INP i CLS mierzone u rzeczywistych użytkowników przez CrUX. Speed Index nie należy do tego zestawu i nie pojawia się w raporcie Core Web Vitals w Search Console.
• Nie jest bezpośrednim czynnikiem rankingowym. Sygnał Google dotyczący doświadczenia strony korzysta z terenowych danych Core Web Vitals. Speed Index to diagnostyka wyłącznie laboratoryjna, której Google nie zbiera od prawdziwych użytkowników, więc nie ma bezpośredniej drogi od liczby Speed Index do rankingu.

Związek z rankingiem jest pośredni: problemy powodujące zły Speed Index — wolny TTFB, CSS/JS blokujące renderowanie i niewidoczny tekst podczas podmiany fontu — są tymi samymi problemami, które powodują zły FCP i LCP. Napraw je, a lepszy Speed Index zwykle będzie szedł w parze z lepszym LCP, czyli elementem faktycznie nagradzanym przez Google.

Dlaczego działa tylko w laboratorium

Speed Index potrzebuje filmu z renderowania strony klatka po klatce, a następnie przetwarzania obrazów do obliczenia kompletności wizualnej każdej klatki. To zbyt kosztowne, aby uruchamiać je dla każdego prawdziwego odwiedzającego, więc metryka istnieje wyłącznie w syntetycznych narzędziach laboratoryjnych — Lighthouse, WebPageTest i GTmetrix. Real User Monitoring oraz zbiór danych CrUX po prostu jej nie zawierają. Jeśli potrzebujesz terenowych danych o wydajności, użyj Core Web Vitals; Speed Index służy do diagnozowania renderowania w kontrolowanym teście.

Skąd się wziął

Speed Index powstał w WebPageTest, które Pat Meenan stworzył i udostępnił jako open source w 2008 r. (sama metryka została dodana około 2012 r.). Zaprojektowano go, aby naprawić realną lukę w ówczesnych metrykach:

• Render start mógł nastąpić przy pojedynczym pikselu albo kolorze tła — nie oznaczało to wartościowej treści.
• Document complete (onload) obejmuje elementy poniżej pierwszego ekranu i nieistotne zasoby.

Speed Index rozwiązał ten problem, mierząc wizualną kompletność obszaru powyżej pierwszego ekranu w czasie — jest lepszym przybliżeniem tego, co faktycznie postrzega użytkownik. Lighthouse później przyjął tę metodologię przez moduł Speedline, dlatego liczby WebPageTest i Lighthouse mają wspólne pochodzenie, choć ich ograniczenia przepustowości są różne.

Jak go poprawić

Nie ma sztuczki dotyczącej wyłącznie Speed Index — własne wskazówki Google mówią, że wszystko, co robisz, aby poprawić szybkość ładowania strony, poprawi też wynik Speed Index. W praktyce:

• Skróć czas odpowiedzi serwera (TTFB). Każda milisekunda przed pierwszym bajtem to czas pustej strony liczony z pełną wagą.
• Usuń CSS i JavaScript blokujące renderowanie. Opóźniają pierwszy render, który jest najdroższą częścią krzywej. Wstaw krytyczny CSS inline, a resztę odrocz.
• Napraw ładowanie fontów. Podczas podmiany fontu tekst może być niewidoczny — dla tego fragmentu liczy się 0 % ukończenia. font-display: swap (albo optional) utrzymuje widoczność tekstu. To jeden z audytów, które Lighthouse wyraźnie wskazuje dla Speed Index.
• Zminimalizuj pracę głównego wątku i skróć czas wykonywania JavaScriptu — to dwie pozostałe diagnostyki, które Lighthouse wskazuje jako mające duży wpływ na Speed Index.
• Nadaj priorytet treści powyżej pierwszego ekranu. Speed Index interesuje się tylko widocznym viewportem, więc szybkie wyrenderowanie pierwszego ekranu jest całą grą.

Te działania niemal całkowicie pokrywają się z optymalizacją FCP i LCP — właśnie dlatego traktuję Speed Index jako sygnał potwierdzający, a nie osobną listę zadań. Zanim zareagujesz na pojedynczą liczbę, obejrzyj filmstrip (Lighthouse i WebPageTest generują go oba), aby potwierdzić, co faktycznie renderuje się wcześnie, a co późno, oraz porównaj kilka powtarzanych, identycznych uruchomień zamiast jednego testu — zobacz poniższą uwagę o zmienności między uruchomieniami.

Ograniczenia, które warto znać

• Tylko laboratorium — nigdy nie odzwierciedla doświadczenia prawdziwego użytkownika, a jedynie środowisko testowe.
• Zależność od viewportu — mierzy widoczny obszar, więc urządzenia mobilne i desktopowe dają bardzo różne wyniki (stąd bardzo różne progi).
• Ślepa plama SPA/AJAX — aplikacje jednostronicowe mogą wyglądać sztucznie szybko: powłoka renderuje się szybko, a rzeczywista treść ładuje się później bez odświeżenia strony.
• Karuzele, automatycznie odtwarzane wideo i nakładki zgody — wszystko, co nadal zmienia piksele po załadowaniu istotnej treści, może otrzymać karę za dalsze rejestrowanie stanu „incomplete” („nieukończonego”), tak jak karane są automatycznie obracające się karuzele.
• To nie metryka „fully loaded” („w pełni załadowane”) — mierzy postęp wizualny powyżej pierwszego ekranu, a nie moment zakończenia działania każdego skryptu, obrazu lub elementu poniżej pierwszego ekranu. Osobna metryka WebPageTest Visually Complete (zawsze ≥ Speed Index) wykrywa widget załadowany późno przez lazy loading.
• Postęp wizualny nie dowodzi użyteczności. Speed Index mierzy tylko zmianę pikseli względem końcowej klatki — nie wie, czy to, co jest na ekranie, da się odczytać, jest ułożone poprawnie, dostępne ani faktycznie interaktywne. Szybko renderowany szkielet lub powłoka może otrzymać dobry wynik, mimo że prawdziwa treść (i możliwość korzystania z niej) pojawia się później; to ten sam tryb błędu co antywzorzec „meaningless early paint” („bezsensownego wczesnego renderu”), tylko opisany od strony metryki.
• Zmienność między uruchomieniami. Ponieważ metryka pochodzi z jednego nagranego ładowania, Speed Index zmienia się wraz z warunkami testu — własne wskazówki Google wymieniają różnice urządzeń, rozszerzenia przeglądarki, oprogramowanie antywirusowe, a nawet zmiany reklam i testów A/B jako źródła wahań wyniku niezwiązanych z Twoim kodem. Porównuj rozkłady z powtarzanych, identycznych uruchomień, a nie pojedyncze liczby.

Metryki powiązane

Speed Index należy do tego samego klastra wydajności stron co hub Core Web Vitals i jego sąsiednie tematy. Najbliżej mu do First Contentful Paint (Speed Index nie może być lepszy niż FCP) i Largest Contentful Paint (te same poprawki, te same przyczyny źródłowe), występuje obok Total Blocking Time w wyniku Lighthouse, a spotkasz go w Lighthouse i PageSpeed Insights. W przypadku metryk terenowych, które faktycznie napędzają ranking, zacznij od huba Core Web Vitals.

Podsumowanie AI

Skrócona wersja karty Advanced:

• Speed Index = jak szybko treść jest wizualnie wyświetlana podczas ładowania — wynik zbiorczy (średni moment pojawienia się widocznej treści), a nie pojedynczy znacznik czasu. Raportowany w sekundach; mniej znaczy lepiej.
• Model mentalny: obszar nad krzywą postępu wizualnego (czas kontra procent ukończenia wizualnego). Obliczany na podstawie filmu z ładowania, z wagą każdego przedziału zależną od tego, jak bardzo strona pozostaje nieukończona.
• Tylko laboratorium: wymaga zrzutów ekranu klatka po klatce, więc nie występuje w CrUX, terenowych danych PageSpeed Insights ani Search Console. Do danych terenowych używaj Core Web Vitals.
• Pochodzenie: WebPageTest (Pat Meenan, 2008; metryka około 2012 r.). Lighthouse oblicza ją za pomocą open-source’owego modułu Speedline — tej samej metodologii co WebPageTest.
• Nie jest Core Web Vital ani czynnikiem rankingowym. CWV to LCP, INP i CLS. Związek z rankingiem jest pośredni: naprawa Speed Index zwykle poprawia FCP/LCP.
• Waga w Lighthouse 10: 10 % — taka sama jak FCP, czyli najniższa. TBT (30 %) oraz LCP/CLS (po 25 %) mają znacznie większe znaczenie, więc samo gonienie za Speed Index ma niski ROI.
• Progi (urządzenia mobilne): Good ≤ 3,4 s, Needs improvement ≤ 5,8 s, Poor > 5,8 s; desktop Good ≤ ~1,3 s. Nie może być szybszy niż FCP i zależy od viewportu.
• Poprawki = poprawki FCP/LCP: szybszy TTFB, mniej zasobów blokujących renderowanie, font-display: swap, mniej pracy głównego wątku i JavaScriptu, priorytet treści powyżej pierwszego ekranu.
• Ograniczenia: SPA mogą otrzymywać sztucznie dobre wyniki; karuzele, automatyczne wideo i nakładki zgody mogą być karane; to nie pomiar „w pełni załadowanej” strony; postęp wizualny nie dowodzi, że treść jest czytelna, dostępna lub użyteczna; a pojedyncze uruchomienie mogą zmieniać urządzenie, rozszerzenia albo reklamy i testy A/B niezwiązane z Twoim kodem.

Dokumentacja oficjalna

Dokumentacja źródłowa dotycząca Speed Index.

Google / Lighthouse

• Speed Index (audyt Lighthouse) — kanoniczne źródło: definicja, sposób obliczania przez Lighthouse za pomocą Speedline, progi wyników i audyty optymalizacyjne.
• Ocena wydajności Lighthouse — miejsce opisujące wagę Speed Index równą 10 % i pełny podział metryk.
• Minimalizowanie pracy głównego wątku — jeden z trzech audytów wskazywanych przez Lighthouse jako mający duży wpływ na Speed Index.
• Skracanie czasu wykonywania JavaScriptu — drugi wskazywany audyt.
• Zapewnienie widoczności tekstu podczas ładowania fontu internetowego (font-display) — trzeci wskazywany audyt.

Pochodzenie / implementacja

• Speedline (paulirish/speedline) — open-source’owy moduł używany przez Lighthouse do obliczania Speed Index na podstawie śladów DevTools.
• Źródło Lighthouse — speed-index.js — stała z opisem audytu.
• WebPageTest — informacje — Pat Meenan stworzył i udostępnił WebPageTest jako open source; tam powstał Speed Index.

Cytaty ze źródła

Wypowiedzi dostępne w źródłach. Każdy link Google/Lighthouse prowadzi bezpośrednio do cytowanego fragmentu.

Google — co mierzy Speed Index

• “Speed Index measures how quickly content is visually displayed during page load.” („Speed Index mierzy, jak szybko treść jest wizualnie wyświetlana podczas ładowania strony”). — audyt Speed Index Lighthouse. Przejdź do cytatu

Google — jak ustalany jest wynik

• “Your Speed Index score is a comparison of your page’s speed index and the speed indexes of real websites, based on data from the HTTP Archive.” („Twój wynik Speed Index jest porównaniem Speed Index Twojej strony z wartościami Speed Index rzeczywistych witryn, opartym na danych z HTTP Archive”). — audyt Speed Index Lighthouse. Przejdź do cytatu

Źródła przekazane (sparafrazowane na podstawie dokumentacji wtórnej, a nie zacytowane dosłownie)

• Lighthouse nagrywa film z ładowania strony, oblicza postęp wizualny między klatkami i generuje wynik za pomocą modułu Speedline — na podstawie tych samych zasad co oryginalny Speed Index WebPageTest. (Audyt Speed Index Lighthouse, sekcja obliczeń.)
• Im dłużej klatka jest widoczna i im mniej kompletna jest wtedy strona, tym większy wkład tej klatki w wynik — a ponieważ cały czas przed FCP liczy się w 100 %, Speed Index nie może być szybszy niż First Contentful Paint. (Dokumentacja Speed Index DebugBear.)
• Speed Index jest dostępny wyłącznie w syntetycznych testach laboratoryjnych ze względu na koszt przetwarzania zrzutów klatka po klatce. (Dokumentacja Speed Index DebugBear.)
• Metrykę dodano do WebPageTest około 2012 r., na bazie narzędzia udostępnionego jako open source przez Pata Meenana w 2008 r. (KeyCDN; strona About WebPageTest.)

Ściąga Speed Index

Progi (Lighthouse 10)

Wagi wydajności Lighthouse 10

Szybkie fakty

• Mierzy kompletność wizualną w czasie (obszar nad krzywą postępu), a nie pojedynczy znacznik czasu. Mniej znaczy lepiej.
• Tylko laboratorium — nie występuje w CrUX, terenowych danych PSI ani Search Console.
• Nie jest Core Web Vital ani bezpośrednim czynnikiem rankingowym.
• Nigdy nie może być szybszy niż FCP (czas przed FCP liczy się w 100 %).
• Zależy od viewportu — wyniki mobilne i desktopowe bardzo się różnią.
• Obliczany przez Speedline; powstał w WebPageTest (Pat Meenan).

Popraw go (tak samo jak FCP/LCP)

• Skróć TTFB (szybsza odpowiedź serwera).
• Usuń CSS/JS blokujące renderowanie; wstaw krytyczny CSS inline.
• Użyj font-display: swap / optional, aby tekst pozostał widoczny.
• Zminimalizuj pracę głównego wątku i czas wykonywania JS.
• Nadaj priorytet renderowaniu powyżej pierwszego ekranu.

Nie daj się zwieść

• "Under 1,000 ms" („Poniżej 1 000 ms”) to dawna wskazówka WebPageTest, a nie próg mobilny Lighthouse.
• SPA mogą otrzymywać sztucznie dobre wyniki; karuzele mogą być karane.

Narzędzia raportujące Speed Index

• Lighthouse (w Chrome DevTools, CLI lub module Node) — raportuje Speed Index jako jedną z pięciu metryk Performance, obliczaną przez Speedline.
• PageSpeed Insights — uruchamia Lighthouse i pokazuje Speed Index w sekcji laboratoryjnej (Diagnostics). Uwaga: znajdująca się wyżej sekcja danych terenowych korzysta z Core Web Vitals, więc Speed Index nigdy się w niej nie pojawia.
• WebPageTest — miejsce powstania metryki; raportuje Speed Index obok Visually Complete i widoków filmstripu, z konfigurowalnymi profilami połączeń.
• GTmetrix — pokazuje Speed Index w swoim interfejsie, korzystając z danych WebPageTest; jego liczby nie będą zgodne z Lighthouse z powodu innych symulacji urządzenia i sieci.
• DebugBear — monitoring syntetyczny z przejrzystym rozbiciem klatka po klatce pokazującym obliczenie wyniku Speed Index.

Pamiętaj przy porównywaniu narzędzi: ta sama strona generuje różne wartości Speed Index w Lighthouse, WebPageTest i GTmetrix z powodu różnych ograniczeń przepustowości i założeń dotyczących urządzeń. Porównuj identyczne warunki z identycznymi.

Błędy Speed Index marnujące czas na optymalizację

• Nazywanie Speed Index Core Web Vital. To metryka postępu wizualnego wyłącznie laboratoryjna, a nie terenowy sygnał rankingowy. Używaj jej do diagnozowania, jak wypełnia się strona, a następnie osobno sprawdzaj rzeczywiste Core Web Vitals.
• Porównywanie progów mobilnych i desktopowych. Lighthouse używa różnych krzywych oceniania i warunków testu. Śledź jeden profil w czasie, zamiast traktować oba wyniki jako zamienne.
• Poprawianie liczby bezsensownym wczesnym renderem. Powłoka nagłówka może sprawić, że postęp wizualny zacznie się wcześniej, podczas gdy główna treść pozostanie pusta. Przejrzyj filmstrip ładowania razem z metryką.
• Optymalizowanie każdego obrazu przed sprawdzeniem ścieżki krytycznej. Wolny TTFB, CSS blokujący renderowanie, fonty i synchroniczny JavaScript mogą opóźnić całą sekwencję wizualną. Znajdź pierwsze wąskie gardło w waterfallu i prześledź je.
• Oczekiwanie stabilnej wartości z jednego uruchomienia. Speed Index pochodzi z syntetycznego filmu i zmienia się wraz ze środowiskiem testu. Powtarzaj porównywalne uruchomienia, zanim ogłosisz regresję albo sukces.

Sprawdź się: Speed Index

Pięć krótkich pytań o to, co mierzy Speed Index. Wybierz odpowiedź na każde, a następnie sprawdź wynik.

Zasoby warte Twojego czasu

Oficjalne

• Speed Index — audyt Lighthouse — kanoniczna definicja, progi i audyty optymalizacyjne.
• Ocena wydajności Lighthouse — wagi metryk, w tym 10 % dla Speed Index.
• WebPageTest — informacje — miejsce powstania metryki.

Implementacja

• paulirish/speedline — open-source’owy moduł używany przez Lighthouse do obliczania Speed Index.

Inni autorzy

• DebugBear — Speed Index — najjaśniejszy przykład obliczenia krok po kroku i związku z FCP.
• KeyCDN — Speed Index — kontekst historyczny i wzór WebPageTest.
• Catchpoint — Speed Index — spadkobierca bloga WebPageTest; wzór postępu wizualnego i ograniczenia SPA/karuzel.
• Google Search Central — Core Web Vitals — potwierdza, że LCP, INP i CLS są sygnałami rankingowymi; Speed Index nie jest wymieniony, co wzmacnia wniosek o braku bezpośredniego wpływu na ranking.
• web.dev — omówienie Vitals — autorytatywna definicja Core Web Vitals (LCP, INP, CLS); Speed Index jest nieobecny, co pomaga wyjaśnić, dlaczego nie wpływa na ranking.
• WebPageTest — dokumentacja Speed Index — informacje o stworzeniu WebPageTest przez Pata Meenana (open source w 2008 r.) i pochodzeniu metryki Speed Index.

Liczby warte cytowania

• Waga Lighthouse: 10 % wyniku Performance w Lighthouse 10 — taka sama jak FCP, czyli najniższa, znacznie mniejsza niż TBT (30 %) i LCP/CLS (po 25 %). Źródło
• Mobilne „Good” ≤ 3,4 s; desktopowe „Good” ≤ 1,3 s — progi Lighthouse 10 skalibrowane na podstawie danych o rzeczywistych witrynach z HTTP Archive. Źródło
• Speed Index ≥ FCP, zawsze — cały czas przed wyrenderowaniem pierwszej treści liczy się w 100 %, więc Speed Index nie może być szybszy niż First Contentful Paint. Źródło
• Pochodzenie: WebPageTest, około 2012 r. — metrykę dodano do narzędzia udostępnionego jako open source przez Pata Meenana w 2008 r. Źródło

Dziennik zmian