Pomiar i optymalizacja wskaźników internetowych Google Core: techniczny przewodnik SEO

Gromadzenie danych na temat wydajności witryny to pierwszy krok w kierunku zapewnienia użytkownikom doskonałej obsługi. Przez lata Google udostępniał różne narzędzia do oceny i raportowania wydajności sieci.

Wśród nich znajdują się Core Web Vitals – zestaw sygnałów dotyczących wydajności, które Google uważa za kluczowe dla wszystkich doświadczeń internetowych.

W tym artykule omówiono bieżący zestaw podstawowych wskaźników internetowych oraz najważniejsze wskazówki i narzędzia umożliwiające poprawę wydajności sieci i zapewnienie użytkownikom dobrego komfortu korzystania ze strony.

Spojrzenie na ewolucję wydajności sieci

Dawno minęły czasy, gdy poprawa wydajności witryny była prosta.

W przeszłości rozdęte zasoby i opóźnione połączenia często blokowały strony internetowe. Możesz jednak wyprzedzić konkurencję, kompresując niektóre obrazy, włączając kompresję tekstu lub minimalizując arkusze stylów i moduły JavaScript.

Obecnie prędkości połączeń są szybsze. Większość zasobów jest domyślnie kompresowana, a wiele wtyczek obsługuje kompresję obrazu, wdrażanie pamięci podręcznej itp.

Pogoń Google za szybszym internetem nie ustaje. PageSpeed ​​Insights (PSI) jest nadal dostępny w web.dev i stanowi najlepsze narzędzie do oceny poszczególnych wczytań stron.

Chociaż wiele osób uważa, że ​​oceny PSI są niepotrzebnie karalne, nadal są one najbliższe temu, jak Google może oceniać i pozycjonować witryny na podstawie sygnałów dotyczących szybkości strony.

Aby przejść najnowszą wersję testu szybkości strony Google, musisz przejść ocenę Core Web Vitals.

Zrozumienie podstawowych wskaźników internetowych

Podstawowe wskaźniki internetowe to zestaw wskaźników zintegrowanych z szerszymi sygnałami wyszukiwania dotyczącymi jakości strony wprowadzonymi w 2021 r. Każdy wskaźnik „reprezentuje odrębny aspekt doświadczenia użytkownika, jest mierzalny w terenie i odzwierciedla rzeczywiste doświadczenia krytycznego użytkownika – skoncentrowany wynik” – podaje Google.

Aktualny zestaw wskaźników Core Web Vitals obejmuje:

• Pierwsza treściwa farba
• Opóźnienie pierwszego wejścia (zastąpione interakcją z następnym malowaniem)
• Interakcja z Next Paint
• Czas do pierwszego bajtu
• Największa treściwa farba
• Łączne przesunięcie układu

Web.dev wyjaśnia, jak działają poszczególne metryki w następujący sposób.

Pierwsza merytoryczna farba (FCP)

„Wskaźnik First Contentful Paint (FCP) mierzy czas od rozpoczęcia ładowania strony do wyrenderowania dowolnej części zawartości strony na ekranie. W przypadku tej metryki „treść” odnosi się do tekstu, obrazów (w tym obrazów tła), elementów <svg> lub elementów <canvas> w kolorze innym niż biały.

Co to oznacza dla technicznego SEO

FCP jest dość łatwe do zrozumienia. Podczas ładowania strony internetowej niektóre elementy pojawiają się (lub „są malowane”) wcześniej niż inne. W tym kontekście „malowanie” oznacza renderowanie na ekranie.

Po wyrenderowaniu dowolnej części strony – powiedzmy, że główny pasek nawigacyjny zostanie załadowany przed innymi elementami – FCP zostanie w tym momencie zalogowany.

Pomyśl o tym, jak szybko strona zaczyna się widocznie ładować dla użytkowników. Ładowanie strony nie zostanie zakończone, ale się rozpocznie.

Opóźnienie pierwszego wejścia (FID)

