Jak zoptymalizować Elementor, żeby nie obciążał serwera

Wprowadzenie – dlaczego Elementor bywa ciężki

Elementor to najpopularniejszy kreator stron na WordPressie, ale ma reputację ciężkiego. Domyślnie generuje sporo kodu, ładuje biblioteki, których nie potrzebujesz, i potrafi dać w kość serwerowi.

Większość poradników każe przejść na inny kreator albo radzi po prostu „zainstaluj wtyczkę cache". Tymczasem optymalizacja Elementora to proces składający się z kilku warstw, które nakładają się na siebie:

• Hosting – moc serwera, pamięć PHP i oprogramowanie
• Ustawienia Elementora – funkcje wydajności, które większość osób pomija
• Kontenery zamiast starych sekcji i kolumn
• Obrazy – formaty, rozmiary i leniwe ładowanie
• Style i skrypty – ładowanie tylko tego, co faktycznie potrzebne
• Baza danych – kontrola nad liczbą rewizji

Poniżej przechodzę przez nie po kolei – z konkretnymi wartościami i wynikami z realnych stron.

Warstwa 0: hosting jako fundament

Zanim dotkniesz ustawień Elementora, spójrz na swój hosting. Strony budowane kreatorami potrzebują 2–3 razy więcej mocy procesora i pamięci RAM niż strony na klasycznych motywach. Jeśli siedzisz na tanim hostingu współdzielonym, żadna wtyczka pamięci podręcznej tego nie naprawi.

Minimalne parametry PHP:

• Limit pamięci PHP: minimum 256 MB, przy bardziej rozbudowanych stronach lepiej 512 MB
• Procesy PHP: przy wyższym ruchu potrzebujesz 8–16 procesów obsługujących żądania – inaczej przy większej liczbie odwiedzających strona zacznie odpowiadać błędami 502 lub 504
• Limit zmiennych wejściowych: domyślnie wynosi 1000, co przy rozbudowanych stronach w Elementorze jest za niskie – podnieś go do 3000–5000

Zbyt niski limit zmiennych wejściowych to częsta, a mało oczywista przyczyna problemów. Przy dużych stronach z wieloma elementami edytor może nie zapisać wszystkich zmian, a Ty nie dostaniesz czytelnego komunikatu o błędzie. Warto więc sprawdzić tę wartość, zanim zaczniesz szukać winnych gdzie indziej.

Oprogramowanie serwera: OPcache, Redis, Nginx i dyski SSD

Same limity PHP to nie wszystko. Równie ważne jest to, jakie oprogramowanie pracuje na serwerze:

• OPcache – przechowuje skompilowany kod PHP w pamięci, dzięki czemu PHP nie musi go przetwarzać przy każdym żądaniu od nowa
• Redis – pamięć podręczna obiektów; bez niej każde odwołanie do danych oznacza pełne zapytanie do bazy MySQL
• Nginx – przy większym obciążeniu radzi sobie lepiej niż Apache
• Dyski SSD zamiast tradycyjnych dysków talerzowych – to absolutna podstawa

Przykłady z życia

W jednym z opisanych przypadków po przejściu z domyślnego motywu na Hello Elementor zanotowano +37,5% prędkości – i była to wyłącznie zmiana motywu. W innym przypadku po zmianie hostingu wynik PageSpeed na urządzeniach mobilnych skoczył z 28 do 72, a po dalszych optymalizacjach do 91.

Wniosek jest prosty: hosting to fundament. Wszystkie kolejne warstwy działają lepiej, gdy serwer ma zapas mocy.

Warstwa 1: ustawienia wydajności w Elementorze

Większość ludzi instaluje Elementora i nigdy nie zagląda do zakładki z ustawieniami wydajności. A to właśnie tam znajdziesz największe zyski przy najmniejszym nakładzie pracy. Nazwy opcji podaję tak, jak wyświetlają się w panelu.

Sposób wstawiania CSS (CSS Print Method)

