Wolne przez pomyłkę vs wolne z założenia

Wolne przez pomyłkę vs wolne z założenia.

Kiedy zatrudnisz mnie, żeby naprawić lub porozmawiać o Core Web Vitals, w pewnym momencie usłyszysz, jak mówię o wolne przez pomyłkę vs wolne z założenia.  Uważam, że jest to kluczowe rozróżnienie i w tym artykule wyjaśnię, jak pomoże Ci to poprawić Core Web Vitals.

Wolne przez pomyłkę

Uwielbiam anty-wzorce „wolne przez pomyłkę”. Zrobiłeś coś, co spowolniło stronę. Popełniłeś błąd. Nie wiedziałeś, że istnieje znacznie szybszy sposób. Bez obaw, mogę naprawić błędy. 

Dlatego kategoryzowanie tych „błędów” ma sens. Daje mi to listę łatwych do naprawienia, wysokowpływowych usprawnień, którą mogę wysłać do Twojego zespołu deweloperów (lub naprawić sam). Zwykle potrzeba bardzo niewiele dyskusji. Poprawa tych anty-wzorców po prostu ma sens ze wszystkich stron. Po ich naprawieniu Core Web Vitals się poprawią.

Oto kilka przykładów anty-wzorców, na które natrafiam codziennie. Kiedy wyjaśniam co i dlaczego, zwykle słyszę „ohh, nie wiedziałem, że to spowalnia stronę”.

1. Obrazy bez lazy loading

Najczęstszym anty-wzorcem są obrazy bez lazy loading. Obrazy, które nie są lazy loaded, zostaną dodane do kolejki pobierania na wczesnych etapach ładowania strony. To zużywa zasoby sieciowe i CPU. Nie ma sensu przydzielać cennych zasobów obrazom, które nie są nawet widoczne, prawda? 

2. Fonty zewnętrzne

3. Skrypty zewnętrzne

4. Obrazy tła

5. Duże arkusze stylów

Wolne z założenia

Wolne z założenia to część, o którą powinieneś się martwić. Podjąłeś strukturalne decyzje, które spowolniły stronę.  Zwykle obejmują one wybory UX designu lub kod JavaScript, który modyfikuje widoczną część strony do tego stopnia, że nie ma dobrych obejść.

Problem z „wolne z założenia” polega na tym, że nie da się tego natychmiast naprawić drobnymi zmianami. Wymaga to więcej planowania i przepisania niektórych kluczowych funkcji strony. 

Pierwszą rzeczą, którą muszę zrobić, jest zrozumienie intencji: Dlaczego to zrobiłeś? Jakie były rozważania i co dokładnie chciałeś osiągnąć? A następnie w ramach tych parametrów znaleźć lepszą alternatywę!

Oto kilka przykładów najczęstszych błędów „wolne z założenia”.

1. Slidery

Slidery zwykle działają tak: Kiedy strona się renderuje, JavaScript wstrzykuje slider na stronę. Bez tego JavaScript strona będzie wyglądać zupełnie inaczej.  To spowoduje dłuższy Largest Contentful Paint, prawdopodobnie Layout Shift i najprawdopodobniej problemy z First Input Delay.

Nie ma szybkiego rozwiązania. Odroczenie JavaScript poprawi metryki paint, ale opóźni slider i spowoduje layout shift. Uczynienie skryptu slidera krytycznym naprawi Layout Shift, ale spowolni metryki paint.

Rozwiązaniem jest progresywne ulepszanie strony. Najpierw upewnij się, że slider renderuje się bez JavaScript, a następnie ulepsz stronę i przekształć już obecny obraz slidera w pełny slider. 

Zabawne jest to, że 9 na 10 razy, kiedy to wyjaśniam, właściciel strony natychmiast sugeruje usunięcie slidera. Dlatego tak ważne jest pytanie o intencje i rozważania dotyczące tych sliderów. Zwykle „po prostu tam były”.

2. Zoom produktu

