Dziura w ramce: luka PageSpeed ​​6.0 ułatwiająca uzyskanie idealnego wyniku

Każdy dobry programista internetowy wie, że Google PageSpeed ​​Insights i open source Lighthouse używane za kulisami są najnowocześniejszymi narzędziami pomagającymi określić względną wydajność witryny. Oferują również kluczowe informacje o tym, jakie zmiany możesz wprowadzić, aby poprawić tę postrzeganą prędkość. PageSpeed ​​stał się złotym standardem szybkości i powolności w sieci.

Nie zaszkodzi to, że sami Google śledzą teraz ten wynik PageSpeed ​​każdej witryny i używają go jako jednego z wielu danych wejściowych do ustalenia, kto dostaje się na szczyt wyników wyszukiwania, a kto jest zesłany do czyśćca na stronie 10.

Cała branża i wiele milionów dolarów zmienia ręce tylko po to, aby zoptymalizować i poprawić ten wynik w nadziei na zbliżenie się do nieosiągalnego idealnego wyniku 100. Najnowsza wersja PageSpeed/Lighthouse 6.0 zawiera nowy zestaw preferowanych wskaźników dla programistów na całym świecie do optymalizacji. Te nowe metryki to: Największe malowanie treści (LCP), skumulowane przesunięcie układu (CLS) i łączny czas blokowania (TBT). Google ma cały artykuł wyjaśniający te nowe „Wskaźniki internetowe”, które świetnie się spisują, szczegółowo opisując sposób ich pomiaru.

Dzięki tej nowej wersji branża zajmująca się wydajnością sieci Web może sprzedawać więcej usług, ponieważ strony internetowe potrzebują teraz świeżych i innych zmian w dążeniu do osiągnięcia najwyższego wyniku. Cóż, nie musisz wydawać ani grosza, pokażę ci prostą zmianę, która natychmiast zabierze Cię nawet z otchłani 60-punktowego piekła, aż do 100-punktowego nieba.

TLDR: PageSpeed ​​nie uwzględnia już wpływu na szybkość osadzania stron trzecich, takich jak YouTube i reklamy

Jeśli chcesz tylko mięsa, odpowiedzią jest to, że najnowsze zmiany Google kładą duży nacisk na największą zawartość treści. Jest to miara tego, jak długo zajmuje wyświetlenie największego elementu na ekranie podczas ładowania strony internetowej. To dobre proxy dla postrzegania szybkości ładowania przez użytkownika. Problem polega na tym, że największa zawartość treściowa nie bierze pod uwagę żadnej osadzonej zawartości, nawet jeśli ta zawartość technicznie kwalifikuje się jako największy element w części strony widocznej na ekranie.

Nie zastanawiając się nad motywacjami do nieujawniania wpływu na wydajność osadzonych treści stron trzecich, takich jak filmy na YouTube i duże osadzone reklamy, powiedziałbym po prostu, że zachęci to ludzi do wprowadzenia niewłaściwych zmian w celu zwiększenia szybkości i cofnie się w Internecie.

Na przykład wydaje się to niedorzeczne, choć nie jest to nieprawdopodobne, biorąc pod uwagę, jak ważny stał się wynik PageSpeed. Poprawiamy wynik PageSpeed ​​witryny z 60 do 100, po prostu umieszczając w ramce oryginalną, powolną wersję witryny. Krótkie polecenia potwierdzające wyniki są tutaj, ale przeczytaj poniżej, aby zobaczyć, jak użytkownik optymalizujący swój wynik przechodzi do naszego ostatecznego rozwiązania Framehole.

 # Verify you have the new Lighthouse 6.0 installed npm install -g lighthouse # This one should have a score somewhere around 60 :( lighthouse https://webvitalsfail.b-cdn.net/ --view # Instantly to 100 lighthouse https://webvitalsfail.b-cdn.net/anything-100.html --view

Taniec kota v1 - Link

