Wnioski dotyczące stosowania ujednoliconego atrybutu wczytywania
Celem tego wpisu jest przekonanie deweloperów i współtwórców platformy CMS (czyli osób, które opracowują ją od podstaw) do wdrożenia obsługi funkcji leniwego ładowania obrazów na poziomie przeglądarki. Podam też rekomendacje dotyczące zapewniania użytkownikom wysokiej jakości wrażeń i umożliwienia innym deweloperom dostosowywania strony podczas wdrażania leniwego ładowania. Te wskazówki powstały na podstawie naszego doświadczenia w dodawaniu obsługi do WordPressa oraz pomagania w wdrażaniu tej funkcji w Joomla, Drupal i TYPO3.
Niezależnie od tego, czy jesteś deweloperem platformy CMS, czy użytkownikiem systemu CMS (czyli osobą, która tworzy witryny za pomocą systemu CMS), możesz przeczytać ten artykuł, aby dowiedzieć się więcej o zaletach leniwego wczytywania na poziomie przeglądarki w systemie CMS. W sekcji Dalsze kroki znajdziesz sugestie dotyczące tego, jak zachęcić platformę CMS do implementacji leniwego ładowania.
Tło
W ciągu ostatniego roku opóźnione wczytywanie obrazów i ramek iframe za pomocą atrybutu loading stało się częścią standardu HTML WHATWG i jest coraz częściej stosowane przez różne przeglądarki.
Te kamienie milowe to jednak dopiero początek szybszego i oszczędzającego zasoby internetu.
Teraz jest on dostępny w rozproszonych systemach internetowych, aby można było korzystać z atrybutu loading.
Systemy zarządzania treścią obsługują około 60% witryn, więc odgrywają ważną rolę w wdrażaniu nowoczesnych funkcji przeglądarek w internecie. Kilka popularnych systemów CMS typu open source, takich jak WordPress, Joomla i TYPO3, obsługuje już atrybut loading w przypadku obrazów. Przyjrzyjmy się ich podejściom i wnioskom, które mogą być przydatne przy wdrażaniu tej funkcji w innych systemach CMS. Leniwe ładowanie multimediów to kluczowa funkcja zwiększająca wydajność witryny, z której witryny powinny korzystać na dużą skalę. Dlatego zalecamy stosowanie tej funkcji na poziomie rdzenia systemu CMS.
Dlaczego warto już teraz wdrożyć leniwe ładowanie
Standaryzacja
Wdrożenie niestandardowych funkcji przeglądarki w systemach CMS ułatwia przeprowadzanie testów na dużą skalę i może ujawnić potencjalne obszary do poprawy. Jednak ogólny konsensus wśród systemów CMS jest taki, że dopóki funkcja przeglądarki nie jest standardowa, należy ją wdrażać w formie rozszerzenia lub wtyczki dla danej platformy. Dopiero po ustandaryzowaniu funkcja może zostać zaadoptowana w głównej części platformy.
Obsługa przeglądarek
Obsługa tej funkcji w przeglądarkach również budzi podobne wątpliwości: większość użytkowników CMS powinna mieć możliwość korzystania z tej funkcji. Jeśli funkcja nie jest obsługiwana w znacznym odsetku przeglądarek, musi ona być tak zaprojektowana, aby nie miała negatywnego wpływu na te przeglądarki.
Próg odległości od widocznego obszaru
Typowym problemem związanym z implementacją ładowania opóźnionego jest to, że zwiększa ono prawdopodobieństwo, że obraz nie zostanie załadowany, gdy stanie się widoczny w widocznym obszarze ekranu użytkownika, ponieważ cykl ładowania rozpoczyna się w późniejszym etapie. W przeciwieństwie do poprzednich rozwiązań opartych na JavaScriptie przeglądarki stosują tę metodę w sposób ostrożny, a ponadto mogą ją dostosować na podstawie rzeczywistych danych o wrażeniach użytkowników, minimalizując wpływ na działanie strony. Dzięki temu platformy CMS mogą bezpiecznie stosować leniwy wczytywanie na poziomie przeglądarki.
Wskazówki dotyczące wrażeń użytkowników
Wymagaj atrybutów wymiarów w elementach
Aby uniknąć zmian układu, od dawna zalecamy, aby osadzone treści, takie jak obrazy lub iframe, zawsze zawierały atrybuty wymiarów width i height, dzięki czemu przeglądarka może wywnioskować format obrazu tych elementów przed ich załadowaniem. Ta rekomendacja jest istotna niezależnie od tego, czy element jest ładowany opóźnione. Jednak ze względu na 0,1% większe prawdopodobieństwo, że obraz nie zostanie w pełni załadowany, gdy znajdzie się w widoku, stosowanie opóźnionego wczytywania staje się nieco bardziej uzasadnione.
Systemy CMS powinny w miarę możliwości podawać atrybuty wymiarów dla wszystkich obrazów i ramek iframe. Jeśli nie jest to możliwe w przypadku każdego takiego elementu, zalecamy pominięcie wczytywania leniwego obrazów, które nie mają obu tych atrybutów.
Unikaj leniwego wczytywania elementów powyżej obszaru widocznego
Obecnie zalecamy, aby w systemach CMS dodawać atrybuty loading="lazy" tylko do obrazów i ramek iframe znajdujących się poniżej pola widocznego na ekranie, aby uniknąć opóźnienia w przypadku metryki Largest Contentful Paint, która w niektórych przypadkach może być znacząca (jak wykazano w lipcu 2021 r.). Należy jednak pamiętać, że ocena położenia elementu względem widoku przed rozpoczęciem procesu renderowania jest złożona. Dotyczy to zwłaszcza sytuacji, gdy system CMS używa automatycznego podejścia do dodawania atrybutów loading, ale nawet w przypadku ręcznej interwencji należy wziąć pod uwagę kilka czynników, takich jak różne rozmiary i proporcje widoku. Mimo to zdecydowanie zalecamy pominięcie obrazów nagłówka i innych obrazów lub ramek iframe, które prawdopodobnie będą widoczne powyżej pola widzenia, z lazy load.
Unikaj korzystania z JavaScriptu jako alternatywy
Chociaż za pomocą JavaScriptu można zastosować opóźnione wczytywanie w przypadku przeglądarek, które nie obsługują (jeszcze) atrybutu loading, to takie mechanizmy zawsze polegają na wstępnym usunięciu atrybutu src z obrazu lub elementu iframe, co powoduje opóźnienie w przypadku przeglądarek, które obsługują ten atrybut. Ponadto wdrożenie takiego rozwiązania opartego na JavaScript na interfejsie systemu CMS o dużej skali zwiększa obszar potencjalnych problemów, co jest jednym z powodów, dla których żaden z poważnych systemów CMS nie stosował leniwego ładowania w swoim jądrze przed wprowadzeniem ustandaryzowanej funkcji przeglądarki.
Rekomendacje techniczne
Domyślnie włącz leniwe ładowanie
Ogólna rekomendacja dla systemów CMS stosujących opóźnione wczytywanie na poziomie przeglądarki jest taka, aby włączyć je domyślnie, czyli dodać loading="lazy" do obrazów i ramek iframe, najlepiej tylko do tych elementów, które zawierają atrybuty wymiarów.
Włączenie tej funkcji domyślnie spowoduje większą oszczędność zasobów sieci niż gdyby trzeba było ją włączyć ręcznie, np. w przypadku poszczególnych obrazów.
W miarę możliwości loading="lazy"należy dodawać tylko do elementów, które prawdopodobnie będą wyświetlane poniżej foldu.
Chociaż wdrożenie tego wymagania może być skomplikowane ze względu na brak informacji po stronie klienta i różne rozmiary widoku, zalecamy przynajmniej użycie przybliżonej heurystyki, aby pominąć elementy takie jak obrazy nagłówka, które prawdopodobnie będą się pojawiać powyżej obszaru widocznego, zamiast ładowania opóźnionego.
Zezwalanie na modyfikacje poszczególnych elementów
Chociaż domyślnie atrybut loading="lazy" powinien być dodawany do obrazów i ramek iframe, ważne jest, aby umożliwić pominięcie tego atrybutu w przypadku niektórych obrazów, np. w celu optymalizacji pod kątem LCP. Jeśli odbiorcy systemu CMS są na ogół bardziej zaawansowani technologicznie, można udostępnić element sterujący w interfejsie dla każdego obrazu i elementu iframe, aby umożliwić rezygnację z ładowania opóźnionego.
Alternatywnie lub dodatkowo interfejs API może być udostępniony deweloperom zewnętrznym, aby mogli wprowadzać podobne zmiany za pomocą kodu.
WordPress na przykład pozwala pominąć atrybut loading w przypadku cały tag HTML lub kontekst albo określony element HTML w treści.
Dostosowanie istniejących treści
Ogólnie można zastosować 2 metody dodawania atrybutu loading do elementów HTML w systemie CMS:
- Możesz dodać atrybut w edytorze treści w backendzie, zapisując go na stałe w bazie danych.
- Dodaj atrybut na bieżąco podczas renderowania treści z bazy danych na froncie.
Zalecamy, aby system CMS dodawał ten atrybut na bieżąco podczas renderowania, aby korzyści z opóźnionego ładowania były dostępne również w przypadku istniejących treści. Jeśli atrybut można dodać tylko w edytorze, korzyści z niego będą wynikać tylko z nowych lub niedawno zmodyfikowanych treści, co znacznie ograniczy wpływ CMS na oszczędzanie zasobów sieci. Ponadto dodanie atrybutu na bieżąco umożliwi w przyszłości wprowadzanie zmian, jeśli możliwości wczytywania opóźnionego na poziomie przeglądarki zostaną rozszerzone.
Dodawanie atrybutu na bieżąco powinno uwzględniać potencjalnie istniejący atrybut loading w elemencie i pozwalać temu atrybucie na pierwszeństwo. W ten sposób CMS lub jego rozszerzenie może też stosować podejście oparte na edytorze bez powodowania konfliktu z duplikowanymi atrybutami.
Optymalizacja skuteczności po stronie serwera
Podczas dodawania atrybutu loading do treści na bieżąco za pomocą np. oprogramowania pośredniczącego po stronie serwera należy wziąć pod uwagę szybkość. W zależności od systemu CMS atrybut może zostać dodany za pomocą przeglądania DOM lub wyrażeń regularnych. Z uwagi na wydajność zalecamy stosowanie tego drugiego rozwiązania.
Użycie wyrażeń regularnych powinno być ograniczone do minimum. Możesz na przykład użyć jednego wyrażenia regularnego, które zbiera wszystkie tagi img i iframe w treści, w tym ich atrybuty, a następnie dodaje atrybut loading do każdej z tych łańcuchów tagów, jeśli to konieczne. WordPress na przykład ma jedno ogólne wyrażenie regularne do wykonywania różnych operacji na bieżąco na wybranych elementach,
w tym dodawanie loading="lazy", używając jednego wyrażenia regularnego do obsługi wielu funkcji. Ta forma optymalizacji jest też kolejnym powodem, dla którego zalecamy stosowanie ładowania opóźnionego w rdzenia systemu CMS zamiast rozszerzenia – pozwala ona na lepszą optymalizację wydajności po stronie serwera.
Dalsze kroki
Sprawdź, czy istnieje już zgłoszenie dotyczące prośby o dodanie funkcji w systemie CMS, lub otwórz nowe, jeśli nie ma jeszcze takiego zgłoszenia. W razie potrzeby odwołuj się do tego posta, aby uzasadnić swoją propozycję.
Jeśli masz pytania lub komentarze albo chcesz, aby Twój system CMS został wymieniony na tej stronie, wyślij mi tweeta (felixarntz@). Możesz też to zrobić, jeśli Twój system CMS obsługuje wczytywanie opóźnione na poziomie przeglądarki. Jeśli napotkasz inne problemy, chętnie dowiem się więcej o nich, aby móc znaleźć rozwiązanie.
Jeśli jesteś deweloperem platformy CMS, sprawdź, jak inne systemy CMS implementują wczytywanie opóźnione:
Możesz wykorzystać wnioski z badań i zalecenia techniczne z tego wpisu, aby zacząć przesyłać kod do swojego systemu CMS, na przykład w postaci poprawki lub zgłoszenia do repozytorium.
Zdjęcie główne: Colin Watts, Unsplash.