„FID mierzy czas od pierwszej interakcji użytkownika ze stroną (tzn. kliknięcia łącza, dotknięcia przycisku lub użycia niestandardowej kontrolki opartej na JavaScript) do momentu, w którym przeglądarka może faktycznie rozpocząć przetwarzanie procedur obsługi zdarzeń w odpowiedzi na tę interakcję.”

Co to oznacza dla technicznego SEO

FID to zestaw wskaźników reakcji użytkownika na interakcję, który w marcu 2024 r. zostanie zastąpiony przez interakcję z następną farbą (INP).

Jeśli użytkownik wchodzi w interakcję z elementem na stronie (np. łączem, sortuje tabelę lub stosuje nawigację aspektową), ile czasu zajmie witrynie rozpoczęcie przetwarzania tego żądania?

Interakcja z następną farbą (INP)

„INP to wskaźnik, który ocenia ogólną reakcję strony na interakcje użytkownika, obserwując opóźnienie wszystkich interakcji związanych z kliknięciem, dotknięciem i klawiaturą, które mają miejsce przez cały czas trwania wizyty użytkownika na stronie. Ostateczna wartość INP to najdłuższa zaobserwowana interakcja, ignorując wartości odstające.

Co to oznacza dla technicznego SEO

Jak wspomniano, INP zastąpi FID jako Core Web Vital w marcu 2024 r.

INP uwzględnia głębsze informacje (najwyraźniej sięgające aż do klawiatury) i jest prawdopodobnie bardziej szczegółowy i wyrafinowany.

Czas do pierwszego bajtu (TTFB)

„TTFB to metryka mierząca czas między żądaniem zasobu a momentem, w którym zaczyna napływać pierwszy bajt odpowiedzi”.

Co to oznacza dla technicznego SEO

Po zażądaniu „zasobu” (tj. osadzonego obrazu, modułu JavaScript, arkusza stylów CSS itp.) ile czasu zajmie witrynie rozpoczęcie dostarczania tego zasobu?

Załóżmy, że odwiedzasz stronę internetową, a na tej stronie znajduje się osadzony obraz. Zaczyna się ładować, ale jeszcze się nie skończyło. Po jakim czasie pierwszy bajt tego obrazu zostanie dostarczony z serwera do klienta (przeglądarki internetowej)?

Największa zawartość farby (LCP)

„Wskaźnik Largest Contentful Paint (LCP) podaje czas renderowania największego obrazu lub bloku tekstu widocznego w widocznym obszarze w porównaniu z momentem rozpoczęcia ładowania strony”.

Co to oznacza dla technicznego SEO

LCP to jeden z najważniejszych wskaźników, a jednocześnie najtrudniejszy do spełnienia.

Po załadowaniu największej porcji multimediów wizualnych (tj. tekstu lub obrazu) następuje rejestracja LCP.

Możesz to przeczytać jako: ile czasu zajmuje załadowanie większości głównej zawartości strony?

Być może w dalszej części strony nadal ładują się małe fragmenty i rzeczy, których większość użytkowników nie zauważy.

Jednak do czasu zalogowania LCP załadowana została duża i oczywista część Twojej strony. Jeśli zajmie to zbyt dużo czasu, test LCP zakończy się niepowodzeniem.

Łączne przesunięcie układu (CLS)

„CLS to miara największej liczby zmian w układzie dla każdej nieoczekiwanej zmiany układu, która ma miejsce w ciągu całego okresu istnienia strony.

Przesunięcie układu następuje za każdym razem, gdy widoczny element zmienia swoje położenie z jednej renderowanej klatki na następną. (Zobacz poniżej szczegółowe informacje na temat sposobu obliczania indywidualnych wyników przesunięć układu.)

Seria zmian układu, nazywana oknem sesji, ma miejsce wtedy, gdy jedna lub więcej pojedynczych zmian układu następuje w krótkich odstępach czasu, z przerwami krótszymi niż 1 sekunda pomiędzy każdą zmianą i maksymalnie 5 sekundami przez całkowity czas trwania okna.

Największy impuls to okno sesji z maksymalnym skumulowanym wynikiem wszystkich zmian układu w tym oknie.