To jest prosta przykładowa witryna pokazująca typowo wyglądającą stronę promocyjną naszej aplikacji mobilnej „Cat Dance”. Zawiera super fajny animowany gif, aby zademonstrować tańczące koty, które otrzymasz po zainstalowaniu naszej gorącej aplikacji na telefon. Sprawdźmy teraz wynik Lighthouse 6.0 dla tej witryny:

Wow, wynik 60 punktów jest bolesny dla tych, którzy osiągają wysokie wyniki, takich jak my. Jak ta prosta strona może być tak powolna według Google? Skoncentrujmy się na „Największej zawartości treści”, ponieważ jest to jedna z nowych metryk wprowadzonych w tej wersji.

Jest to bardzo pomocne, ponieważ zaleca użycie wideo do animowanych treści i pokazuje nam, że element największej zawartości treści jest animowanym gifem naszych tańczących kotów. Fajnie, przejdźmy do:

Taniec kota v2 - Link

W tej wersji zastępujemy animowany gif plikiem mp4 odtwarzanym przy użyciu natywnego elementu wideo HTML5. Powinno to być znacznie lepsze, ponieważ pliki mp4 zostały dosłownie stworzone dla treści animowanych i będą znacznie mniejsze niż porównywalne animowane gify.

Cóż, to z pewnością zmierza w dobrym kierunku. Poprawiliśmy się o 14 punktów, przełączając się na mp4 do animacji naszych niesamowitych tańczących kotów. Przejście od LCP 104,9 s do 9,9 s jest z pewnością znaczną poprawą. Ale nie jesteśmy zadowoleni z 74. To jak ocena „C” i jesteśmy grupą osób, które osiągnęły A+.

Wygląda na to, że nasz LCP jest teraz generowany przez wideo, co ma sens zamiast poprzedniego animowanego gifu. Ale może kiepsko sobie radzimy z kodowaniem, obrazem plakatu czy czymś takim, więc pobawmy się tym dalej.

Taniec kota v3 - Link

W tej wersji użyjemy YouTube do animowanego filmu o kotach. W ten sposób, jeśli jest to coś związanego z kodowaniem wideo, pomoże to wyeliminować. Ogólnie rzecz biorąc, być może nasze naiwne kodowanie wideo nas powstrzymuje, więc zobaczmy, jaki wynik uzyskamy w ten sposób.

Chwileczkę, ci goście są geniuszami, podnoszą mój wynik PageSpeed ​​do 99. Musieliśmy naprawdę nawalić naszego kodowania wideo, żeby uzyskać wynik 76, prawda?

Czy coś tu jest nie tak? W poprzednich wersjach tańczące koty były zawsze największym elementem na ekranie. A patrząc na zrzuty ekranu z tego testu, widać, że wideo nadal ma ten sam rozmiar w tej wersji. Dlaczego więc twierdzi, że tekst naszego <h1> jest największym elementem? Odpowiedź znajduje się w opisie Google metryki największej zawartości treści. Te dane obejmują największy element, w tym wideo, obrazy, pliki SVG, ALE NIE RAMKI

Czekaj, co? To nie może być prawda. Jeśli iframe jest największym elementem i ładuje się wolno jak melasa, to nie ma znaczenia... nie liczy się! Tak więc iframe są jak magiczne czarne dziury wydajności, w których możemy osadzić nasze wolne lub duże elementy i nie wpłyną one na nasz wynik wydajności. Nie ma mowy! Wypróbujmy to.

Taniec kota v4 - Link

Aby przetestować naszą teorię, wrócimy do naszej dokładnej strony w wersji 1 z dużym animowanym gifem i wszystkim. Wprowadzimy tylko jedną zmianę. Załadujmy animowany gif do elementu iframe i zobaczmy, co stanie się z naszym wynikiem PageSpeed.

