Core Web Vitals rescue dla WordPressa zbudowanego z AI

#Core Web Vitals rescue dla WordPressa zbudowanego z AI: problem po budowie

Asystent AI postawi stronę WordPress online w jedno popołudnie. Nie powie Ci, że czwarta wtyczka “speed”, którą polecił, walczy z drugą warstwą cache, którą polecił dwa prompty wcześniej. Właściciele zwykle dowiadują się o tym ze screenshota PageSpeed Insights z czerwonymi liczbami albo od kogoś w firmie, kto pyta, czemu szybko wyglądająca strona ładuje się jak w 2015 roku. To rescue skrojony pod ten konkretny wzorzec awarii: Core Web Vitals zepsute konkretnie, bo build złożył prompt, nie bo biznes świadomie wybrał ciężki motyw.

To usługa węższa niż ogólna optymalizacja szybkości. Standardowy audyt wydajności zakłada świadome, choć niedoskonałe, decyzje architektoniczne podjęte w czasie. Ten rescue zakłada odwrotnie: asystenta, który odpowiedział na dziesięć osobnych prośb dziesięcioma instalacjami wtyczek w jednej sesji budowy, i page builder, który wysyła znacznik, CSS i JavaScript każdego bloku niezależnie od tego, co faktycznie renderuje się nad linią zgięcia.

#Czemu buildy z AI psują Core Web Vitals

Trzy mechanizmy pokazują się w praktycznie każdym buildzie z AI, który otwieramy, zwykle razem.

Nadmiar wtyczek. Duże modele językowe nie mają na żywo inwentarza tego, co jest już zainstalowane. Prompt pierwszy dostaje wtyczkę do formularzy. Prompt piętnasty dostaje drugą wtyczkę do formularzy, bo model nie pamięta promptu pierwszego. Każda instalacja jest obronna indywidualnie; suma nie jest. Zanonimizowane liczby za tym wzorcem opisaliśmy w rozroście wtyczek po budowie z AI: 38 aktywnych wtyczek to standardowy punkt startowy dla trzytygodniowego buildu z AI, nie odstępstwo.

Powielone optymalizatory. Instynktowną odpowiedzią na wolną stronę jest “zainstaluj wtyczkę cache”. Kiedy TTFB tydzień później nadal jest wysokie, kolejny prompt to “zainstaluj szybszą wtyczkę cache”, często bez wyłączenia pierwszej. Regularnie znajdujemy dwa full-page cache, dwa minifikatory i dwie wtyczki do optymalizacji obrazków walczące ze sobą na tej samej stronie, czasem produkujące losowo zepsuty JavaScript, bo dwa minifikatory przepisują te same zasoby inaczej.

Blokujący render output buildera. Page buildery generują generyczny, wielokrotnego użytku znacznik, żeby każdy blok działał w każdym layoucie. Ta generyczność oznacza, że każdy blok wysyła własny CSS i JS, ładowane niezależnie od pozycji w viewporcie. Sekcja hero zbudowana buildera z dodatkowym pakietem addonów regularnie wysyła więcej blokującego render CSS, niż cała strona faktycznie potrzebuje - to dokładnie to, co ściąga LCP i INP na czerwono na mobile.

Widzieliśmy to na sklepie meblowym hostowanym na home.pl: page builder z dwoma dodatkowymi paczkami addonów wysyłał ponad 400 KB blokującego CSS na hero, mimo że powyżej linii zgięcia widać było tylko nagłówek i jedno zdjęcie produktu. Po usunięciu paczek addonów i przeniesieniu hero na lżejszy blok LCP spadł z 5,1s do 2,3s na mobile, bez zmiany hostingu.

#Dowód z praktyki: 38 wtyczek do 21, TTFB 1,47s do 0,68s

Najczystszy dowód to zanonimizowany przypadek opisany w całości w rozroście wtyczek po budowie z AI. Strona B2B z branży usług profesjonalnych, budowana przez około trzy tygodnie z narzędziami AI, wystartowała z:

Hosting i motyw nie zmieniły się. Wygrana przyszła z usunięcia powielonych wtyczek SEO, cache i analityki, scalenia trzech builderów formularzy w jeden i audytu trzech customowych mu-pluginów wygenerowanych przez asystenta, z których dwa usunięto po przejściu bezpieczeństwa. Tak wygląda Core Web Vitals rescue na stronie zbudowanej z AI: głównie odinstalowania i scalenia, nie nowa infrastruktura.

#Tabela triażu: symptom, przyczyna, akcja

Uruchom to przed zleceniem pełnego zaangażowania. Powie Ci, czy szybkie przejście wystarczy, czy build wymaga etapowego demontażu.

Jeśli większość wierszy wskazuje na izolowane powielenie wtyczek, zwykle wystarczy skupiony demontaż. Jeśli customowy kod AI, nadmiar wtyczek i zepsute procesy pojawiają się razem, zaplanuj pełniejszy rescue, zamiast łatać wydajność w izolacji.

#Etapowy porządek demontażu

