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

W ciągu kilku miesięcy wiodącej brytyjskiej witrynie z wiadomościami udało się poprawić CLS w 75. ćwiartylu o 250%, z 0,25 do 0,1.

Chris Boakes

Stabilność wizualna

Przesunięcia układu mogą być bardzo uciążliwe. W Telegraph Media Group (TMG) stabilność wizualna jest szczególnie ważna, ponieważ czytelnicy korzystają z naszych aplikacji, aby czytać wiadomości. Jeśli układ zmienia się podczas czytania artykułu, czytelnik może zgubić miejsce. Może to być frustrujące i rozpraszające.

Z technicznego punktu widzenia zapewnienie, aby strony nie przesuwały się ani nie przerywały czytania, może być trudne, zwłaszcza gdy obszary aplikacji są wczytywane asynchronicznie i dodawane do strony dynamicznie.

W TMG mamy kilka zespołów, które pracują nad kodem po stronie klienta:

  • Główna inżynieria. Wdrażanie rozwiązań innych firm w obszarach takich jak rekomendacje treści i komentowanie.
  • Marketing. Przeprowadzanie testów A/B w celu oceny sposobu, w jaki czytelnicy korzystają z nowych funkcji lub zmian.
  • Reklama. zarządzanie żądaniami reklam i wstępnym określaniem stawek reklam;
  • Wymagania redakcyjne. umieszczanie kodu w artykułach, takich jak tweety lub filmy, a także widżetów niestandardowych (np. licznika zachorowań na koronawirusa).

Utrzymanie prawidłowego układu strony przez te zespoły może być trudne. Korzystając z danych Kumulowana zmiana układu, aby mierzyć, jak często występuje ona w przypadku naszych czytelników, zespoły uzyskały więcej informacji o rzeczywistych wrażeniach użytkowników i o jasnym celu, do którego należy dążyć. W efekcie skumulowane przesunięcie układu na 75-tym percentylu spadło z 0,25 do 0,1, a liczba elementów z dozwolonym przesunięciem wzrosła z 57% do 72%.

250%

Poprawa CLS na poziomie 75. percentyla

15%

więcej użytkowników z dobrym wynikiem CLS,

Od czego zaczęliśmy

Dzięki dashboardom Crux mogliśmy ustalić, że nasze strony zmieniały swoją pozycję częściej niż byśmy chcieli.

Panel CrUX pokazujący wyniki w zakresie 55–60% (dobry), 15% (wymaga poprawy) i 25% (zły).
Nasze wyniki skumulowanego przesunięcia układu w okresie od czerwca 2020 r. do lutego 2021 r.

Chcieliśmy, aby co najmniej 75% naszych czytelników miało „dobre” wrażenia, dlatego zaczęliśmy identyfikować przyczyny niestabilności układu.

Jak mierzono zmiany układu

Aby ustalić, co powoduje przesuwanie układu, użyliśmy narzędzi programistycznych Chrome i WebPageTest. W DevTools użyliśmy sekcji Doświadczenia na karcie Wydajność, aby wyróżnić poszczególne przypadki zmiany układu i ich wpływ na ogólną ocenę.

Strona główna Telegraph z niebieskim nakładem pokazującym reklamę w nagłówku.
Zidentyfikowanie przesunięcia układu spowodowanego wczytywaniem reklamy po stronie klienta powyżej nagłówka za pomocą sekcji Doświadczenie w Narzędziach deweloperskich w Chrome.

WebPageTest podświetla w widoku osi czasu miejsce, w którym występuje zmiana układu, gdy wybrana jest opcja „Highlight Layout Shifts”.

Widok slajdu z testem WebPageTest witryny Telegraph z czerwoną nakładką wskazującą zmianę układu.
WebPageTest wskazuje, gdzie układ uległ zmianie.

Po sprawdzeniu każdej zmiany w przypadku najczęściej odwiedzanych szablonów opracowaliśmy listę pomysłów na ulepszenia.

Ograniczanie przesunięć układu

Skupiliśmy się na 4 obszarach, w których mogliśmy ograniczyć zmiany układu: - reklamy - obrazy - nagłówki - wstawianie

Reklamy

