Udoskonalanie skumulowanego przesunięcia układu w Telegraph Media Group

W ciągu kilku miesięcy wiodąca brytyjska witryna z wiadomościami poprawiła CLS 75. percentyl o 250% (z 0,25 do 0,1).

Chris Boakes

Wyzwanie dotyczące stabilności wizualnej

Przesunięcia układu mogą być bardzo uciążliwe. W Telegraph Media Group (TMG) stabilność wizualna jest szczególnie ważna, ponieważ czytelnicy przeważnie korzystają z naszych aplikacji. Jeśli układ strony zmieni się podczas czytania artykułu, czytelnik prawdopodobnie straci swoje miejsce. Takie doświadczenia mogą być frustrujące i rozpraszające.

Z perspektywy inżynierii zadbanie o to, aby strony nie przesuwały się i nie zakłócały czytnika, może być trudne, zwłaszcza gdy obszary aplikacji są wczytywane asynchronicznie i dynamiczne dodawane do strony.

W TMG kilka zespołów udostępnia kod po stronie klienta:

  • Inżynieria podstawowa. Wdrażanie rozwiązań innych firm w obszarach takich jak polecanie treści i komentowanie.
  • Marketing. Przeprowadzanie testów A/B w celu oceny sposobu interakcji czytelników z nowymi funkcjami lub zmianami.
  • Reklamy. Zarządzanie żądaniami reklam i wstępnym ustalaniem stawek.
  • Wymagania redakcyjne. Osadzanie kodu w artykułach, takich jak tweety czy filmy, oraz niestandardowe widżety (np. narzędzie do śledzenia przypadków koronawirusa).

Dopilnowanie, aby żaden z tych zespołów nie powodował szarpania układu strony, może być trudne. Korzystając z danych Skumulowane przesunięcie układu, aby zmierzyć, jak często występują one na kontach naszych czytelników, zespoły miały lepszy wgląd w wygodę użytkowników i określiły jasny cel. W rezultacie nasza 75-percentylowa wartość CLS wzrosła z 0,25 do 0,1, a wskaźnik z 57% do 72% zwiększył się z 57% do 72%.

250%

75. percentyl poprawy CLS

15%

Więcej użytkowników z dobrym wynikiem CLS

Pierwsze kroki

Dzięki panelom CrUX udało nam się ustalić, że nasze strony zmieniają się bardziej, niż oczekiwaliśmy.

Panel CrUX z widocznymi około 55–60% słabszymi wynikami, 15% wymagającymi poprawy, a 25% słabymi.
Nasze wyniki dotyczące skumulowanego przesunięcia układu między czerwcem a lutym 2021 r.

Chcieliśmy, aby co najmniej 75% czytelników było pozytywnych, więc zaczęliśmy określać przyczyny niestabilności układu.

Jak mierzyliśmy przesunięcia układu

Użyliśmy kombinacji narzędzi Chrome DevTools i WebPageTest, aby pomóc nam zidentyfikować przyczynę zmiany układu. W Narzędziach deweloperskich użyliśmy sekcji „Jakość” na karcie Skuteczność, aby wyróżnić poszczególne przypadki zmiany układu i ich udział w ogólnym wyniku.

Pierwsza strona Telegraph z reklamą w nagłówku podniesionym niebieską nakładką.
W sekcji „Doświadczenie” w Narzędziach deweloperskich w Chrome możesz zidentyfikować zmianę układu spowodowaną wczytywaniem reklamy po stronie klienta nad nagłówkiem.

Narzędzie WebPageTest wskazuje, gdzie w widoku osi czasu następuje przesunięcie układu, gdy wybrana jest opcja „Podświetl przesunięcia układu”.

Widok paska zdjęć z serwisu WebPageTest w witrynie Telegraph z przesunięciem układu wyróżnionym czerwoną nakładką.
WebPageTest wyróżniający miejsce przesunięcia układu.

Po przejrzeniu każdej zmiany w naszych najczęściej odwiedzanych szablonach opracowaliśmy listę pomysłów na usprawnienia,

Ograniczenie przesunięć układu

Skupiliśmy się na 4 obszarach, w których możemy ograniczyć przesunięcia układu: – reklam, – obrazów, – nagłówków, – umieszczonych elementów

Reklamy

Reklamy wczytują się po pierwszym wyrenderowaniu przez JavaScript. Niektóre wczytane kontenery nie miały żadnej zarezerwowanej wysokości.

