Blog Web Dev Insider

W optymalizacji frontendu kluczową sprawą to mierzenie wszelkiej maści metryk na stronie WWW - od TTFB, po LCP, Time to interactive, SpeedIndex itd. Po analizie czasów możemy przejść do planu ich optymalizacji i wdrażania go. Przyjęło się, że im szybszy dany czas, tym lepiej - czyli im szybciej pojawia się np. tytuł strony w przeglądarce - tym lepiej, im sprawniej pojawi się kluczowy element „above the bold” - tym lepiej, im szybciej strona jest interaktywna - tym lepiej.

Ostatnio na Instagramie natknąłem się na pytanie dotyczące nowej metryki (wchodzącej w skład Core Web Vitals) - Cumulative Layout Shifts (CLS) i wykorzystywania krytycznego CSSa. CLS to wskaźnik Zbiorczego Przesunięcia układu strony.

Doczekaliśmy się standaryzacji NATYWNEGO lazy loadingu iframe’ów przez WHATWG. Oznacza to lepsze wsparcie tego naprawdę ważnego usprawnienia w temacie optymalizacji frontendu wśród przeglądarek. Czy aby na pewno wiesz wszystko o iframe'ach w 2020 roku i jak je optymalnie ładować?

Jak uniknąć problemów z metryką Google’a o nazwie „Cumulative Layout Shifts” w kontekście dynamicznej paginacji (np. poprzez technikę Infinite Scroll albo Load More), która traktuje o tzw. zbiorczym przesunięciu układu?

Skrypty zewnętrzne to temat, który zawsze mnie drażnił... Ilekroć spędzałem mnóstwo czasu na optymalizacji frontendu strony lub aplikacji, którą tworzyłem, zawsze przychodził później taki moment, kiedy klient zażyczył sobie dodatkowe 3rd parties - Google Tag Manager, jakiś Intercom chat, Hubspot, formularze Marketo i wydajność znacząco spadała...

Jak wiesz, całkiem niedawno wyszła nowa wersja Lighthouse’a w wersji szóstej, w której wprowadzono nowe metryki do mierzenia POSTRZEGALNEJ wydajności stron WWW. Są to Largest Contentful Paint (LCP), Cumulative Layout Shifts (CLS) oraz Total Blocking Time (TBT), które są częścią Web Vitals - inicjatywy Google’a służącej do przedstawiania sygnałów jakości na temat strony pod względem User Experience.