Domyślnie Elementor wstawia style bezpośrednio w kod strony (osadzanie wewnętrzne). Przełączenie na plik zewnętrzny sprawia, że style są zapisywane jako osobny plik. Przeglądarka i sieć CDN mogą go wtedy przechowywać w pamięci podręcznej, więc przy kolejnych odsłonach nie trzeba go pobierać ponownie. To jedna z tych zmian, które czuć od razu.

Ulepszone ładowanie skryptów (Improved Asset Loading)

Funkcja eksperymentalna w ustawieniach Elementora. Po jej włączeniu skrypty JavaScript ładują się tylko na tych stronach, na których są faktycznie używane. Bez niej moduły takie jak galeria powiększeń, okna dialogowe czy przyciski udostępniania ładują się na każdej stronie.

• Oszczędność: około 177 KB kodu JavaScript na stronę

Ulepszone ładowanie stylów (Improved CSS Loading)

Działa na podobnej zasadzie – ładuje arkusze stylów tylko dla widżetów obecnych na danej stronie. W wersji 3.24 przyniosło to wyraźną redukcję:

• Wersja darmowa: z 267 KB do 61 KB stylów
• Wersja Pro: z 471 KB do 9 KB stylów

Zoptymalizowany kod DOM (Optimized DOM Output)

Usuwa zbędne, stare warstwy znaczników HTML, które Elementor dodawał ze względu na zgodność wsteczną. Dla porównania:

• Strony na starych sekcjach generują około 1847 elementów DOM
• Te same strony na kontenerach – około 1214 elementów
• Google zaleca, by strona miała poniżej 1400–1500 elementów DOM

Pamięć podręczna elementów (Element Caching)

Funkcja dostępna od wersji 3.22. Przechowuje na serwerze gotowy wynik działania poszczególnych widżetów, zamiast generować go przy każdym wyświetleniu. W wewnętrznych testach Elementora:

• zużycie pamięci spadło z 3 MB do 8 KB na widżet,
• czas do pierwszego bajtu (TTFB) poprawił się o 33–70%.

Co ważne, funkcja nie zapamiętuje widżetów dynamicznych (np. koszyka w WooCommerce), więc nie psuje funkcjonalności sklepu.

Czcionki Google i ikony – mniej zewnętrznych zapytań

Ikony osadzone w kodzie (Inline Font Icons)

Ta opcja zamienia bibliotekę ikon Font Awesome, pobieraną jako osobne żądanie sieciowe, na ikony osadzone bezpośrednio w stronie. Eliminuje to jedno żądanie HTTP, co na słabszym połączeniu daje 70–100 ms oszczędności.

Czcionki Google

Elementor domyślnie ładuje czcionki Google przez zewnętrzne zapytanie. To problem z dwóch powodów:

• Wydajność – takie zapytanie blokuje renderowanie strony
• RODO – przeglądarka użytkownika łączy się z serwerami Google, przekazując im jego adres IP

Rozwiązanie: wyłącz ładowanie czcionek Google przez Elementora – służy do tego filtr w motywie potomnym lub prostej wtyczce, który blokuje wypisywanie odnośników do czcionek – a następnie hostuj czcionki lokalnie na własnym serwerze.

Warstwa 2: przejście na kontenery

Elementor od wersji 3.0 oferuje kontenery (oparte na układzie Flexbox) zamiast klasycznego schematu sekcja → kolumna → widżet. Każda sekcja i kolumna to dodatkowe warstwy znaczników, a kontener pozwala uzyskać ten sam układ znacznie mniejszą ilością kodu. Różnica w wydajności jest znacząca.

Wyniki testów na 34 stronach agencyjnych:

• Elementy DOM: 1847 → 1214 (−34,3%)
• Rozmiar HTML: 142 KB → 98 KB
• Style w kodzie strony: 87 KB → 52 KB
• LCP: 3,8 s → 2,4 s (−36,8%)
• CLS: 0,12 → 0,04 (−66,7%)
• Wynik PageSpeed: 52 → 74

