Skip to content
Wróć do bloga
Poradnik3 min czytania

Jak doprowadziłem tę stronę do idealnego wyniku Lighthouse

Krótka, konkretna checklista, która doprowadziła tę stronę od solidnego wyniku Lighthouse do idealnych 100 punktów w Performance, Accessibility, Best Practices i SEO.

SEOAstroPerformanceCloudflare
Grafika Perfect Lighthouse Score pokazująca 100 za Performance, Accessibility, Best Practices i SEO

Doprowadzenie raportu Lighthouse do czterech zielonych 100 na prawdziwej stronie, a nie na okrojonym demo, wymagało konkretnej, krótkiej listy poprawek, a nie mglistego „zoptymalizujmy wszystko”. Oto dokładnie to, co zadziałało na tej stronie.

Zacznij od podstaw strukturalnych

Zanim zajmiesz się wydajnością, podstawy na stronie muszą być poprawne: prawdziwy tytuł i meta description dla każdej strony, canonical URL, tagi Open Graph i Twitter Card oraz graf JSON-LD z Person/WebSite. Nic egzotycznego, ale wszystko to musi być dynamiczne dla każdej strony, a nie skopiowane z jednego szablonu. Jeśli strona obsługuje wiele języków, dodaj też alternatywy hreflang oraz tag x-default, generowane z jednego źródła prawdy, zamiast ręcznie duplikowane na każdej stronie.

Wyeliminuj jeden duży błąd z obrazami

Największym zyskiem wydajności było zastąpienie czterech surowych zrzutów ekranu z iPhone’a (PNG 1284×2778px, od 456KB do 1.3MB każdy) komponentem <Image> z Astro: wynik w WebP, jawne width/height, dzięki czemu przeglądarka rezerwuje miejsce na obraz zanim się załaduje, i rozmiar faktycznie odpowiadający temu, jak duży jest obraz na stronie. Same te cztery obrazy spadły łącznie z 3.5MB do poniżej 200KB.

<Image src={Hook} width={600} format="webp" quality={80} alt="..." />

Napraw kłamstwo w atrybucie sizes

Atrybut sizes="100vw" jest poprawny tylko wtedy, gdy obraz faktycznie zajmuje całą szerokość viewportu. Na tej stronie znajduje się on wewnątrz kontenera z paddingiem, więc rzeczywista szerokość to 100vw minus ten padding. Błąd w tym miejscu nie tylko kosztuje punkty w teście laboratoryjnym, ale sprawia, że przeglądarka pobiera większy obraz niż potrzeba przy każdej prawdziwej wizycie:

sizes="(min-width: 1024px) 34vw, calc(100vw - 2.5rem)"

Przestań serwować blokujący arkusz stylów

Mały, 7.8KB, zewnętrzny plik CSS dodawał pełny sieciowy round trip do krytycznej ścieżki renderowania, zanim strona mogła cokolwiek wyrenderować. Astro może wbudować go bezpośrednio w HTML zamiast linkować osobno:

// astro.config.mjs
export default defineConfig({
  build: { inlineStylesheets: 'always' },
});

Jedna linia i blokujące żądanie całkowicie znika z sieciowego waterfalla.

Odkładaj wszystko, co zewnętrzne

Skrypty analityczne to klasyczny przypadek: nie muszą uruchamiać się zanim odwiedzający w ogóle zobaczy stronę. Zaślepka dataLayer/gtag ładuje się od razu, więc żadne zdarzenie nie ginie, ale sam skrypt gtag.js ładuje się dopiero przy pierwszej interakcji (kliknięcie, klawisz, scroll, dotknięcie) albo kilka sekund po zakończeniu ładowania strony, w zależności od tego, co nastąpi pierwsze. Dzięki temu zewnętrzny skrypt nigdy nie konkuruje z pierwszym renderowaniem samej strony.

Dodaj dodatkowe dane strukturalne

BreadcrumbList na stronach wewnętrznych i wpisach blogowych oraz tablica sameAs w węźle Person, wskazująca na prawdziwe profile LinkedIn i GitHub, to tanie dodatki z realnym, choć skromnym, efektem: większa szansa na rich results i mocniejszy sygnał, że to konkretna, rozpoznawalna osoba, a nie anonimowa strona.

Uważaj na niespodzianki platformy

Najbardziej zaskakujące odkrycie wcale nie dotyczyło kodu. Cloudflare Pages ma przełącznik „Managed robots.txt” (w sekcji AI Crawl Control), który po cichu dokłada reguły Disallow dla GPTBot, ClaudeBot, Google-Extended i kilku innych crawlerów AI na wierzch tego, co strona faktycznie serwuje jako robots.txt. Nie wpływa to na zwykłe indeksowanie w wyszukiwarkach — Googlebot i Bingbot działają normalnie — ale oznacza, że wyszukiwarki oparte na AI w ogóle nie zobaczą treści, dopóki ten przełącznik nie zostanie świadomie wyłączony. Warto to sprawdzić niezależnie od platformy, na której coś jest wdrożone: plik, który widzi przeglądarka, nie zawsze jest tym samym plikiem, co w repozytorium.

Wynik

Raport Google PageSpeed Insights dla wersji mobilnej pavelsmolin.com z wynikiem 100/100/100/100 w Performance, Accessibility, Best Practices i SEO
Raport Lighthouse dla wersji mobilnej pavelsmolin.com, lipiec 2026.

Każda z tych poprawek sprowadza się do czegoś konkretnego: prawdziwego pliku, prawdziwej liczby bajtów, prawdziwego ustawienia w prawdziwym panelu. Żadna z nich nie wymagała więcej niż kilku zmienionych linii naraz. To jest właściwy wniosek: idealne wyniki to nie tajemnica, to krótka, konkretna checklista, zastosowana w kolejności realnego wpływu.

Jeśli konfigurujesz coś podobnego i chcesz drugiej pary oczu, napisz do mnie.