Wnioski dotyczące stosowania standardowego atrybutu loading
Moim celem w tym poście jest przekonanie deweloperów i współtwórców platform CMS (czyli osób, które rozwijają rdzenie CMS), że nadszedł czas na wdrożenie obsługi funkcji leniwego ładowania obrazów na poziomie przeglądarki. Podzielę się też zaleceniami dotyczącymi zapewniania wysokiej jakości wrażeń użytkowników i umożliwiania dostosowywania przez innych deweloperów podczas wdrażania leniwego ładowania. Te wytyczne wynikają z naszego doświadczenia w dodawaniu obsługi do WordPressa oraz pomaganiu w implementacji 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), z tego posta dowiesz się więcej o korzyściach płynących z leniwego ładowania na poziomie przeglądarki w systemie CMS. W sekcji Dalsze kroki znajdziesz sugestie, jak możesz zachęcić platformę CMS do wdrożenia leniwego ładowania.
Tło
W ciągu ostatniego roku leniwe ładowanie obrazów i elementów iframe za pomocą atrybutu loading stało się częścią standardu HTML WHATWG i jest coraz częściej stosowane w różnych przeglądarkach.
Te kamienie milowe stanowią jednak tylko podstawę dla szybszej i bardziej oszczędnej sieci.
Teraz to od rozproszonego ekosystemu internetowego zależy, czy będzie korzystać z atrybutu loading.
Systemy zarządzania treścią obsługują około 60% witryn, dlatego odgrywają kluczową rolę we wdrażaniu funkcji nowoczesnych przeglądarek w internecie. W kilku popularnych systemach CMS typu open source, takich jak WordPress, Joomla i TYPO3, wdrożono już obsługę atrybutu loading w przypadku obrazów. Przyjrzyjmy się ich podejściu i wnioskom, które są istotne dla wdrożenia tej funkcji również na innych platformach CMS. Leniwe ładowanie multimediów to kluczowa funkcja zwiększająca wydajność witryn, z której warto korzystać na dużą skalę. Dlatego zalecamy jej wdrożenie na poziomie rdzenia systemu CMS.
Dlaczego warto wdrożyć leniwe ładowanie już teraz
Standaryzacja
Wprowadzenie niestandardowych funkcji przeglądarki w systemach CMS ułatwia testowanie na szeroką skalę i może ujawnić potencjalne obszary wymagające poprawy. Jednak ogólny konsensus w przypadku systemów CMS jest taki, że dopóki funkcja przeglądarki nie jest ustandaryzowana, powinna być wdrażana w formie rozszerzenia lub wtyczki dla danej platformy. Dopiero po standaryzacji można rozważyć wdrożenie funkcji w podstawowej wersji platformy.
Obsługa przeglądarek
Podobnie jest z obsługą funkcji przez przeglądarkę: większość użytkowników CMS powinna mieć możliwość korzystania z tej funkcji. Jeśli istnieje znaczny odsetek przeglądarek, w których funkcja nie jest jeszcze obsługiwana, musi ona przynajmniej nie mieć na nie negatywnego wpływu.
Progi odległości od widocznego obszaru
Częstym problemem związanym z implementacją leniwego ładowania jest to, że zasadniczo zwiększa ono prawdopodobieństwo, że obraz nie zostanie załadowany, gdy stanie się widoczny w obszarze wyświetlania użytkownika, ponieważ cykl ładowania rozpoczyna się na późniejszym etapie. W przeciwieństwie do poprzednich rozwiązań opartych na języku JavaScript przeglądarki podchodzą do tego ostrożnie, a ponadto mogą dostosowywać swoje podejście na podstawie rzeczywistych danych o wrażeniach użytkowników, co minimalizuje wpływ na działanie witryny. Dlatego platformy CMS powinny bezpiecznie wdrażać leniwe ładowanie na poziomie przeglądarki.
Rekomendacje dotyczące wrażeń użytkownika
Wymagaj atrybutów wymiarów w elementach
Aby uniknąć przesunięć układu, od dawna zaleca się, aby osadzone treści, takie jak obrazy lub elementy iframe, zawsze zawierały atrybuty wymiarów width i height. Dzięki temu przeglądarka może określić format obrazu tych elementów przed ich załadowaniem. Ta rekomendacja jest istotna niezależnie od tego, czy element jest ładowany leniwie. Jednak ze względu na 0,1% większe prawdopodobieństwo, że obraz nie zostanie w pełni wczytany po pojawieniu się w widocznym obszarze, jest to nieco bardziej przydatne w przypadku leniwego ładowania.
Systemy CMS powinny udostępniać atrybuty wymiarów we wszystkich obrazach i elementach iframe. Jeśli nie jest to możliwe w przypadku każdego takiego elementu, zalecamy pominięcie leniwego ładowania obrazów, które nie mają obu tych atrybutów.
Unikaj leniwego ładowania elementów widocznych na ekranie bez przewijania
Obecnie zaleca się, aby systemy CMS dodawały atrybuty loading="lazy" tylko do obrazów i elementów iframe, które znajdują się w części strony widocznej po przewinięciu. Pozwala to uniknąć opóźnienia w przypadku danych Największe wyrenderowanie treści, które w niektórych przypadkach może być znaczne, jak odkryto w lipcu 2021 r. Trzeba jednak przyznać, że ocena pozycji elementu względem widocznego obszaru przed procesem renderowania jest skomplikowana. 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 formaty obrazu widocznego obszaru. Zdecydowanie zalecamy jednak, aby nie stosować leniwego ładowania w przypadku banerów powitalnych i innych obrazów lub elementów iframe, które mogą pojawiać się w części strony widocznej na ekranie.
Unikanie kreacji zastępczej JavaScriptu
JavaScriptu można używać do zapewniania leniwego ładowania w przeglądarkach, które (jeszcze) nie obsługują atrybutu loading, ale takie mechanizmy zawsze polegają na początkowym usunięciu atrybutu src obrazu lub elementu iframe, co powoduje opóźnienie w przeglądarkach, które obsługują ten atrybut. Dodatkowo wdrożenie takiego rozwiązania opartego na JavaScript w interfejsach dużego systemu CMS zwiększa obszar potencjalnych problemów, co jest jednym z powodów, dla których żaden duży system CMS nie przyjął leniwego ładowania w swoim rdzeniu przed wprowadzeniem standardowej funkcji przeglądarki.
Rekomendacje techniczne
Domyślne włączanie leniwego ładowania
Ogólna rekomendacja dla systemów CMS wdrażających leniwe ładowanie na poziomie przeglądarki jest taka, aby włączyć je domyślnie, tzn. dodać loading="lazy" do obrazów i elementów iframe, najlepiej tylko do tych elementów, które zawierają atrybuty wymiarów.
Domyślne włączenie tej funkcji pozwoli zaoszczędzić więcej zasobów sieciowych niż w przypadku konieczności ręcznego włączania, na przykład dla każdego obrazu.
W miarę możliwości atrybut loading="lazy" powinien być dodawany tylko do elementów, które prawdopodobnie pojawią się w części strony widocznej po przewinięciu.
Chociaż wdrożenie tego wymagania w systemie CMS może być skomplikowane ze względu na brak świadomości po stronie klienta i różne rozmiary widocznego obszaru, zalecamy przynajmniej używanie przybliżonych heurystyk, aby pomijać elementy takie jak banery powitalne, które prawdopodobnie pojawią się w części strony widocznej na ekranie, i nie stosować do nich leniwego ładowania.
Zezwalaj na modyfikacje poszczególnych elementów
Chociaż atrybut loading="lazy" powinien być domyślnie dodawany do obrazów i elementów iframe, ważne jest, aby można było go pominąć w przypadku niektórych obrazów, na przykład w celu optymalizacji pod kątem LCP. Jeśli odbiorcy CMS są uważani za bardziej zaawansowanych technicznie, może to być element sterujący interfejsu dostępny dla każdego obrazu i elementu iframe, który umożliwia wyłączenie leniwego ładowania dla tego elementu.
Można też udostępnić interfejs API deweloperom zewnętrznym, aby mogli wprowadzać podobne zmiany za pomocą kodu.
Na przykład WordPress umożliwia pominięcie atrybutu loading w całym tagu HTML lub kontekście albo w konkretnym elemencie HTML w treści.
Dostosowywanie istniejących treści
Zasadniczo istnieją 2 sposoby dodawania atrybutu loading do elementów HTML w systemie CMS:
- Dodaj atrybut w edytorze treści w backendzie, trwale zapisując go w bazie danych.
- Dodaj atrybut na bieżąco podczas renderowania treści z bazy danych we frontendzie.
Zalecamy, aby systemy CMS dodawały ten atrybut na bieżąco podczas renderowania, aby korzyści z leniwego ładowania były dostępne również w przypadku istniejących treści. Gdyby atrybut można było dodać tylko za pomocą edytora, korzyści odniosłyby tylko nowe lub niedawno zmodyfikowane treści, co drastycznie zmniejszyłoby wpływ systemu CMS na oszczędzanie zasobów sieciowych. Ponadto dodanie atrybutu na bieżąco ułatwi wprowadzanie przyszłych zmian, jeśli możliwości leniwego ładowania na poziomie przeglądarki zostaną rozszerzone.
Dodanie atrybutu na bieżąco powinno jednak uwzględniać potencjalnie istniejący atrybut loading elementu i dać mu pierwszeństwo. W ten sposób CMS lub jego rozszerzenie może również wdrożyć podejście oparte na edytorze bez powodowania konfliktów z duplikatami atrybutów.
Optymalizacja wydajności po stronie serwera
Jeśli dodajesz atrybut loading do treści na bieżąco, na przykład za pomocą oprogramowania pośredniczącego po stronie serwera, musisz wziąć pod uwagę szybkość. W zależności od systemu CMS atrybut można dodać za pomocą przechodzenia po modelu DOM lub wyrażeń regularnych. Ze względu na wydajność zalecamy tę drugą metodę.
Wyrażenia regularne powinny być używane w minimalnym stopniu, np. pojedyncze wyrażenie regularne, które zbiera wszystkie tagi img i iframe w treści, w tym ich atrybuty, a następnie dodaje atrybut loading do każdego ciągu tagów, jeśli jest to możliwe. Na przykład WordPress używa jednego ogólnego wyrażenia regularnego do wykonywania różnych operacji na bieżąco na określonych elementach, z których dodanie atrybutu loading="lazy" jest tylko jedną z nich. Wykorzystuje on jedno wyrażenie regularne do obsługi wielu funkcji. Ta forma optymalizacji to kolejny powód, dla którego zaleca się stosowanie leniwego ładowania w rdzeniu CMS-a, a nie w rozszerzeniu – umożliwia to lepszą optymalizację wydajności po stronie serwera.
Dalsze kroki
Sprawdź, czy istnieje już zgłoszenie z prośbą o dodanie funkcji w Twoim systemie CMS, lub otwórz nowe, jeśli jeszcze go nie ma. W razie potrzeby możesz odwoływać się do tego posta, aby uzasadnić swoją propozycję.
Jeśli masz pytania lub komentarze, napisz do mnie na Twitterze (felixarntz@). Możesz też poprosić o dodanie Twojego systemu CMS na tej stronie, jeśli dodano w nim obsługę leniwego ładowania na poziomie przeglądarki. Jeśli napotkasz inne problemy, chętnie się o nich dowiem, aby znaleźć rozwiązanie.
Jeśli jesteś deweloperem platformy CMS, sprawdź, jak inne systemy CMS wdrożyły leniwe ładowanie:
Możesz wykorzystać wnioski z badań i zalecenia techniczne z tego posta, aby zacząć dodawać kod do systemu CMS, na przykład w formie poprawki lub żądania pull.