survivalism.pl

Serwis poradnikowy o survivalu i outdoorze, kilkadziesiąt wpisów w dwóch językach, prowadzony na WordPressie od 2020 roku. Przebudowałem go tak, że redaktor pracuje w znanym WordPressie, a czytelnik dostaje gotowe pliki HTML, bez WordPressa po drodze.

Punkt wyjścia: „szybciej się nie da”

Przed zmianą PageSpeed Insights dawał serwisowi 97-100 punktów. Na papierze nie było czego poprawiać. Pomiar z perspektywy zwykłego czytelnika wyglądał inaczej: test Google trafiał w pamięć podręczną serwera, a odwiedzający prawie nigdy. W serii pomiarów z jednego dnia pamięć podręczna zadziałała raz na 24 próby, a mediana czasu do pierwszego bajtu wpisu wyniosła 2,42 s.

Do tego 28 aktywnych wtyczek na publicznej stronie i w ciągu roku blisko 300 wydań do zainstalowania, z czego około 70 z poprawką bezpieczeństwa. Każda zwłoka z aktualizacją zostawiała otwarte drzwi.

Co zmieniłem

• Strona publiczna to pliki statyczne generowane z treści WordPressa. Nie ma na niej WordPressa ani bazy danych, więc wtyczki i ich luki nie mają czego zaatakować.
• WordPress zostaje jako panel redakcyjny pod osobnym adresem, za hasłem serwera i logowaniem. Redaktor pisze tak jak wcześniej i klika „Publikuj”. Po kilkunastu minutach zmiana jest na stronie.
• Przed każdą publikacją automat sprawdza zbudowaną stronę: linki, zdjęcia, komentarze, przekierowania. Gdy coś się nie zgadza, publikacja się zatrzymuje, a na stronie zostaje poprzednia wersja.
• Komentarze czytelników trafiają do panelu jako oczekujące. Zatwierdzenie komentarza samo uruchamia publikację, bez żadnych komend.
• Formularze kontaktowy i komentarzy działają jako małe skrypty z ochroną Cloudflare Turnstile, ładowaną dopiero wtedy, gdy ktoś zaczyna wypełniać formularz.

Bez utraty adresów

Serwis żyje z ruchu z wyszukiwarki i z wpisów partnerskich, więc każdy adres, przekierowanie i link miał przejść bez zmian. Po przełączeniu kontrola żywej strony przeszła 188 z 188 adresów, a lista adresów z Google Search Console 235 z 235, bez jednej różnicy. Wpisy partnerskie zachowały treść i atrybuty linków 1:1.

Wynik

• Odpowiedź serwera na wpis: teraz 0,06 s, przed przebudową 2,42 s (mediana), dla każdego odwiedzającego.
• Wpis na telefonie: 224 KiB i 9 żądań, LCP 1,65 s (przed zmianą 1,80 s), PageSpeed 99.
• Wtyczki: 0 na stronie publicznej, 11 w panelu redakcyjnym zamiast 28 na produkcji.
• Koszt: ten sam hosting współdzielony co wcześniej, budowanie mieści się w darmowym limicie GitHub Actions.

Skąd to przyspieszenie: wcześniej każde wejście czytelnika uruchamiało WordPressa, który składał stronę z bazy danych przy 28 wtyczkach. Pamięć podręczna miała to omijać, ale trafiała raz na 24 wizyty. Teraz strona jest składana raz, przy publikacji, a serwer tylko oddaje gotowy plik.

Uczciwie o tym, co jeszcze nie jest lepsze: strona główna na telefonie waży dziś więcej niż przed zmianą (większe zdjęcie w nagłówku) i to jest następna poprawka. Wyniki w wyszukiwarce po przełączeniu mierzę przez 30 dni i dopiszę je tutaj pod koniec października 2026.

Kiedy to podejście pasuje

Pliki statyczne sprawdzają się tam, gdzie treść jest taka sama dla każdego odwiedzającego: blog, serwis poradnikowy, strona firmowa. W sklepie koszyk, konto klienta i stan magazynu muszą zostać dynamiczne, więc zysk nie przenosi się jeden do jednego. Sklep zbudowany od podstaw jako headless opisuję w case study Suavius Atelier.