Strony HTML-first znowu wygrywają w 2026

W skrócie: HTML-first oznacza, że strona najpierw wysyła gotową treść jako HTML renderowany na serwerze, a JavaScript dochodzi tylko tam, gdzie realnie pomaga. W 2026 to podejście znowu wygrywa, i nie z sentymentu. Mediana strony mobilnej dźwiga dziś około 646 KB JavaScriptu, mniej niż połowa stron mobilnych przechodzi Core Web Vitals, a przeglądarka robi natywnie wiele rzeczy, do których firmy wciąż doklejają wtyczki. Dla większości stron firmowych lekki kod jest szybszy, tańszy i prostszy w utrzymaniu.

Zacznę od tego, co widzę najczęściej u polskich klientów. Firma ma stronę na WordPressie, do tego kilkanaście wtyczek, motyw premium i konstruktor stron. Wszystko razem ładuje się wolno, zwłaszcza na telefonie, a każda zmiana to ryzyko, że coś innego przestanie działać. To nie jest wina właściciela. To domyślny wybór, który przez lata wszyscy w Polsce podsuwali małym firmom.

W 2026 ten domyślny wybór coraz częściej przegrywa z czymś prostszym.

Dlaczego Twoja strona WordPress ładuje się wolno

Najczęstsza przyczyna jest prozaiczna: nadmiar. Wtyczka do formularza, wtyczka do galerii, wtyczka do ciasteczek, konstruktor strony, a każda z nich dokłada swój JavaScript i swoje style. Przeglądarka musi to wszystko pobrać i wykonać, zanim strona zacznie reagować na dotyk.

To nie jest atak na WordPressa jako taki. To problem warstwy, którą zwykle się na nim buduje. Strona, która miała być zwykłą wizytówką, zaczyna zachowywać się jak mały system operacyjny.

Czym jest lekka strona HTML-first i dlaczego jest szybsza

Najszybszy sposób, żeby to źle zrozumieć, to wyobrazić sobie strony z 2009 roku. To nie o to chodzi.

HTML-first to kolejność działań. Najpierw budujesz stronę, która jest kompletna i czytelna jako HTML z serwera, a dopiero potem ją wzbogacasz. Treść jest widoczna, zanim załaduje się jakikolwiek skrypt. Formularz wysyła się nawet wtedy, gdy JavaScript nie dojedzie. To stara idea progresywnego ulepszania, stosowana dziś świadomie i nowoczesnymi narzędziami.

Nie chodzi o to, żeby zakazać JavaScriptu. Chodzi o to, żeby przestać traktować go jako domyślny materiał na każdą stronę.

Liczby z 2026: JavaScriptu jest coraz więcej

Tu zaczyna się część, która z preferencji programisty robi problem biznesowy.

Web Almanac 2025, opublikowany w styczniu 2026, podaje, że mediana strony mobilnej to około 646 KB JavaScriptu. To nie jest ciężki koniec, to środek. Każdy z tych bajtów trzeba pobrać, sparsować, skompilować i wykonać na głównym wątku, a dopóki ten wątek jest zajęty, strona nie reaguje na użytkownika.

Rozdział o wydajności tej samej edycji jest jeszcze bardziej dosadny. Tylko około 48% stron mobilnych przechodzi wszystkie trzy Core Web Vitals, a mediana czasu blokowania na telefonie wyraźnie wzrosła rok do roku. Te wskaźniki to nie teoria. Od końca 2025 LCP i INP są już standardem we wszystkich przeglądarkach, więc wolna, przeładowana skryptami strona jest mierzona i karana tak samo wszędzie.

W Polsce ma to dodatkowy ciężar. Ruch mobilny dominuje, a to właśnie na telefonie ciężki JavaScript boli najbardziej. Twój klient z Częstochowy czy ze Śląska najpewniej ogląda stronę na telefonie w autobusie, a nie na szybkim łączu w biurze.

Co przeglądarka robi dziś bez JavaScriptu

Druga połowa historii to fakt, jak bardzo dorosła sama platforma. Sporo interaktywności, która kiedyś wymagała biblioteki, jest dziś wbudowane w przeglądarkę.

