Kurs online · web performance i Core Web Vitals
Szybka strona to nie przypadek. To proces.
Dla ludzi. Dla SEO. Dla agentów AI.
Kurs dla trzech ról, które muszą się w tej sprawie dogadać: frontend developera, specjalisty i managera SEO oraz tech leada. Uczysz się mówić o wydajności jednym językiem i prowadzić ją jednym procesem: wiesz, który zasób psuje LCP, zgłaszasz to z liczbami zamiast „popraw wydajność”, i zatrzymujesz regresję w pull requeście - zanim zobaczysz ją w Search Console.
Wydajność spada między jednym
deployem a drugim.
Coraz większą część frontendu pisze dziś agent AI, który domyślnie dokłada wagi: rozdmuchany bundle, komponenty kopiowane zamiast reużywane, biblioteka wciągnięta na krytyczną ścieżkę przez jeden import. Kod przechodzi review i wchodzi na produkcję, a LCP i INP i tak lecą w dół. W tym samym czasie doszedł nowy odbiorca: agenty AI i wyszukiwarki oparte na LLM-ach odpadają na timeoutach szybciej niż Googlebot.
Optymalizacja na czuja, raz na kwartał, po zgłoszeniu.
Pomiar z PageSpeed Insights raz na miesiąc. Brak RUM-u, brak atrybucji zmian do wydania, brak bramki w CI. Regresja wychodzi po dwóch tygodniach ze statystyk, a wtedy nikt już nie wie, który commit ją wprowadził.
Powtarzalny proces z imienną odpowiedzialnością.
RUM podpięty do dashboardu i do agenta AI. Hipotezy testowane w DevTools zanim cokolwiek trafi na produkcję. Budżet wydajnościowy zatrzymuje pull requesta z regresją. Proces, który zadziała na każdym kolejnym projekcie i kliencie.
To nie kurs o AI.
To kurs o wydajności prowadzony z AI w pętli pracy.
„Labs” znaczy laboratorium, a AI jest tu narzędziem laboratoryjnym. Poniżej sześć miejsc, w których wraca w każdym module, plus siódme, o którym większość organizacji jeszcze nie myśli.
RUM podpięty przez MCP
Dane z produkcji podpinasz do agenta przez MCP i zadajesz im pytania jak SQL-em: „pokaż dziesięć ścieżek z najgorszym INP w ostatnich siedmiu dniach”. Odpowiedź wraca razem z propozycją poprawki w kodzie.
Chrome DevTools MCP i snippety
Waterfall, INP, LCP i CLS analizujesz razem z agentem - to on uruchamia DevTools i snippety. Hipoteza → wykonanie → pomiar → następna hipoteza, w jednej pętli, bez przeklikiwania paneli.
Analiza backendu z AI
Wolny backend to wolny frontend. Z agentem czytasz trace’y z New Relic, Sentry, Code Profiler PRO czy Query Monitora i lokalizujesz wąskie gardło w kilka minut.
AI w review zmian
Każda optymalizacja idzie przez review: czy zmiana nie wprowadza CLS-a, czy nie blokuje renderu, czy nie psuje dostępności.
AI generuje hipotezy
Z danych RUM agent proponuje, co najbardziej obniży INP i podniesie LCP, razem z uzasadnieniem i szacunkowym kosztem wdrożenia. Kolejność prac ustalasz na liczbach.
Gotowe skille od dużych graczy
Korzystasz ze skilli rozwijanych przez społeczność i platformy - Vercel React Best Practices, WordPress Skills i innych. Twój agent od pierwszej minuty ma kontekst Twojego stacku.
Latencja jako sygnał jakości dla wyszukiwarek AI
Crawlery AI odpadają na timeoutach dużo szybciej niż Googlebot. Do ludzi i klasycznego SEO dochodzi więc trzeci odbiorca, który pojawił się dopiero co i który już dziś decyduje o tym, czy Twoja treść w ogóle trafi do odpowiedzi modelu.
Cztery role. Jeden wspólny język.
Wydajność rozbija się najczęściej o to, że SEO, frontend i infrastruktura mówią o niej trzema różnymi językami. Ten kurs celowo obsługuje wszystkie trzy, plus czwartą rolę, która ma to spiąć w jeden proces.
Frontend developer
Piszesz w React, Next.js, Astro, Vue lub czystym JS. Chcesz proces, który zadziała w każdym kolejnym projekcie - i workflow z AI, który nie sprowadza się do wklejania promptów.
- Strategie renderowania, hydracja, podział kodu
- INP, CLS i LCP diagnozowane z DevTools MCP
- Czytanie waterfalla i profilowanie runtime’u
Specjalista i manager SEO
Wiesz, że Core Web Vitals to sygnał rankingowy, ale chcesz wskazać developerowi konkretne miejsce do poprawy, a nie zgłosić „popraw LCP”. I umieć obronić priorytet przed biznesem.
- Waterfall czytany request po requeście
- Crawl budget, CrUX i Search Console w jednym obrazie
- Wrażliwość AI crawlerów na latencję
Tech lead / architekt
Odpowiadasz za to, żeby wydajność nie była projektem jednorazowym. Potrzebujesz budżetów, bramek w CI, atrybucji zmian do wydania i podziału odpowiedzialności, który przetrwa rotację w zespole.
- Budżet wydajnościowy jako bramka pull requesta
- Atrybucja regresji do konkretnego commita
- Rytuał raportowania dla zespołu i dla biznesu
Agencja i dział e-commerce
Optymalizujesz cudze serwisy albo własny sklep, w którym każde 100 ms przekłada się na konwersję. Chcesz metodę, którą da się powtórzyć u dziesiątego klienta bez zaczynania od zera.
- Workflow audytu z klientem, od baselineu po raport
- Optymalizacja bez dostępu do kodu
- Wycena: co się opłaca, a co jest kosmetyką
To nie jest kurs dla osób, które dopiero zaczynają z webem. Zakładam znajomość HTML/CSS/JS, terminala i pracę przy realnym projekcie webowym - w dowolnym stacku (Next.js, WordPress, Astro, Vue, Nuxt, czysty HTML).
Najpełniejszy kurs web performance, jaki zrobiłem.
275 krótkich lekcji nagranych na produkcyjnych projektach - z realnymi awariami, ślepymi uliczkami i pomiarem przed i po, a nie na wyczyszczonym przykładzie z dokumentacji. Do tego transkrypcje, repozytoria i gotowe konfiguracje. Kupujesz komplet i zaczynasz tego samego dnia.
275 lekcji wideo
19,4 godziny materiału w lekcjach o średniej długości czterech minut. Jedna lekcja to jedno zagadnienie - wracasz po konkret, zamiast przewijać godzinne nagranie w poszukiwaniu jednego fragmentu.
18 modułówTranskrypcje wszystkich lekcji
Każda lekcja ma pełną, wygładzoną transkrypcję. Przeszukujesz cały kurs tekstem i skaczesz prosto do fragmentu, którego szukasz - zamiast zgadywać, w którym module to było.
pełnotekstowe wyszukiwanieRepozytoria i projekty ćwiczeniowe
Trzy gotowe projekty do wyboru: Next.js, WordPress z page builderem i Astro. Stawiasz jeden u siebie i optymalizujesz go równolegle z kursem - albo pracujesz od razu na swoim produkcyjnym serwisie.
Next.js · WordPress · AstroPrompty, skille i konfiguracje MCP
Gotowe do skopiowania: prompty audytowe, definicje celu dla agenta, konfiguracje Chrome DevTools MCP i RUM MCP, snippety do konsoli. To, co w kursie widzisz w akcji, dostajesz jako pliki.
do skopiowaniaLicencja także dla zespołu
Kurs ogląda się dobrze zespołowo: krótkie lekcje pasują na wspólny przegląd tematu przed sprintem. Dla firm mamy osobny wariant dostępu z fakturą i licencją na wiele stanowisk.
faktura VAT · wiele stanowiskKurs o procesie web performance, pokazany na produkcyjnych projektach.
Proces jest ten sam niezależnie od technologii. Pokazuję go na trzech realnych stackach, bo na abstrakcyjnych przykładach nie widać ani kosztu decyzji, ani tego, co się psuje.
Next.js
Strategie renderowania, ISR i Partial Prerendering, cache HTML na CDN, hydracja, React Compiler, Speculation Rules i prefetch.
WordPress + page builder
Realny WP z popularnym builderem: profilowanie backendu, OPcache, W3 Total Cache, Cloudflare APO i WordPress wystawiony jako serwer MCP.
Astro
Statyka i architektura wysp jako kontrapunkt dla pełnej hydracji. Cache i odpowiedniki ISR przy deployu na Netlify lub Vercel.
Jeśli Twojego stacku nie ma powyżej: Vue, Nuxt, Svelte, Remix czy czysty HTML rządzą się tymi samymi prawami sieci i przeglądarki, więc proces przenosi się na nie bez zmian.
18 modułów, 275 lekcji.
Cała ścieżka od serwera do klatki animacji.
Program jest ułożony w kolejności diagnozy, a nie w kolejności modnych tematów: najpierw infrastruktura i backend, potem krytyczna ścieżka renderowania, na końcu runtime i interakcje. Każdy duży temat ma swój moduł - po kursie wracasz do „modułu o fontach” i tam masz komplet.
Czym naprawdę są Core Web Vitals, skąd brać liczby, którym można zaufać, i dlaczego sam prompt do AI nie zoptymalizuje strony. Filozofia i proces, na których stoi cała reszta kursu.
- Rozróżnisz dane laboratoryjne od danych z produkcji i przestaniesz mylić Lighthouse z CrUX
- Ustawisz performance budget, który da się egzekwować, a nie tylko ogłosić
- Zbudujesz kolejność diagnozy: serwer → sieć → renderowanie → runtime
- Zobaczysz, w których miejscach AI realnie skraca pracę, a w których szkodzi
Pełny łańcuch: kliknięcie → DNS → TLS → CDN → backend → krytyczna ścieżka renderowania. Każde ogniwo to potencjalne wąskie gardło - i każde umiesz zmierzyć osobno.
- Rozłożysz jedno żądanie na fazy i przypiszesz każdą do konkretnego zespołu
- Zdiagnozujesz LCP na żywo i zobaczysz, co zmienia Early Hints
- Nauczysz się mówić „to jest wina TLS”, a nie „strona jest wolna”
PSI, Lighthouse, CrUX, RUM, DevTools, WebPageTest, Search Console. Kiedy ufać testom laboratoryjnym, a kiedy prawda siedzi wyłącznie w danych od realnych użytkowników.
- Poprowadzisz audyt tym samym zestawem narzędzi w każdym projekcie
- Odczytasz Crawl Stats i powiążesz wydajność z budżetem crawlowania
- Wyjaśnisz zarządowi, dlaczego „zielony Lighthouse” i czerwony CrUX to nie sprzeczność
- Ustawisz powtarzalny workflow audytu z klientem lub innym zespołem
Jedyny moduł, w którym agent AI dostaje jednocześnie dostęp do Twoich danych RUM, przeglądarki i repozytorium - i od tego momentu diagnozę prowadzicie razem, zamiast przeklikiwać panele ręcznie.
- Zainstalujesz Chrome DevTools MCP i RUM MCP i zadasz danym pytania jak SQL-em
- Zbudujesz własny tool audytowy z site profile i dwoma trybami pracy
- Podłączysz Agent Skills dopasowane do swojego stacku
- Zdejmiesz pierwszy baseline, do którego wraca cały kurs
Zanim serwer w ogóle odpowie, mijają milisekundy na DNS, handshake i negocjację protokołu. Tu je odzyskujesz, z pomiarem przed i po.
- Zmierzysz DNS lookup i fazę TLS w trzech niezależnych źródłach
- Wdrożysz TLS 1.3, session resumption i HSTS bez łańcucha przekierowań
- Rozstrzygniesz, czy Twój ruch idzie po HTTP/2 czy HTTP/3 - i co z tego wynika
- Użyjesz preconnect i dns-prefetch tam, gdzie realnie skracają, a nie kolejkują
Cały panel przechodzony przełącznik po przełączniku: co włączyć, czego nie dotykać i jak zweryfikować efekt nagłówkiem, a nie wiarą w marketing dostawcy.
- Skonfigurujesz proxy, certyfikat origin i tryb Full (strict) bez przerwy w działaniu
- Ustawisz Cache Rules i full page caching pod swój typ strony
- Ocenisz, czy Speed Brain, APO, Argo i Rocket Loader są u Ciebie zyskiem czy kosztem
- Sprawdzisz gotowość strony dla agentów AI
Najdłuższy moduł kursu: od wersji PHP i OPcache, przez profilowanie z AI, po SSG/ISR/PPR/SSR i mieszanie trybów w jednej aplikacji.
- Zdiagnozujesz serwer skryptem, testem obciążeniowym i profilerem
- Wybierzesz strategię renderowania per typ podstrony, a nie raz dla całego projektu
- Uruchomisz Partial Prerendering i SSR streaming na realnym przykładzie
- Znajdziesz zapytanie, które psuje TTFB - z pomocą Sentry, New Relic i AI
Cache w aplikacji, na serwerze i na edge - plus inwalidacja, która nie strzela w stopę po deployu. Next.js, WordPress i Astro pokazane obok siebie.
- Ułożysz warstwy cache tak, żeby się nie znosiły nawzajem
- Wystawisz HTML z CDN-a i zachowasz kontrolę nad inwalidacją
- Zestroisz cache aplikacyjny i serwerowy z regułami na Cloudflare, bez sprzecznych nagłówków
Trzy filary: mniej, później, warunkowo. Uczysz się czytać waterfall tak, że każdy zasób musi obronić swoje miejsce przed Start Render - również wtedy, gdy nie masz dostępu do kodu.
- Przeczytasz wodospad request po requeście i wskażesz winowajcę z nazwy pliku
- Zweryfikujesz hipotezę bez wdrożenia - Overrides i WebPageTest Experiments
- Napiszesz cel dla agenta AI: dane wejściowe, priorytety i etapy
- Odróżnisz realną poprawę od szumu pomiarowego (mediana, zimny cache)
Rozmiar DOM, arkusze blokujące render, technika media="print", krytyczny CSS i koszt selektorów. Mniejszy, czystszy HTML to również lepsze crawlowanie i lepszy odczyt przez LLM-y.
- Zmierzysz DOM i ocenisz, czy „Optimize DOM size” to u Ciebie realny problem
- Zdejmiesz render-blocking z arkuszy, które nie są potrzebne above the fold
- Rozstrzygniesz, kiedy krytyczny CSS pomaga, a kiedy szkodzi
- Przygotujesz prosty HTML pod boty wyszukiwarek i AI crawlery
Najdroższy zasób na stronie i główny winowajca INP. Tryby ładowania, rozmiar bundla, third-party, SPOF i cała kaskada Google Tag Managera - z audytem prowadzonym przez AI.
- Zastosujesz drzewo decyzyjne do każdego skryptu w projekcie
- Zmniejszysz bundle: code splitting, tree shaking, coverage, barrel files
- Odsuniesz GTM za pierwszą klatkę i naprawisz dataLayer psujący INP
- Zabezpieczysz się przed SPOF-em od dostawcy, którego nie kontrolujesz
Dwa momenty optymalizacji: upload-time (format, kompresja) i delivery-time (edge resize per urządzenie). Plus hero jako LCP, fasady dla YouTube i ukryte koszty next/image.
- Dobierzesz srcset i sizes tak, żeby nie serwować 2000 px na telefon
- Ustawisz hero jako priorytetowy zasób LCP i zabierzesz mu konkurencję
- Zastąpisz osadzone YouTube fasadą, która nie kosztuje sekundy
FOIT, FOUT i skok układu. Pięć wariantów ładowania porównanych na waterfallach, font-display bez pułapki CLS, subsetting i variable fonts.
- Wybierzesz wariant ładowania fontu na podstawie pomiaru na waterfallu
- Usuniesz CLS przy podmianie fontu przez dopasowanie metryk fallbacku
- Odchudzisz pliki: tylko potrzebne grubości, subset, unicode-range
Skrypt zgody musi być wcześnie (RODO), a rujnuje LCP i INP. Rozbrajasz ten konflikt, a potem puszczasz agenta AI na godzinę pracy i uczciwie liczysz, ile to naprawdę dało.
- Osadzisz CMP tak, żeby nie był elementem LCP i nie blokował parsera
- Naprawisz INP na przycisku zgody bez łamania zgodności z prawem
- Zobaczysz pełny cykl: baseline → cel dla agenta → deploy → weryfikacja
- Poznasz koszt tego podejścia i dowiesz się, kiedy się nie opłaca
Anatomia INP rozbita na trzy części i osobno naprawiana: input delay, processing time, presentation delay. Do tego scheduler.yield, web workery i diagnoza z danych produkcyjnych.
- Rozbijesz długie zadanie po kliknięciu i oddasz kontrolę przeglądarce
- Przeniesiesz ciężką logikę do web workera
- Wdrożysz optimistic UI tam, gdzie użytkownik czeka na zapis
- Wybierzesz interakcje do optymalizacji na podstawie danych z RUM-u
Co strona robi, gdy wygląda na gotową. Długie zadania, hydracja, re-rendery, React Scan i React Compiler - plus bfcache, prefetch i Speculation Rules.
- Namierzysz chunk odpowiedzialny za Total Blocking Time
- Zredukujesz re-rendery w Reakcie z React Scan i React Doctorem
- Odzyskasz natychmiastową nawigację wstecz dzięki bfcache
- Wdrożysz Speculation Rules zamiast pobierać wszystkie linki na zapas
Skąd biorą się skoki layoutu i które z nich w ogóle liczą się do CLS. Trzy pełne śledztwa: od WebPageTest przez DevTools po agenta AI i wdrożoną poprawkę.
- Zarezerwujesz miejsce pod reklamy, embedy i treści dosyłane asynchronicznie
- Odróżnisz przesunięcie karane przez CLS od nieszkodliwego
- Zamienisz akordeon na JS na wersję CSS, która nie przesuwa layoutu
Dlaczego strona drży. Pipeline style → layout → paint → composite, warstwy kompozytora, Long Animation Frames API, View Transitions i to, za co płacisz 60 razy na sekundę.
- Przepiszesz animacje na transform i opacity, czyli na to, co tanie
- Znajdziesz zgubioną klatkę i jej przyczynę w Long Animation Frames API
- Użyjesz will-change świadomie, zamiast promować pół strony
- Wdrożysz przejścia między stronami bez frameworka
Wszystko, co realnie pojawia się w lekcjach.
Materiał powstał w 2026 roku, na produkcyjnych projektach. Poniżej pełna lista technik i narzędzi, żebyś mógł ocenić poziom bez czytania całego programu.
AI w pętli pracy
Nowoczesna platforma webowa
Renderowanie i cache
Infrastruktura i pomiar
● - technika lub narzędzie, którego nie było w kursach web performance sprzed 2026 roku
Sprawdź styl prowadzenia,
zanim wydasz złotówkę.
Poniżej trzy pełne, darmowe materiały w tej samej konwencji, w jakiej zrobiony jest kurs: realny projekt, otwarte DevTools, pomiar przed i po. Jeśli ten sposób pracy Ci odpowiada, kurs daje to samo - tylko uporządkowane w 18 modułów i 275 krótkich lekcji.
+ dziesiątki webinarów na YouTube ↗
Wiedza i technika to jedno. System i kultura wydajności to drugie.
Zespół SEO jest rozliczany z Core Web Vitals, których wejścia kontrolują zupełnie inne zespoły. Deploy idzie na produkcję, metryka spada, a informacja o tym wraca po dwóch tygodniach ze statystyk. Poniżej rozkładam ten problem na części: pomiar, atrybucja zmiany, bramka w CI i imienna odpowiedzialność za każdą metrykę.
Środa, 14:32
Scenariusz przykładowy, zbudowany po to, żeby pokazać mechanizm. Liczby nie pochodzą od żadnego klienta ani wdrożenia.
- 14:32Deploy idzie na produkcję.
- 15 minut ciszy14:47p75 LCP na karcie produktu rośnie z 2,1 s do 3,4 s. Nikt tego nie widzi.
- 3 dni ciszy+3 dniSpada CTR z wyników wyszukiwania.
- 8 dni ciszy+11 dniSEO zauważa spadek w Search Console.
- 3 dni ciszy+14 dniWpada ticket „strona zwolniła”. Nikt nie wie, od czego. Zaczyna się szukanie po omacku.
- 14:32Ten sam commit. Pipeline mierzy podgląd wydania, zanim cokolwiek pójdzie na produkcję.
- 5 minut14:37Bramka zestawia wynik z
budget.json: LCP szablonu karty produktu 3,4 s przy progu 2,4 s. - 4 minuty14:41Pull request na czerwono. Merge zablokowany, w komentarzu nazwa zasobu, który urósł.
- 23 minuty15:04Autor cofa import, przez który biblioteka wjechała na krytyczną ścieżkę renderowania.
- 8 minut15:12Bramka na zielono. Wydanie wchodzi na produkcję, monitor potwierdza p75 2,1 s na trasie /produkt.
Po obu stronach ten sam commit i ten sam zespół. Po jednej użytkownicy oglądają te 3,4 s przez dwa tygodnie. Po drugiej regresja nie wychodzi poza pull requesta.
Siedem warstw, które decydują, czy wydajność przetrwa kolejny kwartał
Techniki znajdziecie w dokumentacji i w pozostałych 17 modułach tego kursu. O tym, czy wydajność zostanie w organizacji po trzecim kwartale, decyduje siedem warstw poniżej: kto odpowiada, co mierzycie, co blokuje merge i kto dostaje alert.
Klikaj kolejne warstwy. Jest ich 7, każda z innym zakresem.
00Web Performance Owner
Jedna osoba odpowiada za to, że pomiar, budżety i alerty działają, i ma za sobą kogoś, kto dysponuje budżetem. Inaczej wydajność przegrywa każdy sprint z nowymi funkcjami.
01Pomiar
RUM jako podstawa, p75 zamiast średniej, dane rozbite per typ podstrony.
02Atrybucja zmiany
Dane RUM otagowane wersją wydania i adnotacje deployów wysyłane z pipeline'u.
03Bramka w CI/CD
Budżet wydajnościowy blokuje pull requesta, zamiast lądować w raporcie, którego nikt nie otwiera.
04Alerting na delty
Regresja liczona jako zmiana względem poprzedniego wydania. Alert ma adresata z imienia i nazwiska.
05Rytuał
Tygodniowy raport, miesięczny przegląd z ambasadorami, kwartalne podsumowanie dla biznesu.
06Agent AI
Czyta dane RUM i historię deployów, raz w tygodniu wysyła raport o regresjach. Wpięty w repozytorium wskazuje też commit, od którego metryka poleciała.
Zostajecie przy narzędziach, które już macie.
Nie wymieniamy waszego stacku. Konfigurujemy to, za co już płacicie.
Cztery zmiany w konfiguracji, bez dokładania nowego narzędzia.
- Przełączyć widoki RUM ze średniej na p75 i rozbić je per typ podstrony: osobno karta produktu, listing, koszyk.
- Wysyłać wersję wydania jako tag
versionz pipeline'u, żeby monitory dało się grupować po release'ach. - Zbudować monitory liczące deltę między wydaniami zamiast progów absolutnych.
- Podpiąć kanał #webperf jako odbiorcę i wstawić do treści alertu numer wydania oraz trasę.
Sentry ma te dane, brakuje tylko ustawień.
- Włączyć Web Vitals i patrzeć na szereg czasowy p75, nie na pojedyncze zdarzenia.
- Ustawić
releaseienvironmentw SDK, żeby regresję dało się nałożyć na deploye. - Rozbić transakcje per trasa, inaczej wolne podstrony rozpłyną się w agregacie.
- Wpiąć alerty w kanał zespołowy i przypisać ambasadora do każdej reguły.
Wariant startowy. Da się ruszyć bez umowy z dostawcą APM.
- Zacząć od lekkiego RUM opartego o bibliotekę
web-vitals. CoreDash albo DebugBear wystarczą, żeby zobaczyć p75 z własnego ruchu. - Do czasu pierwszych własnych danych korzystać z CrUX i Search Console jako punktu odniesienia.
- Lighthouse CI wpiąć w pipeline pierwszego dnia, niezależnie od tego, czy RUM już stoi.
- Adnotacje deployów zapisywać od początku, nawet jeśli na starcie lądują w arkuszu.
Syntetyk to bramka przed mergem, RUM to źródło prawdy po deployu. Zielony Lighthouse przy czerwonym CrUX bierze się z mylenia tych dwóch rzeczy.
Jedna osoba po kursie przyspieszy stronę.
Zespół po kursie utrzyma to przez lata.
Najwięcej kosztuje to, że nikt nie zauważa regresji przez dwa tygodnie. Wariant zespołowy jest po to, żeby cały zespół przeszedł przez ten sam materiał i zaczął mówić o wydajności jednym językiem.
Krótkie lekcje działają dobrze jako materiał na wspólny przegląd tematu przed sprintem: cały zespół ma ten sam kontekst w 15 minut, a nie w trzy dni szkolenia stacjonarnego.
W wariancie zespołowym
- Licencja na wiele stanowisk, jedna faktura VAT, jeden proces zakupowy
- Wspólny słownik dla frontendu, SEO i infrastruktury
- Możliwość rozszerzenia o warsztat wdrożeniowy prowadzony na waszym projekcie
Kursanci pracują m.in. w Erste, CCC, Answear,
Ringier Axel Springer, x-komie i Empiku.
Przez sześć lat kursy Web Dev Insider ukończyło ponad 500 osób - mniej więcej po połowie developerów i technicznych specjalistów SEO. Poniżej firmy, w których pracują: banki, e-commerce, media i software house’y, czyli organizacje, w których wydajność mierzy się w przychodzie, nie w punktach Lighthouse.
+ dziesiątki agencji SEO, software house’ów i zespołów in-house
Co mówią kursanci - z obu stron stołu.
Opinie pochodzą z poprzedniego kursu „Zoptymalizowany Frontend”: ten sam autor, to samo podejście do procesu, ten sam nacisk na zrozumienie przyczyny zamiast kopiowania rozwiązań. Zwróć uwagę, jak często wraca wątek wspólnego języka między SEO a zespołem developerskim - to jest realny efekt, o który tu chodzi.
Kurs Bartka Misia to jedno z najlepszych szkoleń, z jakimi miałem okazję się spotkać. Autor w przystępny sposób wyjaśnia zawiłości Core Web Vitals, które my, specjaliści SEO, często zlecamy developerom. Kurs ułatwia nam komunikację i znacząco podnosi kompetencje w zakresie SEO.
Fantastyczny jest to kurs, nie zapomnę go nigdy. Bartek umiejętnie przekazuje treści w sposób łatwy do zrozumienia, wykorzystując realne przykłady z życia. Zadania domowe były świetnym uzupełnieniem teorii.
Zajmuję się pozycjonowaniem i analityką, więc szukałem sposobu na lepszą komunikację z działem IT. Kurs spełnił wszystkie oczekiwania i pozwolił zbudować solidny most komunikacyjny w firmie.
Forma prowadzenia wymusza własną inicjatywę, nie jest to bierne przepisywanie kodu. Tematy bardzo dogłębnie rozwinięte; widać, że prowadzącemu zależy, aby kursant zrozumiał przyczynę problemu.
Do tej pory wszystkie moje działania optymalizacyjne nie dawały efektów. Dzięki temu kursowi w końcu zrozumiałem czym są te wskaźniki, jak na siebie wpływają i jak je optymalizować.
Lekcje są zwięzłe i dobrze przemyślane, a każdy moduł kończy się zadaniem w dedykowanym projekcie. Polecam zarówno początkującym, jak i bardziej doświadczonym developerom.
Bartek Miś.
Web Dev Insider.
Bartek Miś
Twórca kursów „Zoptymalizowany Frontend” i „Wielka Optymalizacja WordPressa”, z których skorzystało ponad 500 osób. Od sześciu lat dzieli się wiedzą przez newsletter, darmowe webinary oraz wystąpienia na konferencjach i meetupach.
Specjalizacja: web performance, Core Web Vitals i optymalizacja frontendów niezależnie od stacku. „Zoptymalizowany Frontend AI Labs” to najobszerniejszy materiał, jaki do tej pory zrobiłem: 275 krótkich lekcji w 18 modułach, nagranych na produkcyjnych projektach.
Płacisz raz. 12 miesięcy dostępu. Bez subskrypcji.
Tego samego dnia masz komplet: 275 krótkich lekcji, transkrypcje i repozytoria. Bez automatycznych przedłużeń.
- 275 lekcji wideo w 18 modułach (19,4 h)
- Transkrypcje wszystkich lekcji
- Prompty audytowe i konfiguracje MCP
- Repozytoria kursowe: Next.js, WordPress, Astro
- Dostęp do kanału społeczności kursantów
- Dostęp przez 12 miesięcy od zakupu
- Certyfikat ukończenia
- Dowolna liczba stanowisk, jedna faktura
- Opcjonalny warsztat wdrożeniowy na Waszym projekcie
Żadnych niespodzianek po zakupie.
Kurs jest praktyczny, więc potrzebujesz środowiska, na którym da się realnie mierzyć i wdrażać. Poniżej dokładnie to, co warto mieć - nic więcej.
Środowisko lokalne
Git, Node.js i dostęp do dowolnego asystenta AI (Claude Code, Codex, Cursor, Antigravity - pełna dowolność). Tyle wystarczy, żeby przejść przez większość modułów.
Projekt, który realnie mierzysz
Najwięcej wyniesiesz, pracując na własnym serwisie - produkcyjnym albo klienckim. Jeśli nie masz takiego pod ręką, w kursie dostajesz trzy gotowe repozytoria do wyboru: Next.js, WordPress z page builderem lub Astro.
Własna domena i serwer
Moduły o DNS, TLS, Cloudflare i cache przechodzi się najlepiej na własnej domenie i serwerze (VPS albo managed hosting). Bez tego obejrzysz je jako demo - reszta kursu działa bez zmian.
Najczęstsze pytania.
275 lekcji po cztery minuty. 18 modułów.
Wszystko naraz, od razu po zakupie.
Zaczynasz dziś: mierzysz baseline, znajdujesz pierwsze wąskie gardło i wdrażasz poprawkę, zanim skończysz pierwszy moduł. A potem układasz to w proces, który zostaje w zespole.