Centrum Społeczności
Advertisement
Centrum Społeczności

Evolving with the web.png

Zgodnie z obietnicą, rozpoczynamy serię wpisów, w których będziemy dzielić się z wami naszą analizą tego jak specyficzne dla wiki elementy wpływają na wyniki w Web Core Vitals, jako część naszego projektu rozwijając się z siecią. Znajdziecie tutaj ogólne podsumowanie końcowych wniosków. Aby zagłębić się w szczegóły, polecane jest przejście do tej strony pomocy w języku angielskim. Jej polska wersja pojawi się wkrótce.

Pomiary

Zacznijmy od przypomnienia – Core Web Vitals to nowy projekt Google, który mierzy 3 różne aspekty tego jak wczytują się strony internetowe gdy już chcesz do nich przejść. Celem projektu jest zapewnienie, że strony oferujące dobre wyniki w kwestii ładowania i pozwalania na szybkie wchodzenie w interakcje z zawartością zostaną wynagrodzone lepszymi pozycjami w wynikach wyszukiwania. To kolejny element w układance składającej się ze standardowego algorytmu indeksującego Google, który wyszukuje treści w wysokiej jakości pasującej do wyszukiwanych haseł.

Trzema wspomnianymi pomiarami są:

  • Ładowanie – Largest Contentful Paint (LCP): Jak szybko widoczna dla czytelnika jest największa porcja treści.
  • Interaktywność – Firtst Input Delay (FID): Jak szybko linki do innych interaktywnych elementów mogą zostać wykorzystane.
  • Stabilność – Cumulative Layout Shift (CLS): Jak bardzo elementy widoczne na ekranie przemieszczają się po załadowaniu, ale zanim można wchodzić z nimi w interakcje.

W skrócie ludzie z Google chcą, aby strony ładowały się szybko, nie miotały się za bardzo podczas ładowania i pozwalały na szybkie wchodzenie w interakcję. Brzmi świetnie, prawda?

Co możemy zrobić

Ciężko pracujemy, aby sprawić, że strony wczytują się szybciej i mniej się przesuwają, aby wyniki w LCP, FID i CLS miały się lepiej na całej platformie. Nasze wysiłki podniosą punkt wyjścia dla wszystkich wiki, ale pomiary mają miejsce dla każdej indeksowanej strony z osobna, więc sama treść będzie miała także wpływ na wynik.

Co wy możecie zrobić

Niżej przedstawiono kilka krótkich wskazów wynikających z naszej analizy wpływu formatowania na wspomniane pomiary. Pełne zestawienie znajduje się na stronie pomocy (eng.).

Krótkie strony i zalążki

Zastanówcie się nad politykami waszych wiki odnośnie zalążków artykułów. Zalążki pozostawione w niekompletnym stanie na więcej niż kilka dni obniżają ocenę Google w kwestii wiarygodności wiki. W kontekście Core Web Vitals treść krótkiej strony jest mniejsza od ramki i nagłówka dookoła niej, co skutkuje gorszym wynikiem CLS, bo Google myśli, że treść została zbyt mocno przesunięta.

Strony z zakładkami

Warto także przemyśleć podejście do stron z zakładkami. Jeśli wasza struktura zakładek jest oparta na szablonach pomyślanych pod kątem komputerów stacjonarnych lub wykorzystuje znacząco JavaScript, może to odbić się negatywnie na ocenie robota indeksującego w pierwszej kolejności wersję mobilną i pogorszyć wyniki w Core Web Vitals.

Skracanie artykułów

Zacznijmy od postawienia sprawy jasno: nie ma nic złego w długich stronach na wiki. Niektóre z najdłuższych stron na platformie należą do najbardziej uznanych zasobów w internecie, to samo tyczy się także polskich wiki i polskiej gałęzi internetu. Długie strony przedstawiają Google kompletny obraz całości.

Jeśli próbujesz skrócić długą stronę, zalecamy zrezygnowanie z wykorzystania tabberów, bo pogorszy to wyniki FID i CLS. Jeśli tabbery są jednak niezbędne, istnieją pewne dobre sposoby na zmaksymalizowanie ich użyteczności, które zostały rozwinięte w stronie pomocy.

Co dalej?

To była pierwsza część naszej analizy tego jak formatowanie wiki wpływa na wyniki w Web Core Vitals. W części drugiej zagłębimy się w kwestie takie szablony i skomplikowany wygląd – włączając w to Lua, przenośne infoboksy i skomplikowane tabele.

Jeśli macie pytania, nie wahajcie się zadawać ich w komentarzach poniżej. Warto także zajrzeć na kanał #best-practices na Discordzie, gdzie autor angielskiej wersji tego bloga oraz strony pomocy – Isaac – z chęcią udzieli wam wskazówek.