Co to oznacza dla technicznego SEO

W czasach, gdy optymalizacja szybkości strony była prostsza, wielu właścicieli witryn zdało sobie sprawę, że mogą osiągnąć niewiarygodnie wysokie oceny szybkości strony, po prostu odraczając wszystkie zasoby blokujące renderowanie (zwykle arkusze CSS i moduły JavaScript).

Świetnie przyspieszało to ładowanie stron, ale sprawiało, że nawigacja w Internecie była bardziej niestabilna i irytująca.

Jeśli CSS – który kontroluje cały styl Twojej strony – zostanie odroczony, zawartość strony będzie mogła zostać załadowana przed zastosowaniem reguł CSS.

Oznacza to, że zawartość Twojej strony zostanie załadowana bez stylu, a następnie nieco przeskoczy podczas ładowania CSS.

Jest to naprawdę denerwujące, jeśli ładujesz stronę i klikasz łącze, ale potem łącze przeskakuje i klikasz niewłaściwy link.

Jeśli tak jak ja cierpisz na zaburzenia obsesyjno-kompulsyjne, takie doświadczenia są absolutnie irytujące (mimo że kosztują tylko sekundy).

Ponieważ właściciele witryn próbowali „ograć” oceny szybkości strony poprzez odroczenie wszystkich zasobów, Google potrzebował licznika, który zrównoważyłby cały wzrost szybkości strony w stosunku do deficytu komfortu użytkownika.

Wprowadź skumulowane przesunięcie układu (CLS). To podstępny klient, który chce zrujnować Twój dzień, jeśli spróbujesz szeroko zakrojony zwiększyć szybkość strony, nie myśląc o swoich użytkownikach.

CLS zasadniczo przeanalizuje ładowanie strony pod kątem usterek i opóźnionych reguł CSS.

Jeśli jest ich zbyt wiele, nie przejdziesz oceny Core Web Vitals pomimo spełnienia wszystkich wskaźników związanych z szybkością.

Ocena podstawowych wskaźników internetowych w celu uzyskania lepszych wyników UX i SEO

Jednym z najlepszych sposobów analizy wydajności pojedynczej strony internetowej jest załadowanie jej do PageSpeed ​​Insights. Widok jest podzielony na kombinację:

• Dane na poziomie adresu URL.
• Dane pochodzenia (na poziomie domeny).
• Dane laboratoryjne.
• Dane terenowe.

Aby to zrozumieć, musimy spojrzeć na przykład:

https://pagespeed.web.dev/analytic/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Tutaj możemy zobaczyć oceny i wskaźniki szybkości strony dla strony głównej TechCrunch.

Powyżej widać, że ocena podstawowych wskaźników internetowych nie powiodła się.

W internecie zorientowanym przede wszystkim na urządzenia mobilne ważne jest wybranie karty Wyniki na urządzeniach mobilnych , która powinna być domyślnie renderowana (to właśnie te wyniki mają największe znaczenie).

Wybierz przełącznik Pochodzenie , aby wyświetlić ogólne dane uśrednione dla całej domeny Twojej witryny, a nie tylko stronę główną (lub inną stronę, którą umieścisz do przeskanowania).

W dalszej części strony zobaczysz stary, znany numeryczny wskaźnik szybkości strony:

Jaka jest zatem różnica między nową oceną Core Web Vitals a starą oceną szybkości strony?

Zasadniczo nowa ocena Core Web Vitals (pozytywny/negatywny) opiera się na danych terenowych (prawdziwego użytkownika).

Stara ocena liczbowa opiera się na symulowanych indeksowaniach mobilnych i danych laboratoryjnych, które mają jedynie charakter szacunkowy.

Zasadniczo Google przeszło na ocenę Core Web Vitals w zakresie modyfikowania rankingów wyszukiwania.

Żeby było jasne, symulowane dane laboratoryjne mogą dać dobry obraz tego, co się dzieje nie tak, ale Google nie wykorzystuje tej oceny liczbowej w swoich algorytmach rankingowych.

