Ta sama strona WordPress, zbudowana trzy razy: 63 → 99 w PageSpeed
Wziąłem jedną stronę główną firmy ogrodniczej i zbudowałem ją trzy razy: rozdmuchany Elementor, ten sam Elementor po optymalizacji w miejscu i lekki rebuild napisany ręcznie. Każdą zmierzyłem w Lighthouse na mobile. Poniżej dokładnie: co się zmieniło, o ile i dlaczego.
Trzy stany, jedna strona
| Wariant | Perf | A11y | BP | SEO | LCP | Waga |
|---|---|---|---|---|---|---|
| Przedrozdmuchany Elementor | 63 | 96 | 100 | 85 | 26,5 s | 5111 KiB |
| W miejscuElementor zostaje | 71 | 96 | 100 | 85 | 5,9 s | 1183 KiB |
| Rebuildręczny, bez buildera | 99 | 100 | 100 | 100 | 2,0 s | 461 KiB |
Wszystkie trzy renderują tę samą pełnoszerokościową stronę (hero, o nas, galeria, formularz). Różni się tylko sposób budowy i szybkość. Na desktopie wyniki były wysokie od początku, problem siedzi na mobile.
Jedna strona ogrodnicza na page builderze
Fikcyjna firma Greenfield Landscaping ma jedną, pełnoszerokościową stronę główną, postawioną na OceanWP + Elementor, czyli tym samym zestawie co większość stron, które dostaję do przyspieszenia. Każdy pomiar to Lighthouse na presecie mobile z symulowanym throttlingiem, więc liczby odpowiadają telefonowi ze średniej półki, a nie desktopowi na światłowodzie.
Co ją ciągnęło w dół
- Zdjęcia hero i galerii w pełnym rozmiarze (JPEG 2400px, ~5 MB) wciśnięte w małe miejsca na stronie.
- Hero to obraz tła w CSS, odkrywany przez przeglądarkę późno, więc LCP czekał na wszystko inne. Stąd te 26,5 s.
- OceanWP + Elementor + Happy Addons + Contact Form 7 + Font Awesome + AddToAny, każdy ładuje CSS i JS na całej stronie. Trzy z nich nie są nawet używane na tej podstronie.
- Render-blocking Google Fonts (Roboto + Roboto Slab, wszystkie grubości), bez preload.
W miejscu: naprawa bez ruszania Elementora
Najpierw wariant dla kogoś, kto nie chce zmieniać sposobu edycji strony. Wszystko idzie przez jeden mu-plugin, bez przebudowy, edytor zostaje dokładnie taki, jaki był.
- Obrazy przekonwertowane do WebP w rozmiarze wyświetlania skryptem w Pythonie (Pillow): z ~5 MB do ~0,8 MB.
- Wyłączone trzy nieużywane wtyczki, usunięte Google Fonts, w zamian fonty systemowe.
- Lazy-load obrazów pod foldem, preload hero (elementu LCP).
Wynik: 63 → 71 Performance, LCP 26,5 s → 5,9 s, waga strony spadła o 77%. Duże, realne wygrane, a edytor nietknięty.
To, co zostaje, to render-blocking CSS page buildera. Ręczne wydłubywanie critical CSS pogorszyło sprawę (więcej HTML plus skok layoutu), więc uczciwy pułap optymalizacji w miejscu na darmowych narzędziach to jakieś 72 punkty. Wyżej wymaga płatnego optymalizatora, który robi automatyczny critical CSS i opóźnianie JS.
Lekki rebuild: ta sama strona, bez buildera
Ta sama treść, ten sam układ, bez WordPressa i bez page buildera. Jeden plik HTML z CSS w środku, więc nic nie blokuje pierwszego renderowania.
- Jeden plik HTML, CSS w środku (zero blokujących arkuszy stylów).
- Fonty systemowe, więc żadnego pobierania fontów na ścieżce krytycznej.
- AVIF z fallbackiem WebP dla zdjęć.
- Responsywne hero z preload; obrazy pod foldem lazy z ustawioną szerokością i wysokością, więc CLS wynosi 0.
Wynik: 99 / 100 / 100 / 100, LCP 2,0 s, 461 KiB. Waga strony o 91% niższa niż w wersji rozdmuchanej, przy tej samej treści.
Page builder ma swój sufit i trzeba to powiedzieć wprost
Render-blocking CSS page buildera kosztuje sporo punktów w Performance, których na darmowych narzędziach nie da się odzyskać bez rebuildu. Optymalizacja w miejscu i tak daje duże, realne wygrane (waga strony niższa o 77%, LCP 26,5 → 5,9 s) i nie zmienia sposobu, w jaki pracujesz. Wynik powyżej 90 na mobile wymaga albo płatnego optymalizatora, albo lekkiego rebuildu. Kto obiecuje page builder na 100 przy darmowych narzędziach, ten albo mierzy desktop, albo nie mierzy wcale.
„Przyspiesz mój WordPress"
Zostajesz przy edytorze. Optymalizuję w miejscu: obrazy, fonty, nieużywane wtyczki, lazy-load, preload. Duże wygrane, uczciwie o suficie.
„Zbuduj porządnie"
Ta sama strona, napisana ręcznie. Usuwam render-blocking CSS buildera w całości i strona dochodzi do 99/100 na mobile.
Podeślij URL swojej strony
Zmierzę ją na mobile i powiem, która ścieżka się opłaca, jeszcze przed jakąkolwiek umową.
Zamów sprawdzenie szybkości