Nauka korzystania ze standaryzowanego atrybutu wczytywania
Celem tego posta jest przekonanie programistów i współtwórców platformy CMS (tj. osób tworzących rdzenie CMS), że nadszedł czas na wdrożenie obsługi funkcji leniwego ładowania obrazów na poziomie przeglądarki. Przekażę też rekomendacje, które pomogą Ci zapewnić użytkownikom wysoką jakość usług i umożliwić ich dostosowywanie przez innych deweloperów przy jednoczesnym wdrożeniu leniwego ładowania. Te wskazówki powstały na podstawie naszego doświadczenia w zakresie obsługi platformy WordPress oraz pomocy we wdrażaniu tej funkcji przez platformy Joomla, Drupal i TYPO3.
Niezależnie od tego, czy jesteś deweloperem platformy CMS czy użytkownikiem systemu CMS (czyli osobą tworzącą strony internetowe za pomocą systemu CMS), z tego posta dowiesz się więcej o zaletach leniwego ładowania w systemie CMS. W sekcji Dalsze kroki znajdziesz sugestie, jak zachęcić platformę CMS do wdrożenia leniwego ładowania.
Wprowadzenie
W ciągu ostatniego roku leniwe ładowanie obrazów i elementów iframe z użyciem atrybutu loading
stało się częścią standardu HTML WhatWG
i coraz częściej jest wykorzystywane w różnych przeglądarkach.
Te kamienie milowe wyznaczają jednak tylko podstawy szybszej i bardziej oszczędzającej zasobów w internecie.
Atrybut loading znajduje się teraz w rozproszonym ekosystemie sieciowym.
Systemy zarządzania treścią są wykorzystywane w około 60% witryn, więc platformy te odgrywają kluczową rolę we wprowadzaniu nowoczesnych funkcji przeglądarek w internecie. Kilka popularnych systemów CMS typu open source, np. WordPress, Joomla i TYPO3, które korzystają już z atrybutu loading w obrazach, przyjrzyjmy się ich podejściu i wnioskom, które warto zastosować również na innych platformach CMS. Leniwe ładowanie multimediów to kluczowa funkcja, z której witryny powinny korzystać na dużą skalę. Dlatego zalecamy jego wdrożenie na poziomie podstawowym CMS.
Oto przykład zastosowania leniwego ładowania.
Standaryzacja
Przyjęcie niestandardowych funkcji przeglądarek w systemach CMS ułatwia powszechne testy i może wskazać obszary do poprawy. W przypadku systemów CMS panuje jednak ogólna koncepcja: o ile funkcja przeglądarki nie jest ustandaryzowana, najlepiej wdrożyć ją w postaci rozszerzenia lub wtyczki na potrzeby danej platformy. Dopiero po ustandaryzowaniu funkcji można ją wdrożyć w głównej platformie.
Obsługiwane przeglądarki
Podobne zastrzeżenia mają obsługa tej funkcji przez przeglądarki: większość użytkowników systemów CMS powinna móc z niej korzystać. Jeśli w znacznym odsetku przeglądarek ta funkcja nie jest jeszcze obsługiwana, musi ona zagwarantować, że nie przynosi ona żadnych negatywnych skutków.
Progi odległości od widocznego obszaru
Częstym problemem w przypadku implementacji leniwego ładowania jest to, że zasadniczo zwiększają one prawdopodobieństwo, że obraz nie zostanie wczytany, gdy stanie się widoczny w widocznym obszarze użytkownika, ponieważ cykl wczytywania rozpoczyna się na późniejszym etapie. W przeciwieństwie do poprzednich rozwiązań opartych na języku JavaScript przeglądarki podchodzą do tego bardziej zachowawczo, a dodatkowo mogą dostosowywać swoje podejście na podstawie rzeczywistych danych o wrażeniach użytkowników, co minimalizuje ten wpływ, dlatego leniwe ładowanie na poziomie przeglądarki powinno być bezpieczne do wdrożenia na platformach CMS.
Zalecenia związane z wrażeniami użytkownika
Wymagaj atrybutów wymiarów elementów
Aby uniknąć zmian układu, od dawna zaleca się, aby treści umieszczone, takie jak obrazy czy elementy iframe, zawsze zawierały atrybuty wymiarów width i height, tak aby przeglądarka mogła wywnioskować współczynnik proporcji tych elementów przed ich załadowaniem. Ta rekomendacja jest przydatna niezależnie od tego,
czy element jest leniwy, czy nie. Jednak ze względu na 0,1% większe prawdopodobieństwo, że obraz nie zostanie wczytany w całości w widocznym obszarze, użycie tej funkcji będzie działać nieco lepiej 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 z tych elementów, zalecamy pominięcie obrazów z leniwym wczytywaniem, które nie mają obu tych atrybutów.
Unikaj leniwego ładowania elementów w części strony widocznej na ekranie
Obecnie zalecamy, aby w systemach CMS dodawać tylko atrybuty loading="lazy" do obrazów i elementów iframe, które znajdują się w części strony widocznej po przewinięciu, aby uniknąć opóźnienia w wskaźniku Największe wyrenderowanie treści, które w niektórych przypadkach może być istotne odkryte w lipcu 2021 r.. Trzeba jednak pamiętać, że ocena pozycji elementu względem widocznego obszaru przed rozpoczęciem renderowania jest skomplikowana. Ma to zastosowanie zwłaszcza wtedy, gdy CMS stosuje automatyczne dodawanie atrybutów loading, ale nawet w przypadku ręcznej interwencji trzeba wziąć pod uwagę kilka czynników, takich jak różne rozmiary i współczynniki proporcji widocznego obszaru. Zdecydowanie zalecamy jednak pomijanie banerów powitalnych oraz innych obrazów i elementów iframe, które podczas leniwego ładowania mogą pojawić się w części strony widocznej na ekranie.
Unikanie kreacji zastępczej JavaScript
Chociaż JavaScript może służyć do zapewniania leniwego ładowania przeglądarkom, które (jeszcze) nie obsługują atrybutu loading, mechanizmy takie 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. Co więcej, wprowadzenie takiego rozwiązania opartego na języku JavaScript we frontendach dużego systemu CMS zwiększa powierzchnię potencjalnych problemów, co jest powodem, dla którego żaden inny system CMS nie wprowadził leniwego ładowania przed ustandaryzowaną funkcją przeglądarki.
Zalecenia techniczne
Domyślnie włącz leniwe ładowanie
W przypadku systemów CMS implementujących leniwe ładowanie na poziomie przeglądarki zalecamy włączenie go domyślnie. Oznacza to, że element loading="lazy" powinien być dodany do obrazów i elementów iframe, najlepiej tylko w przypadku elementów, które zawierają atrybuty wymiarów.
Włączenie tej funkcji domyślnie przekłada się na większe oszczędności zasobów sieciowych niż w przypadku jej ręcznego włączania (np. na podstawie poszczególnych obrazów).
Atrybut loading="lazy" należy w miarę możliwości dodawać tylko do tych elementów, które prawdopodobnie znajdują się w części strony widocznej po przewinięciu.
Wdrożenie tego wymagania w systemie CMS może być skomplikowane z powodu braku świadomości po stronie klienta i różnych rozmiarów widocznego obszaru, ale zalecamy, by za pomocą przybliżonych parametrów heurystycznych pomijać takie elementy jak banery powitalne, które prawdopodobnie będą wyświetlane w części strony widocznej na ekranie podczas leniwego ładowania.
Zezwalaj na modyfikacje poszczególnych elementów
Choć atrybut loading="lazy" powinien być domyślnie dodawany do obrazów i elementów iframe, jest ważny, aby pomijać ten atrybut w przypadku niektórych obrazów, np. w celu optymalizacji pod kątem LCP. Jeśli odbiorcy z systemu CMS są średnio uznawani za bardziej obeznanych technologicznie, może to być element interfejsu dostępny dla każdego obrazu i elementu iframe, który pozwala na rezygnację z leniwego ładowania tego elementu.
Oprócz tego interfejs API może być dostępny dla zewnętrznych deweloperów, aby mogli oni wprowadzać podobne zmiany za pomocą kodu.
WordPress umożliwia na przykład pominięcie atrybutu loading dla całego tagu HTML lub kontekstu albo dla konkretnego elementu HTML w treści.
Uaktualnij istniejące treści
Atrybut loading można dodać do elementów HTML w systemie CMS na 2 sposoby:
- Dodaj atrybut z poziomu edytora treści w backendie, trwale zapisując go w bazie danych.
- Dodaj atrybut na bieżąco podczas renderowania treści z bazy danych w frontendzie.
Zalecamy, aby system CMS włączał atrybut na bieżąco podczas renderowania, co pozwoli wykorzystać zalety leniwego ładowania również w istniejących już treściach. Gdyby ten atrybut można było dodać wyłącznie za pomocą edytora, korzyści mogłyby przynieść tylko nowe lub niedawno zmodyfikowane treści, co znacznie zmniejsza wpływ systemu CMS na oszczędzanie zasobów sieciowych. Co więcej, dodanie atrybutu na bieżąco umożliwi łatwe wprowadzanie zmian w przyszłości, jeśli zwiększy się możliwości leniwego ładowania na poziomie przeglądarki.
Dodanie atrybutu na bieżąco powinno uwzględniać potencjalnie istniejący atrybut loading elementu i umożliwić temu atrybutowi pierwszeństwo. W ten sposób system CMS lub jego rozszerzenie również może wdrożyć podejście oparte na edytorze bez powodowania konfliktu ze zduplikowanymi atrybutami.
Optymalizowanie wydajności po stronie serwera
Gdy dodajesz atrybut loading do treści na bieżąco za pomocą np. oprogramowania pośredniczącego po stronie serwera, bierzemy pod uwagę szybkość. W zależności od systemu CMS atrybut można dodawać za pomocą przemierzania DOM lub wyrażeń regularnych, przy czym ten ostatni atrybut jest zalecany ze względu na wydajność.
Wyrażenia regularne należy ograniczać do minimum, np. używać jednego wyrażenia regularnego, które zbiera w treści wszystkie tagi img i iframe, a następnie dodaje atrybut loading do każdego ciągu tagu (w stosownych przypadkach). W przypadku WordPressa stosuje się na przykład pojedyncze ogólne wyrażenie regularne służące do wykonywania różnych operacji w czasie rzeczywistym na określonych elementach, przy czym dodanie loading="lazy" to tylko jedno wyrażenie regularne, które usprawnia działanie wielu funkcji. Ta forma optymalizacji to kolejny powód, dla którego zamiast rozszerzenia zalecamy stosowanie leniwego ładowania w podstawowym systemie CMS – pozwala to lepiej optymalizować wydajność po stronie serwera.
Dalsze kroki
Sprawdź, czy istnieje już zgłoszenie z prośbą o dodanie funkcji obsługi tej funkcji w systemie CMS. Jeśli jeszcze nie ma, utwórz nowe zgłoszenie. W razie potrzeby wykorzystaj odniesienia do tego posta jako uzasadnienie swojej propozycji.
Jeśli masz pytania lub uwagi, napisz do mnie na Twitterze (felixarntz@). Jeśli dodaliśmy obsługę leniwego ładowania na poziomie przeglądarki, Twój system CMS zostanie wymieniony na tej stronie. Jeśli napotykasz inne problemy, chętnie dowiem się o nich więcej, być może uda mi się znaleźć rozwiązanie.
Jeśli jesteś programistą platformy CMS, dowiedz się, jak inne systemy CMS wdrożyły leniwe ładowanie:
Wykorzystaj wnioski z badań i zalecenia techniczne z tego posta, aby zacząć publikować kod w systemie CMS, np. w postaci poprawki lub żądania pull.
Baner powitalny autorstwa Colin Watts na kanale Unsplash.