Praca nad wydajnością trzyma się ustalonego porządku, żeby jedna poprawka nie została zepsuta przez kolejną partię, a dziury bezpieczeństwa w customowym kodzie nie zostały odsłonięte przez usunięcie wtyczek, które je tłumiły.

1. Zamroź nowe instalacje. Żadna prośba o wtyczkę, dopóki nie istnieje ledger z audytu.
2. Najpierw usuń powielone wtyczki cache i optymalizacji. Dwa full-page cache walczące ze sobą to najczęstsza przyczyna niekonsekwentnych wyników PageSpeed; napraw to przed dotknięciem czegokolwiek innego.
3. Audytuj customowy kod AI, zanim usuniesz komercyjne wtyczki wokół niego. Jeśli wygenerowany mu-plugin cicho zależy od wtyczki, którą właśnie usuwasz, usunięcie wtyczki najpierw psuje stronę.
4. Scalaj nakładające się narzędzia w partiach po pięć-osiem, testując checkout i formularze po każdej partii, mierząc TTFB i liczbę zapytań.
5. Napraw ścieżkę renderu na szablonach niosących ruch: odłóż nieistotny JS, dodaj wyraźne wymiary obrazków i czcionek, ogranicz użycie addonów buildera na hero.
6. Zmierz ponownie i ustal budżet wtyczek, żeby kolejna zmiana z pomocą AI nie odtworzyła tych samych dziur.

#Checklist pomiarowy: LCP, INP, CLS i TTFB

Śledź wszystkie cztery razem. Sam wynik PageSpeed maskuje, która konkretna metryka faktycznie napędza wpływ na biznes.

• LCP (Largest Contentful Paint) - cel poniżej 2,5s. Mierz na faktycznym szablonie hero, nie na lekkiej stronie testowej.
• INP (Interaction to Next Paint) - cel poniżej 200ms. Testuj na stronie z formularzem albo filtrem, gdzie użytkownicy faktycznie interagują.
• CLS (Cumulative Layout Shift) - cel poniżej 0,1. Testuj z obecnym bannerem cookie i lazy-loadowanymi obrazkami, bo to częste źródła CLS na stronach zbudowanych z AI.
• TTFB (Time to First Byte) - cel poniżej ~800ms nieskeszowany na standardowej stronie. Mierz curl albo WebPageTest w pięciu przebiegach i weź medianę, nie jedną próbkę.
• Zapytania do bazy na widok - śledź Query Monitorem; oznacz wszystko powyżej ~120 na stronie treściowej.

Mierz na stronie głównej, najciężej obciążonym landingu i checkoucie albo kontakcie. Strona, która wygląda szybko na stronie głównej i wolno na checkoucie, to częsty wzorzec buildów z AI, bo szablony ciężkie od buildera rzadko są tymi, które ktokolwiek ostatnio testował.

#Czego nie robić

• Nie instaluj kolejnej wtyczki optymalizacyjnej, żeby naprawić wolną stronę spowodowaną nadmiarem wtyczek. Tak strony docierają do 40 wtyczek na starcie.
• Nie uruchamiaj dwóch full-page cache “na wszelki wypadek”. Wybierz jeden i skonfiguruj go poprawnie.
• Nie usuwaj customowych mu-pluginów AI, zanim zaudytujesz, od czego zależą. Niektóre cicho łatają dziurę, którą inna wtyczka zostawiła otwartą.
• Nie ściagaj syntetycznego wyniku 100 w PageSpeed kosztem realnego LCP/INP/CLS na szablonach generujących przychód.
• Nie pomijaj pomiaru stron checkout i kontakt, bo “strona główna jest w porządku”. Szablony drugorzędne, ciężkie od buildera, to zwykle miejsce, gdzie żyją najgorsze liczby.

#Jak przebiega zlecenie

Krok 1 - baza. Mierzymy LCP, INP, CLS i nieskeszowany TTFB na reprezentatywnych szablonach, plus pełną inwentaryzację wtyczek i bazy danych.

Krok 2 - audyt. Każda wtyczka zmapowana do faktycznej roli; duplikaty i blokujący render output buildera oznaczone.

Krok 3 - etapowy demontaż. Partie po pięć-osiem wtyczek, wyłączone, przetestowane, zmierzone, potem usunięte. Żadnych masowych usunięć na produkcji.

Krok 4 - naprawa ścieżki renderu. Odłożenie nieistotnych skryptów, naprawa ładowania obrazków i czcionek, konsolidacja do jednej warstwy cache.

Krok 5 - ponowny pomiar i budżet. Te same szablony, te same narzędzia, dokumentowane przed/po, plus zasada, że żadna nowa wtyczka nie wchodzi bez wycofania lub scalenia istniejącej.

#Powiązane usługi i materiały

Ten rescue idzie w parze z szerszą pracą naprawczą, którą robimy na stronach generowanych:

Głębszy materiał: Rozrost wtyczek: gdy build z AI zostawia Cię z 40 wtyczkami - pełen zanonimizowany przypadek za liczbami użytymi powyżej.

Wycena jest indywidualna i ustalana po audycie bazowym. Skontaktuj się z nami i podaj stronę oraz krótką notatkę o tym, jak była budowana.