Z drugiej strony ocena Core Web Vitals nie dostarcza zbyt wielu szczegółowych informacji. Ocena ta jest jednak uwzględniana w algorytmach rankingowych Google.

Twoim głównym celem jest zatem wykorzystanie bogatszej diagnostyki laboratoryjnej, aby ostatecznie przejść ocenę Core Web Vitals (na podstawie danych terenowych).

Pamiętaj, że gdy wprowadzisz zmiany w swojej witrynie, choć ocena liczbowa może natychmiast zauważyć zmiany, musisz poczekać, aż Google pobierze więcej danych z pola, zanim będziesz mógł ostatecznie przejść ocenę Core Web Vitals.

Zauważysz, że zarówno ocena Core Web Vitals, jak i stara ocena szybkości strony wykorzystują niektóre z tych samych wskaźników.

Na przykład oba odnoszą się do pierwszego malowania zawartości (FCP), największego malowania zawartości (LCP) i skumulowanego przesunięcia układu (CLS).

W pewnym sensie rodzaje wskaźników badanych przez każdy system ratingowy są dość podobne. Inny jest poziom szczegółowości i źródło badanych danych.

Musisz dążyć do zdania terenowej oceny Core Web Vitals. Ponieważ jednak dane nie są zbyt bogate, możesz chcieć wykorzystać tradycyjne dane laboratoryjne i diagnostykę, aby uzyskać postęp.

Mamy nadzieję, że uda Ci się przejść ocenę Core Web Vitals, korzystając z możliwości laboratorium i diagnostyki. Pamiętaj jednak, że te dwa testy nie są ze sobą powiązane.

Ocena CWV za pomocą PageSpeed ​​Insights

Teraz, gdy znasz już główne wskaźniki Core Web Vitals i wiesz, jak technicznie można je spełnić, czas przejść do przykładu.

Wróćmy do naszego badania TechCruncha:

https://pagespeed.web.dev/analytic/https-techcrunch-com/zo8d0t4x1p?form_factor=mobile

Tutaj FID jest spełniony, a INP zawodzi jedynie z niewielkim marginesem.

CLS ma pewne problemy, ale główne problemy dotyczą LCP i FCP.

Zobaczmy, co PageSpeed ​​Insights ma do powiedzenia na temat możliwości i diagnostyki .

Musimy teraz przejść od danych terenowych do danych laboratoryjnych i spróbować wyizolować wszelkie wzorce, które mogą mieć wpływ na podstawowe wskaźniki internetowe:

Powyżej możesz zobaczyć małą podnawigację w prawym górnym rogu, oznaczoną na zielono.

Możesz to wykorzystać, aby zawęzić różne możliwości i diagnostykę do określonych wskaźników Core Web Vitals.

W tym przypadku jednak dane mówią bardzo wyraźnie, bez zawężeń.

Po pierwsze, powiedziano nam, abyśmy zredukowali nieużywany JavaScript. Oznacza to, że czasami JavaScript jest ładowany bez wykonywania.

Istnieją również uwagi dotyczące ograniczenia nieużywanego CSS. Innymi słowy, ładuje się styl CSS, który nie jest stosowany (podobny problem).

Powiedziano nam również, abyśmy wyeliminowali zasoby blokujące renderowanie, które prawie zawsze są powiązane z modułami JavaScript i arkuszami CSS.

Zasoby blokujące renderowanie muszą zostać odroczone, aby zapobiec blokowaniu ładowania strony. Jednakże, jak już ustaliliśmy, może to zakłócić ocenę CLS.

Z tego powodu mądrze byłoby rozpocząć tworzenie zarówno krytycznej ścieżki renderowania CSS, jak i krytycznej ścieżki renderowania JavaScript. Spowoduje to wstawienie potrzebnego kodu JavaScript i CSS w części strony widocznej na ekranie, a resztę odroczy.

Takie podejście umożliwia właścicielowi witryny zaspokojenie wymagań dotyczących ładowania strony, jednocześnie równoważąc metrykę CLS. Nie jest to łatwe zadanie i zazwyczaj wymaga starszego programisty WWW.

