survivalism.pl

Mój własny 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.

Hosting: niższe wymagania, większy wybór

Czytelnik dostaje gotowe pliki, więc strona publiczna nie potrzebuje PHP ani bazy danych: wystarcza jej hosting samych plików, a większy ruch nie wymaga mocniejszego serwera. WordPress obsługuje już tylko redakcję, więc i jemu wystarcza najmniejszy plan.

Przy jednym redaktorze można pójść dalej: WordPress działa na jego komputerze, z kopią bazy poza nim, a w internecie zostają same pliki. Tak survivalism.pl działał w pierwszej dobie po przełączeniu, a dziś to jego droga zapasowa.

Formularze działają tu jako małe skrypty PHP na tym samym hostingu; na hostingu samych plików przejmuje je zewnętrzna usługa formularzy. Przekierowania, od których zależy ruch z wyszukiwarki, przenoszę wtedy do ustawień nowego hostingu.

survivalism.pl został na dotychczasowym hostingu, bo to samo konto utrzymuje inne serwisy, więc tej oszczędności tu nie mierzyłem. Liczy się tam, gdzie hosting jest opłacany dla jednej strony albo za ruch płaci się wyższym planem: wystarcza wtedy niższy plan, a przy redaktorze pracującym na własnym komputerze nawet bezpłatny hosting samych plików.

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.