Wnioski dotyczące stosowania standardowego atrybutu wczytywania
Celem tego posta jest przekonanie programistów platformy CMS i współtwórców (czyli osób, które opracowują rdzenie CMS), że nadszedł czas, aby wdrożyć obsługę leniwego ładowania obrazów na poziomie przeglądarki. Podam Ci też zalecenia, które pomogą Ci zapewnić użytkownikom wysoką jakość obsługi i umożliwić dostosowywanie przez innych programistów przy jednoczesnym wdrożeniu leniwego ładowania. Wskazówki te pochodzą z naszego doświadczenia przy dodawaniu obsługi do WordPressa oraz w wdrażaniu narzędzi Joomla, Drupal i TYPO3.
Niezależnie od tego, czy jesteś programistą platformy CMS czy użytkownikiem CMS (tj. osobą, która tworzy witryny za pomocą CMS), w tym poście znajdziesz więcej informacji o zaletach leniwego ładowania w systemie CMS na poziomie przeglądarki. 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
weszło w życie standardu HTML WhatWG i jest coraz popularniejsze w różnych przeglądarkach.
Te kamienie milowe stanowią jednak podstawę szybszego i bardziej oszczędzającego zasoby internetowe.
Teraz może korzystać z atrybutu loading w rozproszonym ekosystemie internetowym.
Systemy zarządzania treścią sterują około 60% witryn, dlatego platformy te odgrywają kluczową rolę w udostępnianiu w internecie nowoczesnych funkcji przeglądarek. W przypadku kilku popularnych systemów CMS typu open source, takich jak WordPress, Joomla i TYPO3, które wdrożyły już obsługę atrybutu loading w obrazach, zapoznaj się z ich podejściem i wynikami, które warto rozważyć przy wdrażaniu tej funkcji również na innych platformach CMS. Leniwe ładowanie multimediów to kluczowa funkcja w zakresie wydajności stron internetowych, z której witryny powinny korzystać na dużą skalę, dlatego zalecamy wdrożenie go na podstawowym poziomie CMS.
Przypadki wdrożenia leniwego ładowania teraz
Standardowa
Przyjęcie w systemach CMS niestandaryzowanych funkcji przeglądarek ułatwia powszechne testowanie i może wskazać obszary wymagające poprawy. W systemach CMS obowiązuje jednak ogólna zgodność co do tego, że o ile funkcja przeglądarki nie jest ustandaryzowana, najlepiej, aby była wdrażana w formie rozszerzenia lub wtyczki dla danej platformy. Dopiero po ustandaryzowaniu funkcji można rozważyć ich wdrożenie w podstawowej platformie.
Obsługiwane przeglądarki
Podobna wątpliwość dotyczy obsługi tej funkcji w przeglądarkach – większość użytkowników systemu CMS powinna być w stanie z niej korzystać. Jeśli znaczna część przeglądarek nie obsługuje jeszcze danej funkcji, należy upewnić się, że nie będzie ona miała w nich negatywnego wpływu.
Progi odległości od widocznego obszaru
Częstym problemem implementowania leniwego ładowania jest to, że z reguły zwiększa się 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 zachowawczo, a dodatkowo mogą doprecyzować swoje podejście na podstawie rzeczywistych danych o wrażeniach użytkowników, minimalizując wpływ, więc leniwe ładowanie na poziomie przeglądarki powinno być bezpieczne dla platform CMS.
Zalecenia dotyczące wygody użytkowników
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, aby przeglądarka mogła wywnioskować współczynnik proporcji tych elementów przed ich faktycznym wczytaniem. Ta rekomendacja jest ważna niezależnie od tego, czy element jest ładowany leniwie, czy nie. Jednak ze względu na o 0,1% większe prawdopodobieństwo, że obraz nie zostanie w pełni wczytany raz w widocznym obszarze, użycie leniwego ładowania będzie trochę bardziej przydatne.
Systemy CMS powinny zapewniać 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 w części strony widocznej na ekranie
Obecnie zalecamy, aby do obrazów i elementów iframe umieszczonych w części strony widocznej po przewinięciu dodać tylko atrybuty loading="lazy", aby uniknąć opóźnień w danych Największe wyrenderowanie treści, które w niektórych przypadkach mogą być istotne w lipcu 2021 r.. Pamiętaj jednak, że ocena pozycji elementu w odniesieniu do widocznego obszaru przed renderowaniem jest skomplikowana. Ma to zastosowanie szczególnie wtedy, gdy system CMS dodaje atrybuty loading w sposób zautomatyzowany, ale nawet po ręcznej interwencji trzeba wziąć pod uwagę kilka czynników, np. różne rozmiary i współczynniki proporcji widocznego obszaru. Zdecydowanie zalecamy jednak pomijanie obrazów powitalnych oraz innych obrazów i elementów iframe, które mogą pojawić się w części strony widocznej na ekranie, przez leniwe ładowanie.
Unikanie działania kreacji zastępczej JavaScript
Choć JavaScript może zapewniać leniwe ładowanie przeglądarek, które (jeszcze) nie obsługują atrybutu loading, takie mechanizmy zawsze najpierw usuwają atrybut src elementu graficznego lub iframe, co powoduje opóźnienie w przeglądarkach, które obsługują ten atrybut. Poza tym wdrożenie takiego rozwiązania opartego na języku JavaScript we frontendach dużego systemu CMS zwiększa obszar w przypadku potencjalnych problemów, dlatego w żadnym z największych systemów CMS przed wprowadzeniem ustandaryzowanej funkcji przeglądarki żaden główny CMS nie wdrożył leniwego ładowania.
Zalecenia techniczne
Domyślnie włącz leniwe ładowanie
W przypadku systemów CMS, które wdrażają leniwe ładowanie na poziomie przeglądarki, zalecamy włączenie tej funkcji domyślnie. Oznacza to, że element loading="lazy" należy dodawać do obrazów i elementów iframe, najlepiej tylko w przypadku tych elementów, które zawierają atrybuty wymiarów.
Włączenie tej funkcji domyślnie spowoduje większe oszczędności zasobów sieciowych niż w przypadku włączenia jej ręcznie, na przykład na podstawie pojedynczych obrazów.
O ile to możliwe, atrybut loading="lazy" należy dodawać tylko do elementów, które prawdopodobnie znajdują się w części strony widocznej po przewinięciu.
Chociaż wdrożenie tego wymagania w przypadku CMS może być skomplikowane ze względu na brak świadomości po stronie klienta i różne rozmiary widocznego obszaru, zalecamy co najmniej użycie przybliżonej heurystyki, aby pominąć elementy takie jak obrazy główne, które prawdopodobnie pojawią się w części strony widocznej na ekranie, przez leniwe ładowanie.
Zezwalaj na modyfikacje poszczególnych elementów
Choć atrybut loading="lazy" należy domyślnie dodawać do obrazów i elementów iframe, trzeba umożliwić pominięcie atrybutu w przypadku niektórych obrazów, na przykład w celu optymalizacji pod kątem LCP. Jeśli odbiorcy CMS zwykle uznaje się za bardziej obeznanych technologicznie, może to oznaczać, że w przypadku każdego obrazu i elementu iframe użytkownicy nie będą musieli korzystać z opcje leniwego ładowania.
Interfejs API może też być udostępniany zewnętrznym deweloperom, aby mogli wprowadzać podobne zmiany w kodzie.
WordPress umożliwia na przykład pominięcie atrybutu loading w przypadku całego tagu HTML lub kontekstu albo konkretnego elementu HTML w treści.
Ulepszanie istniejących treści
Ogólnie atrybut loading można dodać do elementów HTML w systemie CMS na 2 sposoby:
- Dodaj atrybut z poziomu edytora treści w backendzie i trwale zapisz go w bazie danych.
- Dodaj atrybut na bieżąco podczas renderowania treści z bazy danych we frontendzie.
Zaleca się, aby system CMS włączał dodawanie atrybutu na bieżąco podczas renderowania, ponieważ umożliwi to korzystanie z tej możliwości również w przypadku istniejących treści. Gdyby ten atrybut można było dodawać wyłącznie za pomocą edytora, korzyści byłyby dostępne tylko w przypadku nowych lub niedawno zmodyfikowanych treści, co znacząco zmniejszy wpływ systemu CMS na oszczędzanie zasobów sieci. Ponadto dodanie tego atrybutu na bieżąco pozwoli na łatwe wprowadzanie zmian w przyszłości, jeśli możliwości leniwego ładowania na poziomie przeglądarki zostaną rozszerzone.
Dodanie atrybutu na bieżąco powinno jednak dotyczyć potencjalnie istniejącego atrybutu loading elementu i umożliwiać mu pierwszeństwo. Dzięki temu system CMS lub rozszerzenie dla niego może stosować podejście oparte na edytorze, nie powodując 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 CMS atrybut może być dodany za pomocą przemierzania DOM lub wyrażeń regularnych, przy czym ten drugi atrybut jest zalecany w celu zwiększenia skuteczności.
Wyrażenia regularne powinny być ograniczone do minimum, np. jedno wyrażenie regularne, które zbiera wszystkie tagi img i iframe w treści wraz z ich atrybutami, a potem w razie potrzeby dodaje atrybut loading do każdego ciągu tagu. Na przykład w WordPressie chodzi o jedno ogólne wyrażenie regularne do wykonywania różnych operacji na określonych elementach w czasie rzeczywistym, z których dodanie loading="lazy" oznacza tylko jedno. Można użyć pojedynczego wyrażenia regularnego, aby obsługiwać wiele funkcji. Ta forma optymalizacji jest kolejnym powodem, dla którego lepiej korzystać z leniwego ładowania w podstawowej ramach systemu CMS niż z rozszerzenia – pozwala to na lepszą optymalizację wydajności po stronie serwera.
Dalsze kroki
Sprawdź, czy nie ma już zgłoszenia prośby o dodanie funkcji do Twojego systemu CMS, lub otwórz nowe zgłoszenie, jeśli jeszcze go nie masz. W razie potrzeby wykorzystaj odniesienia do tego posta na poparcie swojej oferty.
Napisz do mnie tweeta (felixarntz@), jeśli masz pytania lub uwagi. Jeśli chcesz dodać swój system CMS do tej strony, dodaj obsługę leniwego ładowania na poziomie przeglądarki. Jeśli napotkasz inne problemy, chętnie dowiem się o nich więcej i mam nadzieję, że uda mi się znaleźć rozwiązanie.
Jeśli jesteś deweloperem platformy CMS, zobacz, jak w innych systemach CMS wdrożysz leniwe ładowanie:
Możesz wykorzystać wnioski z badań i zalecenia techniczne z tego posta, aby zacząć tworzyć kod do swojego CMS, np. w formie poprawki lub żądania pull.
Zdjęcie produktu: Colin Watts na kanale Unsplash.