Elementy <details> i <dialog> są już szeroko dostępne, a strony MDN o nich były aktualizowane w kwietniu 2026, więc to teraźniejszość, a nie obietnica na przyszłość. Kiedy akordeon, okno modalne i formularz działają bez paczki kodu, pytanie przestaje brzmieć "która biblioteka", a zaczyna "czy w ogóle potrzebuję biblioteki".

Dla wielu stron uczciwa odpowiedź brzmi: nie.

Strona statyczna HTML vs WordPress: kiedy co ma sens

Nie twierdzę, że każdy projekt ma wrócić do plików statycznych. Jeśli buduję coś z rozbudowanym stanem po stronie klienta, współpracą na żywo czy realnie aplikacyjnym przepływem, JavaScript zarabia na swoje miejsce i sięgam po niego bez wahania.

Tylko ten wybór nie jest już automatyczny. Mniej więcej tak go dzielę:

• Lekka strona HTML-first, gdy projekt to głównie treść: strony firmowe, wizytówki, strony usług, blogi, większość katalogów sklepowych i wiele narzędzi wewnętrznych. Zadaniem jest pokazać informację i złapać kontakt albo sprzedaż.
• Framework lub WordPress z głową, gdy interfejs jest produktem albo gdy klient naprawdę potrzebuje konkretnego ekosystemu wtyczek i sam będzie zarządzał treścią na co dzień.

Większość stron firmowych to ten pierwszy przypadek. A budowane były jak ten drugi i płaciły za to czasem ładowania.

Zanim zamówisz stronę: o co zapytać wykonawcę

Nie musisz znać się na kodzie, żeby zadać dobre pytania. Wystarczy kilka, które szybko pokażą, czy dostaniesz lekką stronę, czy kolejny ciężki szablon z wtyczkami.

• Ile JavaScriptu załaduje strona na telefonie i czy treść jest widoczna, zanim skrypty się wykonają?
• Czy strona jest renderowana na serwerze, czy dopiero JavaScript w przeglądarce buduje treść?
• Ile wtyczek będzie wymagało regularnej aktualizacji i kto będzie za nie odpowiadał?
• Jak wygląda wynik w Core Web Vitals na urządzeniu mobilnym, na konkretnym przykładzie?

Jeśli wykonawca nie potrafi odpowiedzieć na te pytania, to też jest odpowiedź. Dobra strona firmowa nie musi być skomplikowana. Musi być szybka, czytelna dla Google i prosta do zmiany, gdy zmienia się Twoja oferta.

Co to znaczy dla polskiej firmy

Najprościej: nie musisz płacić za wolną stronę tylko dlatego, że "wszyscy robią na WordPressie". Lekka, renderowana na serwerze strona w podobnym budżecie potrafi być szybsza, lepiej oceniana przez Google i tańsza w utrzymaniu, bo nie ma w niej dziesięciu wtyczek, które trzeba aktualizować i które potrafią się wzajemnie psuć.

To samo podejście stosuję, robiąc strony internetowe dla polskich firm. Renderuję strony na serwerze, korzystam z natywnego HTML do interakcji i dokładam tylko te skrypty, które realnie poprawiają doświadczenie. Po starcie najwięcej zyskuje klient: gdy chce zmienić cenę, dodać usługę albo poprawić formularz, edytuję czysty szablon, a nie odkopuję build i błąd hydracji na stronie, która nigdy tego nie potrzebowała.

Pisałem już, że mała firma nie potrzebuje drogiej, ciężkiej strony, żeby mieć dobrą stronę, i że czasem najlepszym ruchem jest prostsza, ludzka strona. HTML-first to praktyczna część tej samej korekty.

Więc tak, lekkie strony HTML znowu wygrywają, a 2026 to rok, w którym przestało to być niszową opinią. Są szybsze, tańsze w utrzymaniu i bardziej uczciwe wobec tego, czego projekt naprawdę potrzebuje. Jeśli potrzebna jest bogata interaktywność, dodam ją. Chcę tylko, żeby strona działała, zanim pojawi się cała reszta.

Jeśli tak wyobrażasz sobie swoją stronę, napisz do mnie.

Źródła: Web Almanac 2025: Page Weight, Web Almanac 2025: Performance, web.dev: LCP i INP są już standardem, Google Search Central: JavaScript SEO, MDN: progresywne ulepszanie.