Ponieważ znaleźliśmy również nieużywany CSS i JavaScript, możemy również przeprowadzić ogólny audyt kodu JavaScript, aby sprawdzić, czy JavaScript mógłby zostać wdrożony w bardziej inteligentny sposób.

Wróćmy do możliwości i diagnostyki :

Teraz chcemy się skupić na diagnostyce. Google celowo ogranicza te kontrole ze względu na słabe połączenia 4G, przez co elementy takie jak praca głównego wątku wydają się tak długie (17 sekund).

Jest to celowe, aby zadowolić użytkowników o małej przepustowości i/lub wolnych urządzeniach, które są powszechne na całym świecie.

Chcę zwrócić tutaj uwagę na „Zminimalizuj pracę głównego wątku”. Ten pojedynczy wpis jest często kopalnią spostrzeżeń.

Domyślnie większość zadań związanych z renderowaniem strony internetowej i wykonywaniem skryptów (JavaScript) jest przekazywana przez główny wątek przetwarzający przeglądarki internetowej klienta (jeden pojedynczy wątek przetwarzający). Możesz zrozumieć, jak powoduje to znaczne wąskie gardła podczas ładowania strony.

Nawet jeśli cały kod JavaScript zostanie idealnie zminimalizowany i szybko przesłany do przeglądarki użytkownika, domyślnie musi on czekać w kolejce przetwarzania pojedynczego wątku, co oznacza, że ​​jednocześnie można wykonać tylko jeden skrypt.

Zatem szybkie przesłanie użytkownikowi dużej ilości kodu JavaScript jest równoznaczne z wystrzeleniem węża strażackiego w ceglaną ścianę z jednocentymetrową przerwą.

Dobra robota, ale nie wszystko przejdzie!

Coraz częściej Google kładzie nacisk na szybkość reakcji po stronie klienta jako nasz obowiązek. Podobać się lub zwalić, tak to właśnie jest (więc lepiej się zaznajom).

Możesz powiedzieć z frustracją: „Dlaczego tak jest!? Przeglądarki internetowe od lat mają dostęp do wielu wątków przetwarzania, nawet przeglądarki mobilne nadrabiają zaległości. Nie ma potrzeby, żeby było tak niezręcznie, prawda?

Aktualnie tak. Niektóre skrypty korzystają z danych wyjściowych innych skryptów, zanim same będą mogły zostać wykonane.

Najprawdopodobniej, gdyby wszystkie przeglądarki nagle zaczęły przetwarzać cały kod JavaScript równolegle i poza kolejnością, większość sieci prawdopodobnie uległaby awarii i spaleniu.

Istnieje więc dobry powód, dla którego sekwencyjne wykonywanie skryptów jest domyślnym zachowaniem nowoczesnych przeglądarek internetowych. Ciągle podkreślam słowo „domyślny”. Dlaczego?

Dzieje się tak dlatego, że istnieją inne opcje. Jednym z nich jest uniemożliwienie przeglądarce klienta przetwarzania jakichkolwiek skryptów poprzez przetwarzanie ich w imieniu użytkownika. Nazywa się to renderowaniem po stronie serwera (SSR).

Jest to potężne narzędzie do rozplątywania węzłów wykonawczych JavaScript po stronie klienta, ale jest też bardzo drogie.

Twój serwer musi przetwarzać wszystkie żądania skryptów (od wszystkich użytkowników) szybciej niż przeglądarka przeciętnego użytkownika przetwarza pojedynczy skrypt. Pozwól temu zapaść w pamięć na chwilę.

Nie jesteś fanem tej opcji? OK, przyjrzyjmy się równoległości JavaScript. Podstawową ideą jest wykorzystanie pracowników sieciowych do zdefiniowania, które skrypty będą ładowane sekwencyjnie, a które mogą być ładowane równolegle.