Animacja strony Telegraph. Lista artykułów jest przesuwana w dół, gdy wyświetla się nad nią reklama.
Blok „Więcej artykułów” pod reklamą jest przesunięty w dół po wczytaniu reklamy.

Chociaż nie znamy dokładnej wysokości, możemy zarezerwować przestrzeń, używając najpopularniejszego rozmiaru reklamy wczytanego w boksie.

Animacja strony Telegraph. Zastępczy prostokąt dotyczący reklamy znajduje się nad listą artykułów. Reklama wczytuje się w miejscu obiektu zastępczego, nie powodując przesunięcia układu.
Jeśli zarezerwujesz miejsce na reklamę, blok „Więcej artykułów” poniżej pozostaje nieruchomy przed wczytaniem reklamy i po jej wczytaniu.

W niektórych przypadkach popełniliśmy błąd dotyczący średniej wysokości reklamy. W przypadku czytników tabletów gniazdo zwijało się.

Animacja przedstawiająca widok witryny Telegraph na tablecie. Boks zastępczy jest większy niż reklama, więc po jej wczytaniu treść przesuwa się w górę.
Boks reklamowy zwija się po wczytaniu dla czytników na tablety.

Sprawdziliśmy ponownie boks i dostosowaliśmy jego wysokość, tak aby korzystał z najpopularniejszego rozmiaru.

Animacja przedstawiająca widok witryny Telegraph na tablecie. Jeśli zmienna odpowiada rozmiarowi reklamy, nie ma żadnego przesunięcia układu po wczytaniu reklamy.
Zadbanie o to, aby miejsce zarezerwowane na boks reklamowy odpowiadało wysokości reklamy, która ma się najczęściej wyświetlać.

zdjęcia;

Wiele obrazów w witrynie jest leniwie ładowanych i ma zarezerwowaną dla nich przestrzeń.

Animacja pokazująca wczytywanie kart podglądu artykułu.
Leniwe ładowanie obrazów bez zakłócania układu.

Jednak obrazy w tekście u góry artykułów nie miały zarezerwowanego miejsca w kontenerze ani powiązane z tagami atrybuty szerokości i wysokości. Spowodowało to przesunięcie układu podczas wczytywania.

Animacja przedstawiająca wczytywanie strony z artykułem. Podczas wczytywania obrazu głównego u góry strony tekst przesuwa się w dół.
Przesunięcie układu spowodowane przez główne zdjęcie artykułu.

Wystarczyło dodać do obrazów atrybuty szerokości i wysokości, aby zapewnić, że układ się nie zmieni.

Animacja przedstawiająca wczytywanie strony artykułu z obiektem zastępczym zarezerwowanym dla obrazu głównego. Gdy obraz główny wczytuje się u góry strony, nie dochodzi do przesunięcia układu.
Wczytuje się główny obraz artykułu bez wywoływania przesunięcia układu.

Nagłówek znajdował się pod treścią w znacznikach i był u góry za pomocą CSS. Początkowo chcieliśmy potraktować priorytetowo wczytywanie treści przed rozpoczęciem nawigacji, ale spowodowało to chwilowe przesunięcie strony.

ALT_TEXT_HERE
Nagłówek strony, która wczytuje się nieregularnie.

Przeniesienie nagłówka na górę znacznika umożliwiło wyrenderowanie strony bez tego przesunięcia.

ALT_TEXT_HERE
Układ nie jest już zakłócany przez nagłówek wczytywania strony.

Umieszczanie na stronie

Niektóre elementy często umieszczone na stronie mają zdefiniowany współczynnik proporcji. np. filmy w YouTube. Podczas ładowania odtwarzacza pobieramy z YouTube miniaturę i używamy jej jako obiektu zastępczego na czas wczytywania filmu.

Gniazdo odtwarzacza, w którym podczas ładowania filmu jest wczytywana miniatura o niskiej rozdzielczości.
Gniazdo odtwarzacza, w którym podczas ładowania filmu jest wczytywana miniatura o niskiej rozdzielczości.

Pomiar wpływu

Mogliśmy dość łatwo zmierzyć wpływ na poziom funkcji, korzystając z narzędzi wspomnianych na początku artykułu. Chcieliśmy jednak mierzyć CLS zarówno na poziomie szablonu, jak i na poziomie witryny. Syntetycznie zastosowaliśmy technologię SpeedCurve do weryfikacji zmian zarówno na etapie przedprodukcyjnym, jak i produkcyjnym.