W testach Core Web Vitals strony na kontenerach z optymalizacją zdawały test w 91% przypadków. Strony na starych sekcjach – tylko w 27%. Kontener to nie opcjonalne ulepszenie, tylko obecny standard.

Jak bezpiecznie przeprowadzić migrację:

1. Wykonaj pełną kopię zapasową strony (pliki i baza danych)
2. Skorzystaj z wbudowanego narzędzia Elementora do konwersji sekcji na kontenery
3. Sprawdź każdą stronę po konwersji – narzędzie działa poprawnie w około 80% przypadków
4. Pozostałe strony popraw ręcznie

Warstwa 3: optymalizacja obrazów

Obrazy stanowią 50–80% wagi strony. Tu możesz stracić najwięcej, ale też najwięcej zyskać.

Formaty

• WebP jest o 25–35% lżejszy niż JPEG przy tej samej jakości
• AVIF daje kolejne 30–50% oszczędności względem WebP
• Większość nowoczesnych wtyczek do optymalizacji obsługuje już automatyczną konwersję do tych formatów

Rozmiar i kompresja

• Główny obraz na górze strony nie powinien być szerszy niż 1920 pikseli
• Docelowa waga takiego pliku – poniżej 200 KB
• Przy dobrej kompresji stratnej (jakość 70–85%) różnica wizualna jest niezauważalna

Leniwe ładowanie

WordPress i Elementor mają wbudowane leniwe ładowanie obrazów – grafiki poniżej widocznego obszaru pobierają się dopiero wtedy, gdy użytkownik do nich przewinie. Jedna ważna zasada: nie włączaj leniwego ładowania dla głównego obrazu na górze strony. To bezpośrednio pogarsza LCP. Zdjęcie widoczne od razu po wejściu na stronę powinno ładować się priorytetowo.

Przykład z życia

W jednym z opisanych przypadków po optymalizacji obrazów czas ładowania spadł z 3,76 s do 1,12 s, a łączna waga obrazów zmalała z 1,85 GB do 760 MB. Ocena w PageSpeed poprawiła się z C na B.

Warstwa 4: zarządzanie stylami i skryptami

Elementor domyślnie ładuje na każdej stronie około 200–400 KB stylów i skryptów – zanim jeszcze dodasz jakąkolwiek treść. Na słabszym połączeniu mobilnym to dodatkowe 1–3 sekundy do LCP.

Wyłącz nieużywane widżety

W Elementorze znajdziesz to w menedżerze elementów (Elementor → Element Manager). Każdy widżet z dodatku ładuje własne style i skrypty. Jeśli masz zainstalowany pakiet 50 widżetów, a używasz 5, reszta i tak ładuje się na każdej stronie. Włącz tylko te, których faktycznie potrzebujesz.

Nie łącz plików CSS i JS

Wtyczki optymalizacyjne (WP Rocket, Autoptimize) mają opcję łączenia plików stylów i skryptów w jeden. W przypadku Elementora to zwykle więcej szkody niż pożytku:

• łączenie łamie zależności między skryptami,
• strona potrafi wyglądać dobrze dla zalogowanych, a źle dla odwiedzających,
• takie błędy trudno zauważyć, bo administrator widzi poprawną wersję.

Zostaw minifikację, ale wyłącz łączenie plików.

Jedna wtyczka optymalizacyjna

Nie nakładaj na siebie WP Rocket, Autoptimize i dodatkowo optymalizacji Cloudflare. Każda warstwa nadpisuje wynik pracy poprzedniej. Wybierz jeden system. Jeśli Twój hosting ma wbudowaną pamięć podręczną serwera (LiteSpeed, Nginx FastCGI), możliwe, że nie potrzebujesz żadnej wtyczki.

Blokuj niepotrzebne skrypty na poszczególnych stronach

Część usług zewnętrznych ładuje własne biblioteki na każdej stronie, choć potrzebne są tylko na kilku:

• Mapy Google
• reCAPTCHA
• czat na stronie
• Trustpilot
• Stripe

