[ARTYKUŁ W BUDOWIE]
Oficjalna aktualizacja dokumentacji Google z lutego 2026 r. jasno definiuje granice: Googlebot pobiera i przetwarza tylko pierwsze 2 MB pliku HTML, JS oraz CSS. Choć na pierwszy rzut oka limit ten wydaje się hojny, w rzeczywistości stanowi on rygorystyczne sito, które odsiewa serwisy nieefektywne technologicznie.
Pułapka „cichej truncacji” i mit kompresji
Dla wielu deweloperów najpoważniejszym zaskoczeniem jest fakt, że Googlebot operuje na danych niekompresowanych.
- Mechanizm działania: Jeśli Twój plik HTML po przesłaniu przez sieć (dzięki kompresji Brotli czy Gzip) waży 500 KB, ale po rozpakowaniu przez robota osiąga 2,5 MB – Googlebot „odcina” ostatnie 500 KB kodu.
- Brak ostrzeżeń: Testy wykazują, że Google Search Console często nie zgłasza błędów przy przekroczeniu limitu. Strona figuruje jako „Zindeksowana”, podczas gdy w rzeczywistości połowa jej zawartości, w tym kluczowe linki wewnętrzne czy dane strukturalne (Schema), może być dla algorytmów niewidoczna.
SEO vs GEO: AI nie lubi cyfrowego szumu
W świecie GEO (Generative Engine Optimization) optymalizacja pod 2 MB nabiera nowego wymiaru. Modele AI, takie jak Gemini, Perplexity czy ChatGPT, działają w oparciu o architekturę RAG (Retrieval-Augmented Generation). Oznacza to, że muszą błyskawicznie wyekstrahować sens z Twojej strony, by użyć go jako cytatu w odpowiedziach generatywnych.
- Czytelność maszynowa: Im mniej „śmieciowego” kodu otacza Twoją treść, tym większa szansa, że model AI poprawnie zinterpretuje kontekst i uzna Twoją stronę za wiarygodne źródło.
- Ryzyko „halucynacji”: Jeśli bot AI otrzyma tylko ucięty fragment strony (przez limit 2 MB), może błędnie zinterpretować ofertę firmy lub pominąć istotne zastrzeżenia, co bezpośrednio uderza w wizerunek marki.
Wyzwania dla systemów CMS: Od monolitów do mikro-zasobów
Zmiana ta wymusza na twórcach systemów CMS (Content Management Systems) odejście od dotychczasowych praktyk:
- Rozbicie monolitów: Platformy takie jak Wix czy Squarespace muszą wdrożyć technologię Code Splitting na szerszą skalę. Zamiast jednego, gigantycznego pliku JS, systemy te powinny serwować dziesiątki małych modułów, z których żaden nie zbliża się do granicy 2 MB.
- Server-Side Rendering (SSR): Kluczowe informacje muszą być renderowane po stronie serwera i dostarczane w pierwszych kilobajtach kodu HTML, a nie generowane dynamicznie przez ciężkie skrypty na samym końcu dokumentu.
Badanie wielkości plików wg. CMS
Google zmieniło zasady gry: ich boty skanują obecnie tylko pierwsze 2 MB pliku HTML, JS oraz CSS. Wszystko, co znajduje się poniżej tej granicy, jest dla wyszukiwarki nieistniejące. W kontekście tych zmian, nasze badanie 234 179 domen nabiera krytycznego znaczenia. Zderzyliśmy teorię o „nowoczesnych platformach” z brutalną rzeczywistością wagową internetu.
Średnia wielkość pliku HTML w całym badaniu to 284,55 KB, a średnia liczba plików JS na stronę wynosi 31,22. Choć średnie wydają się bezpieczne, ekstrema są alarmujące. Znaleźliśmy aż 1502 domeny, których plik HTML przekracza limit 2 MB. Absolutnym rekordzistą jest strona hanusia-rabka.pl (Joomla), serwująca plik HTML o wielkości ponad 60 MB.
Oto jak popularne systemy radzą sobie z „dietą”, której wymaga dzisiejsze SEO.
Jakie są ograniczenia tego badania?
Zanim przejdziemy do konkretów, musimy jasno określić ramy, w jakich się poruszaliśmy:
- Skanowane były tylko strony główne: Warto o tym pamiętać, gdyż strony kategorii czy rozbudowane listingi produktów w e-commerce mogą okazać się znacznie większe; nie jest to zatem ranking „ostateczny”.
- Głębokość analizy zasobów: Z racji ogromnej liczby skanów, pliki CSS oraz JS były sprawdzane tylko do poziomu 1 (bez głębokiego rekurencyjnego przeszukiwania wszystkich skryptów).
- Selekcja danych: Z podsumowania ostatecznego wykluczyliśmy witryny, których nie udało się przeskanować, oraz te z podejrzanie niską wielkością HTML; prawdopodobnie wiele „problematycznych” domen znajdowało się właśnie w odrzuconym segmencie.
Który CMS serwuje najcięższy fundament (HTML)?
Kod HTML to kręgosłup strony. Jeśli przekracza 2 MB, Googlebot „odcina” skanowanie, co może oznaczać, że Twoja treść czy meta tagi nigdy nie zostaną zaindeksowane. Wix jest tutaj systemowym liderem ryzyka – generuje kod średnio ponad 5-krotnie cięższy niż Webflow.
Czy Twój JavaScript to monolit czy rozproszona armia?
JavaScript najbardziej obciąża urządzenia mobilne. Squarespace stosuje ryzykowną strategię „monolitu”, serwując największy pojedynczy plik JS w zestawieniu (średnio 1,27 MB). WordPress z kolei serwuje rekordową liczbę plików, co zmusza przeglądarkę do dziesiątek zbędnych połączeń.
Ile waży „ładny wygląd” w arkuszach CSS?
Nadmiar stylów blokuje renderowanie strony. Choć pliki CSS rzadko przekraczają 2 MB, ich waga w przypadku platform e-commerce (Sky-Shop) i kreatorów wizualnych jest alarmująca. WordPress, mimo mniejszej średniej wagi pliku, posiada najwięcej domen przekraczających limit Google (23 sztuki).
Liczby zamiast obietnic: Czy Twój CMS przejdzie przez sito Google?
Dane z ponad 230 tysięcy domen obnażają strukturalne problemy najpopularniejszych systemów. Wybierając technologię, nie wybierasz tylko wyglądu panelu, ale konkretną architekturę danych, która może Cię wykluczyć z indeksu Google.
WordPress i pułapka „pluginozy”
WordPress to absolutny rekordzista pod względem liczby zasobów – serwuje średnio blisko 38 plików JavaScript oraz 18 plików CSS na każdą stronę główną. To podręcznikowy przykład „pluginozy”: każda wtyczka mająca poprawić UX lub SEO dodaje własne skrypty i style. Nawet jeśli pojedyncze pliki są małe, ich łączna liczba (średnio 55 zapytań na same style i skrypty) tworzy ogromny narzut komunikacyjny, który Googlebot musi przetworzyć.
Squarespace i Wix: Problem monolitycznego puchnięcia
Podczas gdy WordPress cierpi na rozdrobnienie, kreatory takie jak Squarespace i Wix stawiają na monolit. Wix serwuje niemal 1 MB kodu HTML na „dzień dobry”, co przy nowym limicie Google zostawia bardzo mało miejsca na realną treść strony. Z kolei Squarespace serwuje rekordowo ciężki plik JS (średnio 1272,82 KB), co w połączeniu z innymi zasobami sprawia, że niebezpiecznie zbliża się do granicy 2 MB, po której Google po prostu przestaje czytać kod.
Webflow: Jakość > Ilość
Wyniki Webflow pokazują, że nowoczesne podejście do generowania kodu działa. Średnio 159,54 KB HTML oraz tylko jedna domena przekraczająca limit 2 MB na 1453 przebadane to wynik deklasujący resztę stawki. To dowód na to, że da się budować wizualnie bez produkowania cyfrowych śmieci.
Podsumowanie
W 2026 roku waga strony przestała być tylko parametrem wpływającym na Core Web Vitals. Stała się kryterium kompletności indeksowania. Jeśli Twoja strona „waży” zbyt dużo, nie jest po prostu wolna – jest dla Google niekompletna.
