Dlaczego Page Builder w Magento 2 domyślnie niszczy LCP na mobile?
Sprawa jest prosta: Page Builder w Magento 2 traktuje każde dodane zdjęcie tak, jakby użytkownik potrzebował go w pierwszej milisekundzie po otwarciu strony. Niezależnie od tego, czy to baner główny w widoku powitalnym, czy piąty z rzędu kafelek w siatce produktowej ukryty trzy ekrany niżej, silnik renderuje znaczniki <img> w trybie zachłannym (eager loading). Przeglądarka na telefonie klienta zaczyna równolegle pobierać megabajty grafik, o których istnieniu użytkownik jeszcze nawet nie wie.
Efekt? Katastrofa w Core Web Vitals, a konkretnie w metryce LCP (Largest Contentful Paint). LCP mierzy czas potrzebny na wyrenderowanie największego widocznego elementu w obszarze roboczym — najczęściej jest to baner główny lub zdjęcie produktu. Kiedy łącze komórkowe dławi się transferem niewidocznych grafik ze stopki, ładowanie kluczowego elementu LCP zostaje drastycznie opóźnione. Właśnie dlatego przygotowaliśmy darmowy moduł lazy loading dla Page Buildera, który rozwiązuje ten architektoniczny absurd za pomocą jednego przełącznika w panelu administracyjnym.
Jak działa natywny atrybut loading="lazy" i dlaczego bije na głowę skrypty JS?
Przez lata świat e-commerce próbował radzić sobie z odkładaniem ładowania grafik za pomocą bibliotek JavaScript, takich jak lazysizes czy dedykowane biblioteki bazujące na IntersectionObserver. W realiach Magento 2 — platformy, która i tak wysyła do przeglądarki solidną porcję skryptów — dorzucanie kolejnego parsera JS do obsługi obrazów przypomina gaszenie pożaru benzyną. Zanim JavaScript się pobierze, sparsuje i uruchomi, przeglądarka dawno zdąży zgubić cenne setki milisekund.
Odpowiedzią standardów webowych jest natywny atrybut HTML loading="lazy". Nie wymaga on ani jednej linijki JavaScriptu. Kiedy przeglądarka (Chrome, Safari, Firefox, Edge) widzi w kodzie <img src="..." loading="lazy">, sama decyduje, kiedy rozpocząć transfer pliku. Dopóki użytkownik nie zbliży się scrollem do określonej odległości od obrazu, żadne bajty nie są przesyłane przez sieć.
Natywny lazy loading nie kosztuje ani jednego cyklu procesora na parsowanie zewnętrznych skryptów. Oddelegowuje zarządzanie kolejką pobierania bezpośrednio do silnika przeglądarki.
Dzięki temu pasmo sieciowe telefonu pozostaje w 100% otwarte dla zasobów krytycznych: arkuszy stylów CSS, fontów oraz głównego banera LCP. Wyniki w Google PageSpeed Insights idą w górę nie dzięki trikom pod audyty, lecz dzięki realnemu odciążeniu urządzenia użytkownika.
Co zmieniliśmy w forku SISL dla Magento 2.4.9 i PHP 8.4?
W ekosystemie Magento panuje plaga porzuconych modułów. Ktoś napisał przydatne rozszerzenie pod wersję 2.3, zebrał gwiazdki na GitHubie, a potem zmienił pracę i zapomniał o projekcie. Dokładnie taka historia spotkała oryginalny moduł dodający opcję leniwego ładowania do Page Buildera. Co gorsza, jego plik composer.json nie posiadał poprawnie zdefiniowanej sekcji require, przez co menedżer pakietów pozwalał na instalację w środowiskach, w których moduł mógł wywołać trudne do zdiagnozowania błędy.
Jako butikowe studio SISL prowadzimy stałą inicjatywę techniczną: bierzemy porzucone, wartościowe narzędzia ze społeczności Magento, czyścimy ich strukturę, dodajemy testy zgodności i utrzymujemy je jako bezpłatne otwartoźródłowe forki. W przypadku tego rozszerzenia zrobiliśmy pełną weryfikację pod kątem Magento 2.4.9 oraz środowiska PHP 8.4.
- Czysta konfiguracja XML: Moduł opiera się wyłącznie na deklaratywnym rozszerzeniu konfiguracji Page Buildera (pliki
pagebuilder_base_form.xml). Nie ingeruje w bazę danych, nie dodaje pluginów PHP w pętli renderowania ani nie modyfikuje logiki widoków. - Jawne zależności w Composerze: Wprowadziliśmy rygorystyczne reguły wersji, zapobiegając konfliktom zależności przy wdrożeniach CI/CD.
- Przełącznik w UI: Administrator podczas edycji dowolnego komponentu graficznego w Page Builderze otrzymuje prosty przełącznik: Włącz / Wyłącz Lazy Loading.
Kod źródłowy jest w pełni otwarty i dostępny w repozytorium SISL na GitHubie: https://github.com/SISL-source/magento2-pagebuilder-lazyload-images. Każdy sklep może z niego korzystać bez opłat licencyjnych.
Kiedy włączać lazy loading, a kiedy zrobisz sobie nim krzywdę?
Wielu deweloperów popełnia kardynalny błąd optymalizacyjny, ustawiając loading="lazy" globalnie na wszystkich obrazach w szablonie. Jeśli oznaczysz atrybutem lazy-load baner główny (hero image), który znajduje się na samej górze strony głównej, Google natychmiast ukarze Twój wynik LCP. Dlaczego? Ponieważ przeglądarka celowo wstrzyma pobieranie najważniejszego elementu wizualnego do czasu pełnego przeliczenia układu strony.
Złota zasada optymalizacji grafik:
- Obrazy Above the Fold (pierwszy widok ekranu): Zostawiasz domyślne ładowanie (eager). To jest Twój potencjalny element LCP. Ma się pobrać z maksymalnym priorytetem.
- Obrazy Below the Fold (poniżej linii zgięcia): Wszystkie kafelki promocyjne, siatki marek, infografiki o darmowej dostawie i logotypy partnerów włączasz w tryb Lazy Loading.
Elastyczność naszego modułu polega na tym, że decyzję podejmuje osoba konfigurująca landing page w Page Builderze. Nie jesteś uwięziony w sztywnych regułach szablonu programisty.
Szerszy kontekst: Lazy loading to tylko jeden z filarów Core Web Vitals
Nie będziemy Ci wmawiać, że dodanie jednego atrybutu do obrazków zamieni ociężałe Magento w bolid Formuły 1. Poprawa Core Web Vitals w złożonym sklepie wymaga podejścia wielotorowego. Odciążenie sieci z niepotrzebnych grafik eliminuje problem przepustowości, ale pozostaje jeszcze kwestia blokowania wątku głównego procesora przez JavaScript.
Aby uzyskać realne, powtarzalne wyniki poniżej 2.5s LCP oraz doskonały wskaźnik INP (Interaction to Next Paint), lazy loading obrazów należy połączyć z zaawansowanym bundlingiem skryptów. W SISL standardem wdrożeniowym jest konfiguracja narzędzia Magepack, które rozbija gigantyczny monolit RequireJS na zbalansowane paczki ładowane asynchronicznie. Dopiero gdy połączysz zoptymalizowany transfer zasobów statycznych, odchudzony JS oraz natywny lazy loading w Page Builderze, sklep zaczyna działać płynnie nawet na tańszych smartfonach.
Jak wdrożyć moduł w swoim środowisku Magento 2?
Instalacja modułu sprowadza się do standardowej procedury composera w katalogu głównym projektu:
composer config repositories.lazyimg vcs https://github.com/SISL-source/magento2-pagebuilder-lazyload-images
composer require develodesign/magento-module-pagebuilder-lazyload-images:dev-main
bin/magento module:enable Develodesign_PagebuilderLazyloadImages
bin/magento setup:upgrade
bin/magento cache:flushPo wyczyszczeniu cache przejdź do edycji dowolnej strony w Content > Pages, otwórz komponent obrazu w Page Builderze i sprawdź zakładkę ustawień zaawansowanych. Znajdziesz tam nowe pole wyboru obsługujące atrybut loading. Zapisz stronę, otwórz narzędzia deweloperskie Chrome (zakładka Network, filtr Img) i zobacz, jak kolejne grafiki pobierają się dopiero w momencie przewijania widoku.
Jeśli Twój sklep wciąż nie mieści się w zielonych strefach Core Web Vitals, a audyty Lighthouse wykazują błędy w architekturze frontendu, napisz do nas. Przeanalizujemy stan Twojego Magento 2 i wdrożymy rozwiązania, które przekładają się na realną konwersję, a nie tylko puste cyferki w raportach.