AI Agent Loops a optymalizacja wydajności Core Web Vitals
W Zoptymalizowanym Frontendzie AI Labs pokazuję jak optymalizować wydajność stron i aplikacji (zwłaszcza tych większych, rozbudowanych - czy to WordPress czy Next.js) za pośrednictwem narzędzi AI. Działamy w oparciu o instrukcje, skillsy, serwery MCP, nawet Agent Loops (kolejny modny temat ostatnimi czasy). I na tym ostatnim wynalazku chciałbym się zatrzymać - czy jest to dobry sposób na optymalizację Core Web Vitals?
Po pierwsze chciałbym polecić bardzo fajny materiał Olafa Sulicha o Agent Loops. Merytorycznie jest to ten rodzaj contentu, który uwielbiam. Do tego super jakość :)
O co chodzi z loopami? Tak na szybko: zamiast promptować i mieć konwersację z agentem w stylu ping-pong, ustalasz cel, dajesz narzędzia, skillsy i agent działa tak długo, aż osiągnie założenie.
Trochę bullshitu się wokół Agent Loops pojawia jakoby "to koniec promptowania". Bzdura. Nadal musimy napisać prompt, z tym że agent w międzyczasie samodzielnie sobie ustali kroki, napisze narzędzia, skrypty, wdroży, potestuje i będzie działał tak długo, aż osiągnie cel.
Wracając do tematu web performance'u. Właśnie w tym wideo pojawił się wątek /goal i to w kontekście poprawy wydajności - do momentu, aż agent osiągnie 90 punktów w Lighthouse. Poczułem się wręcz zobowiązany, by strzec BHP pracy nad wydajnością i się do tego odnieść.
Gorąco polecam korzystanie z /goal w kontekście web performance. Serio :) Tylko musimy do tego podejść mądrze i w sposób, który faktycznie jest miarodajny oraz korzystny dla USERÓW + SEO + AI botów, a nie wyłącznie dla metryk.
Jeśli za cel obieramy np. minimum 90/100 w Lighthouse, pojawia się pytanie: czy agent testuje performance na localhost w wersji developerskiej, czy po wdrożeniu na serwer, np. staging, w wersji zbuildowanej i zminifikowanej?
Jeśli opiera się wyłącznie na localhost, otrzymujemy niepełny obraz sytuacji. Użytkownicy łączą się z localhostem czy z faktycznym serwerem? :) Musimy uwzględnić to w celu. Często występują też różnice między stagingiem a produkcją - zarówno w tym, co się ładuje, jak i w jaki sposób.
Poprawa wydajności z /goal odbędzie się głównie na poziomie kodu. W porządku - poprawmy tyle, ile się da. Ale co z serwerem, siecią czy nawet dostawcą DNS?
A co z cache i nagłówkami? Nie możemy zapominać o tych etapach, ponieważ bywają ważniejsze niż poprawienie przez agenta skryptu bez defer lub async. Czasem odpowiedź leży w konfiguracji Nginx, czasem w DNS, a czasem w wersji TLS.
Kolejna kwestia to złożoność projektu. Prosty landing page wygenerowany przez AI? Poprawa wydajności z /goal będzie stosunkowo łatwa.
Schody zaczynają się przy WordPressie albo rozbudowanym e-commerce w Next.js. Trochę dzieje się w kodzie, trochę w panelu zarządzania, trochę w bazie. Dochodzą skrypty zewnętrzne, które tworzą konkretne, czasem nieprzewidywalne łańcuchy ładowania zasobów.
Tutaj potrzebna jest analiza wodospadu żądań. Przepływu requestów (zarówno tych na backendzie, jak i frontendzie). Agent, nawet korzystający z DevTools MCP, może nie widzieć pełnego obrazu. Polecam więc wygenerować waterfall w WPT i również uwzględnić go w celu. Tyle że każda poprawa wymaga ponownego testu, wygenerowania nowego waterfalla i czasem ręcznych działań.
Kolejny temat? INTERAKCJE.
Fajnie, że celem jest WYDAJNOŚĆ ŁADOWANIA w Lighthouse, ale po co komu szybko załadowana strona, jeśli później laguje podczas klikania? Tu od razu hint: DevTools MCP nie zmierzy precyzyjnie main threada podczas automatycznie wykonywanych interakcji :) Coś próbuje pobrać i wydedukować, ale niestety często rekomendacje i zmiany kończą się fiaskiem.
Podobnie ze stabilnością układu. Nie powinniśmy sprawdzać jej wyłącznie podczas page load, ale również później, np. podczas scrollowania czy przechodzenia do kolejnych podstron.
Zachęcam, by nie spłycać tematu wydajności. Jest szeroki. /goal może bardzo pomóc, ale nie załatwi wszystkiego. Do prostych stron, gdy tylko "jako tako" chcemy zapewnić wystarczający poziom wydajności - spoko. Do złożonych projektów - może pomóc, ale nie ogarnie całości. Często to właśnie nasze głębsze zrozumienie web performance'u okaże się tym brakującym elementem, by zrobić to dobrze. A z tego weźmiemy pewniejszą, precyzyjniejszą wersję automatyzacji z AI i ręcznego działania, gdzie trzeba.
I jeszcze najważniejsze: agent pracujący w pętli na Lighthouse operuje na danych laboratoryjnych. Może pomóc zdiagnozować i naprawić problem, ale sam nie potwierdzi, że wydajność faktycznie poprawiła się dla użytkowników. Do tego potrzebujemy danych field albo własnego RUM. Ale o tym mówiłem już tyle razy, że nie trzeba się powtarzać :)
Tu od razu przykład, na jaki się ostatnio natknąłem. Strona WordPressa zoptymalizowana w ramach usługi optymalizacji pewnej firmy. Być może z AI, może nie - nie wiem, zgaduję. Chwalenie się wynikami:
A rzeczywistość (dane z CrUX)?
PageSpeed Insights świecą na zielono. A w realu? Użytkownicy wcale nie odczuwają strony jako szybkiej.
Przy okazji polecam Ci też lekcję z Zoptymalizowanego Frontendu AI Labs poniżej. Omawiam w nim tę samą kwestię. Zadaję pytanie "czy prompt do LLM w postaci - hej, popraw wydajność - jest wystarczający?". Odpowiedź w wideo:
Jeśli chcesz nauczyć się optymalizacji wydajności z wykorzystaniem AI (a najpierw ze ZROZUMIENIEM co i dlaczego) - wpadnij na Zoptymalizowany Frontend AI Labs.