Chociaż możesz wymusić równoległe ładowanie JavaScript, robienie tego domyślnie jest wyjątkowo niewskazane. W większości przypadków zintegrowanie takiej technologii w znacznym stopniu ograniczyłoby potrzebę stosowania SSR.

Jednakże wdrożenie tego będzie bardzo trudne i będzie wymagało (zgadliście!) czasu starszego programisty WWW.

Ten sam facet, którego zatrudnisz do przeprowadzenia pełnego audytu kodu JavaScript, również może Ci w tym pomóc. Jeśli połączysz równoległość JavaScriptu z krytyczną ścieżką renderowania JavaScript, to naprawdę polecisz.

W tym przykładzie oto naprawdę interesująca rzecz:

Od razu widać, że podczas gdy główny wątek jest zajęty przez 17 sekund, wykonanie JavaScript zajmuje 12 sekund.

Czy to oznacza, że ​​12 sekund z 17 sekund pracy wątku to wykonywanie JavaScriptu? Jest to bardzo prawdopodobne.

Wiemy, że cały JavaScript jest domyślnie przepuszczany przez główny wątek.

Tak też domyślnie skonfigurowany jest WordPress, aktywny CMS.

Ponieważ na tej stronie działa WordPress, wszystkie 12 sekund czasu wykonania JavaScript prawdopodobnie pochodzi z 17 sekund pracy głównego wątku.

To świetny spostrzeżenie, ponieważ mówi nam, że większość czasu głównego wątku przetwarzającego spędzana jest na wykonywaniu JavaScript. Patrząc na liczbę przywołanych skryptów, nie trudno w to uwierzyć.

Ruszamy z krucjatą do narzędzi deweloperskich Chrome

Czas przejść do spraw technicznych i zdjąć koła treningowe.

Otwórz nową instancję przeglądarki Chrome. Powinieneś otworzyć profil gościa, aby upewnić się, że nie ma bałaganu ani włączonych wtyczek, które mogłyby zawyżać nasze ustalenia.

Pamiętaj: wykonaj te czynności z czystego profilu gościa Chrome.

Załaduj witrynę, którą chcesz przeanalizować. W naszym przypadku jest to TechCrunch.

W razie potrzeby zaakceptuj pliki cookie. Po załadowaniu strony otwórz Chrome DevTools (kliknij stronę prawym przyciskiem myszy i wybierz Sprawdź ).

Przejdź do opcji Wydajność > Zrzuty ekranu.

Naciśnij przycisk ponownego ładowania, aby zarejestrować ładowanie strony. Następnie zostanie wygenerowany raport:

W tym momencie wszyscy musimy wziąć głęboki oddech i spróbować nie wpadać w panikę.

Powyżej, w zielonej ramce, widać cienki panel ilustrujący żądania na przestrzeni czasu.

W tym polu możesz przeciągnąć myszką, aby wybrać przedział czasu, a reszta strony i analizy zostaną automatycznie dostosowane.

Region, który wybrałem ręcznie, to obszar pokryty półprzezroczystym niebieskim prostokątem.

To tam następuje ładowanie strony głównej i to właśnie chcę sprawdzić.

W tym przypadku z grubsza wybrałem zakres czasu i zdarzeń od 32 ms do 2,97 sekundy. Skupmy wzrok na wnętrzu głównego wątku:

Pamiętasz, jak mówiłem wcześniej, że większość zadań renderowania i wykonywania JavaScript jest wymuszana przez wąskie gardło głównego wątku?

Cóż, teraz przyglądamy się wnętrzu tego głównego wątku na przestrzeni czasu. I tak, na żółto widać wiele zadań skryptowych.

W miarę upływu czasu w kilku górnych wierszach pojawia się coraz więcej ciemnożółtych fragmentów potwierdzających wszystkie wykonywane skrypty i czas ich przetwarzania. Możesz kliknąć poszczególne fragmenty słupków, aby uzyskać odczyt dla każdego elementu.

Chociaż jest to potężna grafika, w sekcji Podsumowanie znajdziesz jeszcze potężniejszą:

To podsumowuje wszystkie szczegółowe dane, podzielone na proste sekcje tematyczne (np. Skrypty , Ładowanie , Renderowanie ) za pomocą łatwego do zrozumienia medium wizualnego w postaci wykresu pierścieniowego.

Jak widać, skrypty (wykonanie skryptu) zajmują większość ładowania strony. Zatem nasze wcześniejsze przypuszczenie, oparte na połączeniu danych terenowych i laboratoryjnych Google, które wskazywało na wąskie gardła w wykonywaniu JavaScript w głównym wątku, wydaje się trafne.

W 2023 r. jest to jeden z najczęściej spotykanych problemów, z kilkoma prostymi, gotowymi rozwiązaniami.

Tworzenie krytycznych ścieżek renderowania JavaScript jest skomplikowane. Przeprowadzanie audytów kodu JavaScript wymaga specjalistycznej wiedzy, a przyjęcie równoległości JavaScript lub SSR nie jest takie proste.

Teraz chodźmy i spójrzmy na drzewo wywołań :

Drzewo połączeń jest często bardziej przydatne niż od dołu do góry .

Dane są podobne, ale Call Tree pogrupuje tematycznie zadania w przydatne segmenty, takie jak Evaluate Script (wykonanie skryptu).

Następnie możesz kliknąć grupę, rozwinąć ją i zobaczyć skrypty oraz czas ich ładowania. Ładowanie pubads_impl.jsm zajmowało 11% czasu, a ładowanie opus.js zajmowało 6% czasu.

Nie wiem, co to za moduły (i ty pewnie też nie), ale od tego często zaczyna się podróż optymalizacji.

Możemy teraz cofnąć się o krok:

• Wygoogluj te skrypty i sprawdź, czy są częścią bibliotek stron trzecich, co robią i jaki jest wpływ.
• Skonsultuj się z programistą, aby dowiedzieć się, w jaki sposób można je inteligentniej wdrożyć.
• Zawęź problem do poszczególnych zasobów i poszukaj alternatyw.
• Pozbądź się deficytu wydajności (lub alternatywnie walcz o więcej zasobów/przepustowości i silne środowisko hostingowe – jeśli jest to rzeczywiście wymagane).

Inne narzędzia do pomiaru i optymalizacji podstawowych wskaźników internetowych

Jeżeli udało Ci się wytrwać ze mną aż do tego momentu, gratuluję. Jeśli chodzi o głębokie podstawowe wskaźniki internetowe i analizę szybkości strony, wykorzystaliśmy tylko:

• Statystyki PageSpeed
• Chrome DevTools (karta Wydajność )

Tak, naprawdę możesz być aż tak szczupły. Istnieją jednak inne narzędzia, które mogą okazać się niezwykle pomocne:

• GTMetrix : Szczególnie przydatny w przypadku wykresu kaskadowego (wymaga darmowego konta dla wodospadu), który możesz przeczytać tutaj. Nie zapominaj, że GTMetrix będzie domyślnie działał bez ograniczeń, co daje zbyt korzystne wyniki. Pamiętaj, aby ustawić połączenie LTE.
• Google Search Console : jeśli skonfigurujesz tę opcję i zweryfikujesz swoją witrynę, możesz zobaczyć wiele danych dotyczących wydajności i użyteczności na przestrzeni czasu, w tym wskaźniki Core Web Vitals na wielu stronach (zagregowane).
• Screaming Frog SEO Spider : można go połączyć z interfejsem API szybkości strony, aby umożliwić masowe pobieranie ocen pozytywnych lub negatywnych w zakresie podstawowych wskaźników internetowych (dla wielu stron). Jeśli korzystasz z bezpłatnego interfejsu API szybkości strony, nie wbijaj go w nierozsądny sposób

Poprawa wskaźników szybkości strony była wcześniej tak prosta, jak kompresowanie i przesyłanie niektórych obrazów.

Obecnie? To złożona krucjata dotycząca podstawowych wskaźników internetowych.

Przygotuj się do pełnego zaangażowania. Wszystko mniejsze będzie oznaczać porażkę.