Reklamy są wczytywane po początkowym renderowaniu za pomocą JavaScriptu. Niektóre z kontenerów, w których były one załadowane, nie miały zarezerwowanej wysokości.

Animacja strony internetowej Telegraph. Gdy nad listą artykułów wyświetli się reklama, lista jest przesuwana w dół.
Po załadowaniu reklamy blok „Więcej artykułów” pod reklamą przesuwa się w dół.

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

Animacja strony internetowej Telegraph. Nad listą artykułów znajduje się prostokątny obiekt zastępczy reklamy. Reklama wczytuje się zamiast zastępczego obrazu bez zmiany układu.
Zarezerwowanie miejsca na reklamę powoduje, że blok „Więcej artykułów” poniżej pozostaje statyczny przed i po załadowaniu reklamy.

W niektórych przypadkach nieprawidłowo oszacowaliśmy średnią wysokość reklamy. W przypadku czytników tabletów sekcji nie można było zwinąć.

Animacja przedstawiająca stronę internetową Telegraph w wersji na tablet. Boks zastępczy jest większy niż reklama, więc po jej wczytaniu treści przesuwają się w górę.
Blok reklamowy, który po załadowaniu zwija się dla czytelników na urządzeniach wielkości tabletu.

Ponownie sprawdziliśmy slot i zmieniliśmy jego wysokość, aby użyć najbardziej typowego rozmiaru.

Animacja przedstawiająca stronę internetową Telegraph w wersji na tablet. Jeśli placeholder pasuje do rozmiaru reklamy, podczas jej wczytywania nie dochodzi do zmiany układu.
Sprawdzanie, czy miejsce zarezerwowane na boks reklamowy odpowiada najczęściej wyświetlanej wysokości reklamy.

Obrazy

Wiele obrazów w witrynie jest wczytywanych z opóźnieniem i mają zarezerwowane miejsce.

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

Jednak obrazy wstawiane u góry artykułów nie miały zarezerwowanego miejsca w kontenerze ani atrybutów szerokości i wysokości powiązanych z tagami. Powodowało to przesuwanie się układu podczas wczytywania.

Animacja wczytywania strony artykułu. Gdy główny obraz wczytuje się u góry strony, tekst przesuwa się w dół.
Zmiana układu spowodowana przez główne zdjęcie artykułu.

Wystarczyło dodanie atrybutów szerokości i wysokości do obrazów, aby układ się nie przesunął.

Animacja wczytywania strony artykułu z miejscem zarezerwowanym na obraz główny. Gdy główny obraz wczytuje się u góry strony, nie zmienia się układ.
Główny obraz artykułu wczytuje się bez zmiany układu.

Nagłówek znajdował się poniżej treści w oznaczeniu i został przesunięty na górę za pomocą CSS. Pierwotna koncepcja zakładała, że priorytetem jest wczytywanie treści przed nawigacją, ale powodowało to chwilowe przesuwanie strony.

ALT_TEXT_HERE
Nagłówek strony wczytuje się nieelegancko.

Przeniesienie nagłówka na początek znacznika umożliwiło renderowanie 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 często używane elementy mają określone proporcje. Na przykład filmy w YouTube. Podczas wczytywania odtwarzacza pobieramy miniaturę z YouTube i używamy jej jako obiektu zastępczego podczas wczytywania filmu.

Podczas wczytywania odtwarzacza wczytuje się miniatura o niskiej rozdzielczości.
Boks odtwarzacza wczytujący miniaturę w niskiej rozdzielczości podczas wczytywania odtwarzacza.

Pomiar wpływu

Udało nam się łatwo zmierzyć wpływ na poziomie funkcji za pomocą narzędzi wymienionych na początku artykułu. Chcieliśmy jednak mierzyć CLS zarówno na poziomie szablonu, jak i na poziomie witryny. W celu weryfikacji zmian zarówno w środowisku przedprodukcyjnym, jak i produkcyjnym, użyliśmy testu syntetycznego SpeedCurve.

Wykres SpeedCurve przedstawiający gwałtowny spadek wartości CLS.
Śledzenie postępów w przypadku CLS za pomocą sztucznej metody SpeedCurve.

Gdy kod trafi do wersji produkcyjnej, będziemy mogli zweryfikować wyniki w danych RUM (dostarczanych przez mPulse).