Wykres SpeedCurve przedstawiający gwałtowny spadek wyniku CLS.
Syntetyczne śledzenie postępu CLS za pomocą SpeedCurve.

Możemy wtedy zweryfikować wyniki w naszych danych RUM (dostarczanych przez mPulse), gdy kod osiągnie produkcję.

Wykres mPulse pokazujący spadek wyniku CLS.
Weryfikacja poprawy CLS w całej witrynie z wykorzystaniem danych mPulse RUM przed wprowadzeniem zmian i po ich wprowadzeniu.

Sprawdzanie danych RUM daje nam pewność, że wprowadzane zmiany mają pozytywny wpływ na naszych czytelników.

Ostatnie analizy dotyczą danych RUM zbieranych przez Google. Jest to szczególnie ważne, ponieważ wkrótce będą wpływać na ranking strony. Na początek użyliśmy raportu na temat użytkowania Chrome, który zawiera miesięczne dane na poziomie źródła dostępne w panelu CrUX oraz wysyłanie zapytań do BigQuery w celu pobrania historycznych danych P75. Dzięki temu z łatwością zauważyliśmy, że w przypadku całego ruchu mierzonego przez CrUX nasza wartość CLS w przypadku 75 centyla wzrosła o 250% z 0,25 do 0,1, a wskaźnik przekazywania wzrósł z 57% do 72%.

Panel CrUX pokazujący wartość p75 CLS w przypadku domeny telegraph.co.uk to 0,1.
Wyniki z panelu Crux.
BigQuery pokazuje wartości p75 z miesiąca na miesiąc (od 0,25 do 0,1).
Uruchomienie BigQuery z wartościami P75 od 2021 r. do chwili obecnej.

Możemy też skorzystać z interfejsu Chrome UX Report API i utworzyć kilka paneli wewnętrznych podzielonych na szablony.

Wewnętrzny panel pokazujący średni dobry wynik 76,2, wymagający poprawy do 9,3 i słaby wynik 14,6.
Wewnętrzne panele korzystające z interfejsu Chrome UX Report API, które wyróżniają nasz średni wynik i najgorsze strony, które używają tego szablonu.

Unikanie regresji CLS

Ważnym aspektem poprawiania skuteczności jest unikanie spadków wydajności. Utworzyliśmy podstawowe budżety skuteczności dla naszych kluczowych danych i uwzględniliśmy w nich CLS.

Panel budżetu wydajności, który pokazuje syntetyczne mechanizmy kontrolne mierzące CLS w niektórych szablonach o dużym ruchu. Obecnie budżet wynosi 0,025.

Jeśli test przekroczy budżet, wyśle wiadomość na kanał Slacka, aby umożliwić nam zbadanie przyczyny. Konfigurujemy też raporty tygodniowe, dzięki którym nawet jeśli szablony pozostaną w budżecie, będziemy wiedzieć o wszelkich zmianach, które miały negatywny wpływ.

Planujemy też rozszerzyć budżety, aby wykorzystywały dane RUM oraz dane syntetyczne. mPulse będzie używać mPulse zarówno do ustawiania alertów statycznych, jak i potencjalnie wykrywania anomalii, co uświadomi nas o nietypowych zmianach.

Dlatego ważne jest, aby podchodzić do nowych funkcji z myślą o CLS. Wiele zmian, o których wspomniałem, dotyczy tych, które musieliśmy poprawić po udostępnieniu czytelnikom. Stabilność układu będzie uwzględniana podczas projektowania rozwiązań wszystkich nowych funkcji, dzięki czemu unikniesz nieoczekiwanych przesunięć układu już od samego początku.

Podsumowanie

Wprowadzone do tej pory ulepszenia były dość łatwe do wdrożenia i miały znaczny wpływ. Wprowadzenie wielu zmian opisanych w tym artykule nie zajęło dużo czasu. Zastosowano je we wszystkich najczęściej używanych szablonach. Dzięki temu miały one bardzo pozytywny wpływ na naszych czytelników.

Są jeszcze obszary witryny, które wymagają ulepszenia. Szukamy sposobów, w jakie moglibyśmy zrobić więcej funkcji logiki po stronie klienta po stronie serwera, co pozwoli nam jeszcze bardziej ulepszyć CLS. Będziemy śledzić i monitorować nasze dane, by stale je ulepszać i zapewniać użytkownikom jak najlepsze wrażenia.