Bricks Builder: Jak osiągnąć 100/100 w Google PageSpeed Insights

Wynik 100/100 w Google PageSpeed Insights to cel, który większość stron WordPress traktuje jako nieosiągalny - a Bricks Builder zmienia tę sytuację fundamentalnie. Dzięki czystej architekturze kodu, braku jQuery domyślnie i generowaniu tylko używanego CSS, Bricks startuje z lepszej pozycji niż jakikolwiek inny page builder na rynku. W tym przewodniku opisuję konkretne kroki, konfiguracje i decyzje, które pozwolą Ci osiągnąć 95-100 w PageSpeed Insights na stronach zbudowanych w Bricks Builder.

To nie jest lista „zainstaluj wtyczki do cache i gotowe”. To szczegółowy proces, który wielokrotnie stosowałem na produkcji - od optymalizacji obrazków, przez konfigurację Bricks Settings, po zaawansowane techniki eliminacji render-blocking resources. Zanim zaczniesz, warto też poznać inne narzędzia do pomiaru wyników poza samym PageSpeed Insights - opisujemy je w osobnym artykule.

Dlaczego Bricks Builder daje przewagę wydajnościową nad innymi page builderami?

Żeby zrozumieć, dlaczego Bricks jest dobrym punktem startowym dla optymalizacji, trzeba spojrzeć na to, czego nie ładuje domyślnie. Elementor ładuje jQuery (30 KB), własny framework CSS (80-120 KB), JavaScript odpowiedzialny za edytor, preloader i kilkanaście dodatkowych plików. Bricks ładuje fragment JavaScript potrzebny do interaktywności (animacje, efekty hover) i tylko CSS klas faktycznie użytych na stronie.

W testach PageSpeed Insights na czystej instalacji (bez treści, bez obrazków, tylko szkielet strony) Bricks osiąga 98-100 zarówno na mobile jak i desktop. Elementor w tym samym teście ląduje w okolicach 60-75. To fundament, na którym budujesz kolejne optymalizacje - i z tej przewagi warto korzystać świadomie, bo szybkość i dobra struktura SEO idą tu w parze. Więcej o tym, jak zoptymalizować stronę na Bricks pod wyszukiwarki, piszemy w osobnym poradniku.

Konfiguracja Bricks Builder dla maksymalnej wydajności

Zanim zaczniesz instalować wtyczki do optymalizacji, przejrzyj ustawienia samego Bricks. Kilka opcji w panelu ma bezpośredni wpływ na rozmiar generowanego kodu.

Performance Settings w Bricks

W zakładce Bricks → Settings → Performance znajdziesz opcje, które powinny być włączone na każdej produkcyjnej stronie:

• Disable WordPress emoji scripts - usuwa skrypt emoji (kilka KB, ale zawsze zbędny HTTP request)
• Disable jQuery migrate - jQuery migrate to plik ładowany dla kompatybilności z wtyczkami z epoki jQuery 1.x. Jeśli Twoje wtyczki nie potrzebują migracji, to czysty zysk
• Disable Gutenberg styles - jeśli używasz Bricks zamiast Gutenberga, style block editora są zbędne
• Disable WordPress core block library CSS - podobnie jak wyżej, dotyczy stylów dla bloków Gutenberga

CSS Loading Method: Per-Page CSS

Od wersji 1.5 Bricks oferuje opcję ładowania CSS osobno dla każdej strony (per-page CSS) zamiast globalnego pliku CSS dla całej witryny. W efekcie każda strona ładuje tylko style, które faktycznie używa - zamiast całego „atlasu CSS” witryny. Włącz tę opcję w Bricks → Settings → Performance → CSS Loading Method → Per-page (Inline CSS). Na stronach z unikatowym designem każdej podstrony zysk może być znaczny.

Disable jQuery (jeśli możliwe)

Od Bricks 1.6 możesz wyłączyć jQuery dla całej witryny - ale przed tym sprawdź, czy żadna z zainstalowanych wtyczek nie wymaga jQuery. Popularne wtyczki wymagające jQuery to: Contact Form 7 (stare wersje), Gravity Forms (używa jQuery w walidacji), niektóre slidery i galeryjki. Test: wyłącz jQuery, sprawdź konsolę przeglądarki pod kątem błędów JS, przetestuj wszystkie formularze i interaktywne elementy.

Optymalizacja obrazków: największy zysk w PageSpeed

Obrazki to zwykle 60-80% wagi strony. Właściwa optymalizacja obrazków to pojedyncza zmiana, która może przesunąć wynik Lighthouse o 15-30 punktów.

Format WebP i AVIF

WebP to format Google oferujący 25-35% mniejszy rozmiar pliku niż JPEG przy porównywalnej jakości. Wszystkie nowoczesne przeglądarki (Chrome, Firefox, Safari od 14, Edge) obsługują WebP. AVIF to nowszy format z jeszcze lepszą kompresją (40-50% mniej niż JPEG), ale wolniejszy w generowaniu i z nieco mniejszym wsparciem przeglądarek.

W WordPress najwygodniejsza metoda konwersji do WebP to wtyczki: Imagify (automatyczna konwersja przy uploadzie, serwowanie WebP przez htaccess lub picture element), ShortPixel (podobnie) lub LiteSpeed Cache (jeśli hosting działa na LiteSpeed Server - konwersja i serwowanie WebP jest wbudowane w hosting, bez obciążania PHP).