Użyj menedżera skryptów (Perfmatters, Asset CleanUp, WP Rocket), żeby ładować je tylko tam, gdzie są potrzebne. W jednym z opisanych przypadków samo usunięcie Trustpilot i Stripe z podstron produktowych dało wymierną poprawę.

Wpisy blogowe poza Elementorem

Do prostych wpisów blogowych użyj edytora blokowego Gutenberg. Generuje on 70–80% mniej kodu niż Elementor dla tej samej treści.

Elementor zostaw dla stron, które faktycznie wymagają skomplikowanego układu – strony głównej, stron ofertowych czy stron docelowych kampanii. Wpis złożony z nagłówków, akapitów i kilku zdjęć nie potrzebuje kreatora, a każdy taki wpis w Elementorze to niepotrzebnie cięższa strona.

Warstwa 5: ograniczenie liczby rewizji

Każdy zapis strony w Elementorze tworzy w bazie danych pełną, zapisaną w postaci ciągu znaków kopię jej struktury. WordPress dodatkowo przechowuje własne rewizje. Efekt:

• baza danych stale rośnie,
• razem z nią wydłuża się czas odpowiedzi serwera.

Rozwiązanie to ograniczenie rewizji do 3–5 na stronę. Robi się to, dopisując w pliku konfiguracyjnym WordPressa (wp-config.php) stałą określającą maksymalną liczbę przechowywanych rewizji wpisu, na przykład 5. To prosta zmiana, która zapobiega rozrostowi bazy.

Co mówią liczby – wyniki z realnych wdrożeń

Zestawienie rzeczywistych wyników z opisanych przypadków stron agencyjnych:

• FCP: z 6,2 s do 2,4 s
• LCP: z 12,1 s do 3,4 s
• TTFB: z 1,8 s do 148 ms
• Waga strony: z 2,5 MB do 500 KB
• PageSpeed na urządzeniach mobilnych: z 41 do 94
• Współczynnik odrzuceń: z 61,91% do 2,80%

Te wyniki nie pochodzą z jednego przełącznika – to efekt pracy na wszystkich opisanych warstwach jednocześnie.

Podsumowanie – czy to wszystko ma sens?

Optymalizacja Elementora nie polega na jednym magicznym przełączniku. To kilka warstw, które nakładają się na siebie. Każda daje kilkuprocentową poprawę, ale ich suma robi różnicę między stroną ładującą się w 6 sekund a taką, która mieści się w 2.

Lista kontrolna:

Hosting:

• Pamięć PHP 256–512 MB
• 8–16 procesów PHP przy wyższym ruchu
• Limit zmiennych wejściowych 3000–5000
• OPcache, Redis, Nginx i dyski SSD

Elementor:

• Style jako plik zewnętrzny
• Ulepszone ładowanie skryptów i stylów
• Zoptymalizowany kod DOM i ikony osadzone w kodzie
• Pamięć podręczna elementów
• Lokalne czcionki zamiast czcionek z serwerów Google
• Kontenery zamiast sekcji

Treść i zasoby:

• Obrazy w WebP lub AVIF, maksymalnie 1920 pikseli i poniżej 200 KB
• Brak leniwego ładowania dla głównego obrazu
• Tylko używane widżety, jedna wtyczka optymalizacyjna, bez łączenia plików
• Skrypty zewnętrzne tylko tam, gdzie są potrzebne
• Wpisy blogowe w Gutenbergu
• Rewizje ograniczone do 3–5

Nie goń za wynikiem 100

I jedno zastrzeżenie: nie goń za PageSpeed 100. Wynik 80–90 na urządzeniach mobilnych przy stabilnych Core Web Vitals i dobrym doświadczeniu użytkownika to więcej niż wystarczający cel. Poświęcanie tygodni na ostatnie 5–10 punktów rzadko ma sens biznesowy. Lepsze jest wrogiem dobrego.

Elementor nie jest lekki. Ale przy odpowiedniej konfiguracji potrafi być wystarczająco szybki, żeby nie szkodzić ani użytkownikom, ani pozycjom w wyszukiwarce.