O cholera... czy to naprawdę może być rozwiązanie? Po prostu bierzemy wszelkie problemy, które powodują spadek wyniku szybkości witryny, wrzucamy je do ramki iframe, a następnie BOOM, żadnych więcej problemów. Chodzi mi o to, że wiemy, że tak naprawdę nie zmienia to szybkości ładowania, ponieważ jest to ten sam plik o tym samym rozmiarze, po prostu załadowany w ramce iframe. Podobnie jak to, co się stało podczas korzystania z osadzania YouTube, tak naprawdę nie zmieniło to tak bardzo szybkości. Wygląda na to, że elementy iframe są po prostu magicznymi portalami, które mogą pobić wynik PageSpeed.

Ale przenoszenie wszystkich naszych powolnych elementów do ramek iframe jest trochę uciążliwe...

Cat Dance v5 - Framehole'd Link

Potrzebujemy prostszego sposobu na natychmiastowe zwiększenie szybkości dowolnej witryny. Konieczność selektywnego zastępowania elementów wersjami iframe jest po prostu bardzo skomplikowana i może nie być tego warta na dłuższą metę. Wiemy, jak pracować mądrzej, a nie ciężej.

Co jeśli umieścimy całą witrynę w ramce iframe? W ten sposób nasze rozwiązanie byłoby oddzielone od rzeczywistej bazy kodu witryny. Moglibyśmy nawet zrobić tego typu rzeczy na krawędzi lub w NGINX, całkowicie oddzielając to od wpływu na istniejący kod.

Nasz v5 to po prostu strona z v1, umieszczona w ramce w pustym opakowaniu. Ten sam duży animowany gif, bez optymalizacji. A teraz przeszliśmy z 60 do 100. To Święty Graal i nie trzeba nic robić z właściwą stroną internetową.

To jest głupie

Jeśli myślisz, że jest to największy olej wężowy, jaki kiedykolwiek widziałeś i żaden programista przy zdrowych zmysłach nie dbałby o tę zmianę wyniku, ponieważ prędkość bazowa nie zmieniła się ani trochę, to myślę, że masz rację na froncie oleju wężowego, ale tak bardzo myli się, czy ludzi to obchodzi.

Pamiętaj, że PageSpeed ​​to złoty standard wydajności sieci. Google używa nawet tego wyniku do zasilenia swojego algorytmu. Jeśli nigdy nie słyszałeś od klienta, że ​​chce zobaczyć, jak Twój produkt wpływa na jego wynik PageSpeed, oznacza to, że nie rozmawiałeś z wystarczającą liczbą klientów. Obchodzi ich, bo zależy im na Google , a wynik ma coś znaczyć. Zobacz, ile słów zajęło mi wyjaśnienie tego i wyobraź sobie, że mówię klientowi, że myli się, że Twój produkt spowalnia witrynę w porównaniu z uproszczonym, łatwym do zrozumienia wynikiem PageSpeed, twierdząc, jak bardzo się mylisz.

Bez względu na przyczynę, ostatecznie wykluczenie elementów iframe z obliczeń dotyczących czasu potrzebnego na pojawienie się najważniejszych treści w witrynie jest po prostu błędne!

Używanie czasu wyświetlania największego elementu jako wskaźnika szybkości na stronie internetowej ma sens na świecie. Nadal wpływa na postrzeganie prędkości, nawet jeśli jest załadowany w iframe. A posuwanie się naprzód z wynikiem, który wyklucza osadzone treści, jest szkodliwe dla celu, jakim jest przyspieszenie sieci. Osadzone treści nie otrzymują darmowej przepustki, zwłaszcza gdy są przyczyną powolnego ładowania.

Jeśli punktacja zostanie zrealizowana z tymi wskaźnikami sieciowymi, to czeka nas sieć, która jest zachęcana do powrotu na stronę patchworkową z ogromnymi reklamami i osadzonymi stronami trzecimi, całkowicie pomijając koszt szybkości tych elementów. Nie ma wątpliwości, że znajdą się ludzie, którzy zaimplementują dokładnie iframe dla całej witryny, jak wspomniano w tym artykule, ponieważ kierownictwo chciało jak najwyższego wyniku PageSpeed.

Zachowanie jest kształtowane przez to, jak utrzymujemy wynik