Preload obrazka LCP

Obrazek LCP (Largest Contentful Paint) - zwykle hero image lub banner - powinien być preloadowany przez przeglądarkę przed parsowaniem strony. Bez preloadu przeglądarka odkrywa ten obrazek dopiero po sparsowaniu HTML i pobraniu CSS, co opóźnia LCP o kilkaset milisekund.

W WordPress dodaj preload w funkcji wp_head lub przez wtyczkę (WP Rocket → Preload LCP Image). W Bricks możesz też ustawić priorytet ładowania obrazka w ustawieniach elementu Image - opcja „Fetchpriority: High” powoduje, że przeglądarka traktuje ten obrazek priorytetowo.

Lazy loading - tak, ale nie dla obrazka LCP

WordPress od wersji 5.5 automatycznie dodaje loading="lazy" do obrazków. To dobra domyślna opcja dla wszystkich obrazków poniżej fold. Problem pojawia się, gdy lazy loading zostanie zastosowany do obrazka LCP - wtedy przeglądarka odkłada jego ładowanie, co niszczy wynik LCP. Bricks zwykle poprawnie nie aplikuje lazy loading do pierwszego obrazka widocznego po wejściu na stronę, ale warto to sprawdzić w DevTools (zakładka Network, filtruj Img).

Eliminacja render-blocking resources

Render-blocking resources to pliki CSS i JavaScript, które blokują renderowanie strony - przeglądarka czeka na ich pobranie i parsowanie przed wyświetleniem jakiejkolwiek treści. PageSpeed Insights wyświetla je w sekcji „Eliminate render-blocking resources”.

Defer i async dla JavaScript

Skrypty JavaScript ładowane bez atrybutów defer lub async blokują parsowanie HTML. Atrybut defer powoduje, że skrypt jest pobierany równolegle z HTML, ale wykonywany po jego sparsowaniu - bezpieczny dla większości wtyczek. Atrybut async wykonuje skrypt natychmiast po pobraniu, bez czekania na HTML - używaj tylko dla skryptów niezależnych od DOM (np. Google Analytics).

W Bricks możesz zarządzać ładowaniem skryptów przez wtyczki: WP Rocket (automatyczny defer/async), LiteSpeed Cache, lub ręcznie przez wp_script_add_data(). Sprawdź każdy zdeferred skrypt na funkcjonalność - część skryptów (np. inicjalizujących slidery, masy) musi być wykonana po załadowaniu DOM.

Krytyczny CSS (Critical Path CSS)

Krytyczny CSS to zestaw reguł CSS potrzebnych do wyrenderowania tego, co użytkownik widzi po pierwszym załadowaniu strony (above the fold). Jeśli inlajnujesz krytyczny CSS bezpośrednio w sekcji <head>, przeglądarka może wyświetlić stronę bez czekania na załadowanie zewnętrznych plików CSS. WP Rocket i LiteSpeed Cache oferują automatyczne generowanie Critical CSS. W Bricks ze względu na per-page CSS krytyczny CSS jest mniejszy i łatwiej go zoptymalizować.

Cache i hosting: fundament wydajności

Nawet najlepiej zoptymalizowany kod da złe wyniki, jeśli serwer odpowiada zbyt wolno. Cache i konfiguracja hostingu to warstwy, których nie możesz pominąć.

Cache na poziomie serwera vs cache PHP

Wtyczki cache (WP Rocket, W3 Total Cache) działają na poziomie PHP - generują statyczny HTML, który jest serwowany zamiast dynamicznie generowanej strony WordPress. To dobre, ale cache LiteSpeed (jeśli hosting używa LiteSpeed Server) działa na poziomie serwera HTTP - jest szybszy, bo omija PHP zupełnie. Dla Bricks Builder na hostingu z LiteSpeed: LiteSpeed Cache Plugin to najlepszy wybór, bezkonkurencyjny w tej kombinacji.

OPcache i Redis/Memcached

OPcache to rozszerzenie PHP buforujące skompilowany bytecode - zamiast parsować PHP przy każdym żądaniu, serwer używa skompilowanej wersji. Dla WordPress z WooCommerce i pluginami oznacza to wyraźne przyspieszenie TTFB. Redis lub Memcached to object cache - buforowanie wyników zapytań do bazy danych. Oba mają sens na serwerach z większym ruchem (powyżej kilku tysięcy sesji dziennie).

Checklist: 100/100 w PageSpeed Insights dla Bricks Builder

Podsumowanie: jak osiągnąć 100/100 w PageSpeed z Bricks Builder

Bricks Builder daje Ci najlepszy punkt startowy wśród page builderów WordPress. Czysty kod, minimalne CSS, opcjonalne jQuery - to fundament, którego inne narzędzia nie oferują bez zaawansowanej optymalizacji. Do tego dodaj: konwersję obrazków na WebP, preload obrazka LCP, per-page CSS w Bricks Settings, defer nieistotnych skryptów, cache na poziomie serwera i szybki hosting z TTFB poniżej 200ms.

Wynik 100/100 w Lighthouse jest osiągalny na prostych stronach bez dużej ilości third-party scripts. Na bardziej rozbudowanych stronach realistyczny cel to 90-96 - co jest wynikiem znakomitym i daje mierzalną przewagę SEO nad konkurencją.