Wykres mPulse pokazujący spadek wyniku CLS.
Sprawdzanie ulepszeń CLS w całej witrynie za pomocą danych RUM z mPulse przed wprowadzeniem zmian i po ich wprowadzeniu.

Dzięki sprawdzaniu danych RUM możemy mieć pewność, że wprowadzane przez nas zmiany mają pozytywny wpływ na naszych czytelników.

Ostateczne liczby, które wzięliśmy pod uwagę, dotyczą danych RUM zbieranych przez Google. Jest to szczególnie ważne teraz, ponieważ wkrótce wpłyną na pozycję witryny w rankingu. Na początek użyliśmy raportu na temat użytkowania Chrome, zarówno w przypadku danych miesięcznych na poziomie pochodzenia dostępnych w panelu CrUX, jak i w przypadku zapytań do BigQuery, aby pobrać historyczne dane p75. W ten sposób łatwo zauważyliśmy, że w przypadku całego ruchu zmierzonego przez CrUX wartość CLS w 75. percentylu wzrosła o 250% z 0,25 na 0,1, a liczba elementów z pozytywnym wynikiem wzrosła z 57% na 72%.

W panelu CrUX widać, że wskaźnik CLS p75 dla telegraph.co.uk wynosi 0,1.
Wyniki z panelu Crux.
BigQuery pokazuje, że wartości p75 poprawiają się z miesiąca na miesiąc – z 0,25 na 0,1.
Wynik zapytania do BigQuery z wartościami p75 z 2021 r. do tej pory.

Dodatkowo mogliśmy skorzystać z interfejsu API raportu na temat użytkowania Chrome i utworzyć wewnętrzne panele podzielone na szablony.

Panel wewnętrzny pokazujący średnią ocenę „dobra” wynoszącą 76,2, ocenę „wymaga poprawy” wynoszącą 9,3 i ocenę „zła” wynoszącą 14,6.
Panele wewnętrzne korzystające z interfejsu API raportu na temat użytkowania Chrome, które wskazują nasz średni wynik i strony o najgorszych wynikach korzystające z tego szablonu.

Unikanie regresji CLS

Unikanie regresji jest ważnym aspektem poprawy wydajności. Skonfigurowaliśmy podstawowe budżety skuteczności dla kluczowych danych, uwzględniając w nich CLS.

Panel budżetu skuteczności, który zawiera testy syntetyczne zmierzające CLS w niektórych naszych szablonach o dużej liczbie wizyt. Budżet jest obecnie ustawiony na 0,025.

Jeśli test przekroczy budżet, wyśle wiadomość do kanału Slack, abyśmy mogli zbadać przyczynę. Skonfigurowaliśmy też raporty tygodniowe, aby nawet wtedy, gdy szablony pozostają w budżecie, wiedzieć, jakie zmiany miały negatywny wpływ.

Planujemy też zwiększyć budżety, aby używać danych RUM i danych syntetycznych, a także korzystania z mPulse do ustawiania alertów statycznych i potencjalnie wykrywania anomalii, które informowałyby nas o nietypowych zmianach.

Ważne jest dla nas, aby nowe funkcje były tworzone z uwzględnieniem CLS. Wiele z wymienionych przeze mnie zmian to zmiany, które musieliśmy wprowadzić po opublikowaniu treści dla naszych czytelników. Od teraz stabilność układu będzie brana pod uwagę przy projektowaniu każdej nowej funkcji, aby od samego początku uniknąć nieoczekiwanych zmian układu.

Podsumowanie

Dotychczasowe ulepszenia były łatwe do wdrożenia i wywarły znaczący wpływ. Wdrożenie wielu zmian opisanych w tym artykule nie zajęło dużo czasu i zostały one zastosowane we wszystkich najczęściej używanych szablonach, co oznacza, że miały one pozytywny wpływ na wielu czytelników.

Nadal musimy poprawić niektóre obszary witryny. Sprawdzamy, czy możemy przenieść część logiki po stronie klienta na serwer, co jeszcze bardziej zmniejszy CLS. Będziemy śledzić i monitorować nasze dane, aby stale je ulepszać i zapewniać czytelnikom jak najlepsze wrażenia.