Zoom produktu działa tak: w przeciętnym sklepie internetowym najedź kursorem na obraz produktu i możesz powiększyć część produktu.  „Zoom produktu” zwykle ma ten sam problem co slidery.  Fragment kodu JavaScript pobierze Twoje obrazy, ukryje je i przepisze na stronę jako obrazy z możliwością powiększania. To spowoduje dłuższy Largest Contentful Paint, prawdopodobnie Layout Shift i najprawdopodobniej problemy z First Input Delay.

Różnica w porównaniu ze sliderem polega na tym, że żaden właściciel produktu nigdy nie powie: „och, po prostu usuń tę funkcjonalność”. Jest to ważne i zwiększa konwersję.

Rozwiązanie jest takie samo jak w przypadku slidera. Skrypt zoomu nie powinien ukrywać oryginalnych obrazów, ale rozszerzać funkcjonalność obrazów produktów. Niestety funkcjonalność zoomu zwykle nie jest łatwo naprawiana i wymaga  trochę pracy, żeby wszystko dobrze działało.

3. Inline jQuery / zależności inline JavaScript

Inline jQuery to problem, który zaczął się jako „wolne przez pomyłkę”, ale pogorszył się z czasem. Około 50% stron, które analizuję, cierpi na ten problem. Ponieważ skrypty inline zależą od wcześniejszego skryptu (zwykle jQuery), nie możesz już odroczyć jQuery. To opóźni wszystkie metryki paint.

Naprawa jest prosta: Po prostu przenieś te skrypty do zewnętrznego skryptu. Teraz możesz odroczyć zarówno jQuery, jak i niestandardowy skrypt. 

Dlaczego więc umieściłem to w kategorii „wolne z założenia”? Kiedy pytam o intencje i rozważania, zwykle słyszę „och, nie wiem”. I to jest prawdziwy problem. Brakuje wiedzy o tym, jak działa JavaScript.  Mogę być dość pewny, że ten błąd powtórzy się w przyszłości. Oznacza to, że rozwiązanie to nie to samo co naprawa. Będę musiał wyedukować zespół deweloperów o zależnościach JavaScript i ich kolejności.

4. Duże obrazy (hero)

Kolejnym problemem „wolne z założenia” są duże obrazy. Niektóre strony po prostu muszą „zachwycić odbiorców” mnóstwem obrazów w pełnym rozmiarze. Wyobraź sobie, że sprzedajesz plakaty. Prawdopodobnie chciałbyś serwować odwiedzającym wysokiej jakości, duże obrazy. Te obrazy, bez względu na to, jak bardzo je zoptymalizujesz, zawsze będą pobierać się dłużej niż mniejsze obrazy. 

W tym momencie (zakładając, że wszystkie obrazy są zoptymalizowane) jedyne, co mogę zrobić, to sprawdzić, czy jest jakieś pole manewru. Czy naprawdę potrzebujemy obrazów 4k, czy wystarczyłoby full-hd?

5. Interaktywne mapy

Kolejnym problemem, na który często natrafiam, są interaktywne mapy. Kiedy strona ma interaktywną mapę, cała intencja tej strony polega na tym, żeby odwiedzający wchodził w interakcję z mapą. Oczywiście załadowanie tej mapy zajmie trochę czasu. 

Nie da się tego obejść. Będziemy musieli zaakceptować pewne spowolnienie. Ale są rzeczy, które możemy zrobić. Możemy upewnić się, że mapy są ładowane z najwyższym priorytetem. Zwykle te strony nie są zoptymalizowane pod wczesne wykonywanie JavaScript. W tym przypadku to był zły wybór. Potrzebujemy, żeby skrypt pobrał się i wykonał jak najwcześniej!

6. Wolne API

Podsumowanie

Może być przydatne rozróżnienie między wolne przez pomyłkę a wolne z założenia, jeśli chodzi o Core Web Vitals. Wolne przez pomyłkę jest zwykle łatwe do naprawienia, podczas gdy wolne z założenia wymaga bardziej dokładnego, wielowymiarowego podejścia.