Strona nie ładuje CSS – instrukcja krok po kroku

Test po stronie przeglądarki

Strona nie ładuje CSS wtedy, gdy przeglądarka pobiera dokument HTML, ale nie stosuje arkusza stylów, co w praktyce oznacza widok bez układu, kolorów i responsywności. W diagnostyce najpierw sprawdź Chrome DevTools, HTTP 404 oraz Content-Type CSS, bo standard HTTP opisuje 5 klas statusów odpowiedzi od 1xx do 5xx, a błędny status lub nagłówek zwykle wystarcza do znalezienia przyczyny (źródło: RFC 9110, 2022).

Jak wykluczyć cache użytkownika?

Zacznij od testu, który nie zmienia profilu przeglądarki. Z mojej praktyki administracyjnej wynika, że kasowanie całego profilu Chrome lub Edge na początku diagnozy częściej ukrywa problem niż go naprawia, zwłaszcza gdy awaria dotyczy produkcji i widzą ją także inni użytkownicy.

1. Tryb incognito uruchamia sesję bez większości lokalnych ciasteczek i rozszerzeń, więc szybko pokazuje, czy problem powoduje zapisany stan przeglądarki.
2. Druga przeglądarka, na przykład Firefox zamiast Chrome, pozwala odróżnić błąd aplikacji od błędu konkretnego profilu lub rozszerzenia.
3. Twarde odświeżenie Ctrl+F5 wymusza ponowne pobranie HTML, CSS i JavaScript z pominięciem części lokalnego cache.
4. Ctrl+Shift+R w Chrome i Edge działa podobnie, ale test wykonuj na aktywnej karcie z badaną stroną.
5. Disable cache w DevTools działa tylko wtedy, gdy panel DevTools jest otwarty, więc nie traktuj tego jako czyszczenia CDN.
6. Inna sieć, na przykład hotspot LTE, wyklucza lokalny DNS, filtr firmowy, proxy lub cache operatora.

Czy problem może być tylko w Chrome?

Tak. CSS może nie ładować się tylko w Chrome przez rozszerzenie, uszkodzony Service Worker, agresywny cache albo politykę bezpieczeństwa. Jeżeli Edge i Firefox pokazują stronę poprawnie, a Chrome nie, skup się na profilu, rozszerzeniach i danych witryny, nie na deployu.

• Rozszerzenie blokujące zasoby może zatrzymać plik style.css, jeśli reguła filtra błędnie rozpozna go jako reklamę lub tracker.
• Service Worker może serwować stary plik HTML, który wskazuje nieistniejący plik CSS po nowym buildzie.
• Cache aplikacji PWA może trzymać poprzedni manifest assets, mimo że katalog dist na serwerze jest aktualny.
• Polityka CSP może zablokować arkusz stylów z zewnętrznej domeny, jeśli style-src nie obejmuje tego hosta.

Jak sprawdzić CSS na telefonie?

Najprostszy test mobilny to wejście na ten sam URL przez LTE i WiFi. Jeśli na telefonie przez LTE strona działa, a na komputerze w firmowej sieci nie, problemem może być DNS, proxy, filtr antywirusowy albo lokalny cache. Gdy błąd występuje na telefonie i desktopie, przejdź do diagnostyki Network.

„Element link z rel=stylesheet służy do połączenia dokumentu HTML z zewnętrznym arkuszem stylów; błędny href oznacza, że przeglądarka szuka CSS pod niewłaściwym adresem.” MDN Web Docs, HTML link element, 2024

Diagnostyka w DevTools Network

DevTools Network to panel diagnostyczny przeglądarki, charakteryzujący się listą żądań HTTP, statusem odpowiedzi, nagłówkami i czasem ładowania. Przy awarii CSS interesują cię głównie zakładki Network i Console w Chrome DevTools, Firefox DevTools albo Edge DevTools.

Gdzie sprawdzić, czy CSS się ładuje?

Otwórz stronę, naciśnij F12, przejdź do Network i odśwież widok. Następnie użyj filtra CSS albo pola wyszukiwania i wpisz nazwę pliku, na przykład style.css, app.css, main.css, index.css albo nazwę z hashem typu assets/index-8f3a2c.css.

1. Otwórz Network przed odświeżeniem, ponieważ panel musi zarejestrować żądania od początku ładowania strony.
2. Zaznacz Preserve log, jeśli po wejściu następuje przekierowanie z HTTP na HTTPS lub z domeny bez www na domenę z www.
3. Włącz Disable cache, aby lokalny cache nie maskował błędu w produkcyjnym pliku CSS.
4. Użyj filtra CSS, ponieważ na dużych stronach WordPress lista żądań może mieć ponad 100 pozycji.
5. Kliknij plik CSS i sprawdź zakładki Headers, Preview oraz Response, bo tam widać status, MIME type i faktyczną treść odpowiedzi.
6. Porównaj rozmiar odpowiedzi, bo plik CSS o rozmiarze 0 B albo kilkaset bajtów często oznacza stronę błędu zamiast arkusza stylów.

Co oznacza CSS z odpowiedzią HTML?

Jeżeli w Response widzisz kod zaczynający się od doctype, div, komunikatu logowania albo strony 404, to przeglądarka nie dostała prawdziwego CSS. Typowy przypadek: aplikacja React lub Vite ma zły base path i serwer oddaje index.html dla adresu assets/index.css.

Objaw w Network	Najczęstsza przyczyna	Bezpieczna naprawa
200 OK, ale Response zawiera HTML	Routing fallback oddaje index.html dla pliku CSS.	Popraw konfigurację statycznych assets i wyklucz katalog assets z fallbacku SPA.
404 przy assets/index.css	HTML wskazuje plik, którego nie ma w katalogu dist.	Wgraj pełny build albo usuń stary HTML z cache CDN.
403 przy style.css	Serwer blokuje odczyt pliku lub katalogu.	Sprawdź uprawnienia pliku i reguły .htaccess, Nginx albo WAF.
Mixed Content w Console	Strona HTTPS próbuje ładować CSS przez HTTP.	Zmień URL assetu na HTTPS albo ścieżkę względną.
MIME type text/html	Serwer zwraca HTML lub ma złą mapę typów MIME.	Ustaw Content-Type: text/css dla plików .css.

Jak odczytać błędy w konsoli?

Console dopowiada to, czego nie widać od razu w tabeli Network. Szukaj komunikatów o MIME type stylesheet, Mixed Content, CORS, CSP oraz odmowie ładowania zasobu. Link DevTools Network krok po kroku warto mieć jako procedurę dla osób, które dopiero zaczynają pracę z tym panelem.

• Refused to apply style oznacza zwykle błędny MIME type albo HTML zwrócony zamiast CSS.
• Mixed Content oznacza blokadę zasobu HTTP na stronie działającej przez HTTPS.
• Content Security Policy oznacza, że nagłówek CSP nie pozwala ładować stylów z danej domeny.
• CORS przy CSS występuje rzadziej, ale pojawia się przy fontach, importach i zasobach z CDN.
• net::ERR_ABORTED może oznaczać anulowanie żądania po przekierowaniu, błędnym typie lub zmianie strony.

Status HTTP i treść odpowiedzi CSS

Status HTTP dla CSS to kod odpowiedzi serwera, charakteryzujący się klasą błędu, informacją o cache i wskazówką, czy problem jest po stronie ścieżki, dostępu, serwera czy przeglądarki. Najważniejsze kody przy CSS to 200, 304, 403, 404, 500 i canceled.

Jak czytać 200, 304, 404, 403 i 500?

Nie wystarczy zobaczyć zielonego 200. Status 200 mówi, że serwer coś zwrócił, ale nie gwarantuje, że jest to CSS. Dlatego po statusie zawsze sprawdź Content-Type i Response.

• 200 OK jest poprawny tylko wtedy, gdy Response zawiera reguły CSS, a nagłówek Content-Type ma wartość text/css.
• 304 Not Modified oznacza, że przeglądarka używa kopii z cache, więc do testu włącz Disable cache i odśwież stronę.
• 404 Not Found oznacza złą ścieżkę, usunięty plik, niepełny deploy albo HTML wskazujący poprzedni hash pliku.
• 403 Forbidden oznacza blokadę dostępu, często przez uprawnienia pliku, reguły serwera, WAF albo błędną konfigurację katalogu.
• 500 Internal Server Error oznacza problem po stronie aplikacji lub serwera, szczególnie gdy CSS jest generowany dynamicznie.
• Canceled oznacza anulowane żądanie, które trzeba sprawdzić razem z przekierowaniami, Service Workerem i logiem Console.

Kiedy status 304 jest problemem?

Sam status 304 nie jest błędem. Problem zaczyna się wtedy, gdy przeglądarka używa starego CSS, a HTML albo aplikacja oczekuje nowej wersji. Przy plikach z hashem, na przykład index-a1b2c3.css, stary HTML może wskazywać plik usunięty z serwera po deployu.

1. Sprawdź HTML i odczytaj dokładny adres CSS wpisany w tagu link rel stylesheet.
2. Porównaj adres z katalogiem dist, ponieważ Vite generuje nazwy z hashem zależnym od zawartości pliku.
3. Wyczyść cache HTML, bo stary dokument może wskazywać nieaktualny manifest assets.
4. Nie usuwaj nowych plików, dopóki nie potwierdzisz, że CDN i przeglądarka przestały odwoływać się do poprzednich nazw.

Co sprawdzić w Headers?

W Headers sprawdź Request URL, Status Code, Content-Type, cache-control, location i ewentualne przekierowania. Jeśli Request URL ma zły katalog, naprawiasz link lub base path. Jeśli URL jest poprawny, ale Content-Type nie jest text/css, przechodzisz do konfiguracji MIME.

„Przeglądarki używają typu MIME do ustalenia, jak przetworzyć zasób; CSS powinien być zwracany jako text/css, a nie text/html lub text/plain.” MDN Web Docs, MIME types, 2024

Naprawa ścieżek, HTTPS i nagłówków

Naprawa ścieżki CSS to korekta adresu, pod którym HTML wskazuje arkusz stylów, charakteryzująca się zgodnością href, katalogu produkcyjnego i konfiguracji serwera. W praktyce osobno sprawdzasz statyczny HTML, Vite, React i WordPress, bo każdy z tych stosów psuje CSS w innym miejscu.

Jak naprawić złą ścieżkę CSS w HTML?

W statycznym HTML zacznij od tagu link. Poprawny zapis zwykle wygląda jak link rel=”stylesheet” z href prowadzącym do istniejącego pliku. Jeśli strona działa w katalogu podrzędnym, na przykład /blog/, ścieżka zaczynająca się od /assets może wskazywać zły katalog na serwerze.

1. Sprawdź href w link rel stylesheet, ponieważ literówka w nazwie style.css daje natychmiastowy status 404 CSS.
2. Użyj ścieżki względnej, na przykład ./style.css, gdy plik HTML i CSS leżą w tym samym katalogu.
3. Użyj ścieżki absolutnej, na przykład /assets/app.css, gdy aplikacja zawsze działa od korzenia domeny.
4. Nie mieszaj katalogów, jeśli build zapisuje pliki do dist/assets, a serwer publikuje katalog public.
5. Sprawdź wielkość liter, bo Linux rozróżnia Style.css i style.css, a Windows lokalnie często maskuje ten błąd.

Jak sprawdzić base path Vite i public path React?

Vite używa opcji base do wygenerowania adresów assets w produkcyjnym HTML. Jeżeli aplikacja jest wdrożona pod /panel/, a build zakłada /, CSS może ładować się z nieistniejącego adresu. W React problem zwykle dotyczy public path, homepage w package.json albo konfiguracji hostingu.

• Vite base powinien odpowiadać katalogowi publikacji, na przykład base: „/panel/” dla aplikacji pod adresem domena.pl/panel/.
• Katalog dist musi zostać wgrany w całości, łącznie z index.html, assets i plikami manifestu.
• React build musi wskazywać poprawny public URL, jeśli aplikacja nie działa z korzenia domeny.
• Fallback SPA powinien obsługiwać trasy aplikacji, ale nie powinien przechwytywać prawdziwych plików .css.
• Manifest assets musi pasować do HTML, bo stary index.html z nowym katalogiem assets daje błędy 404.

Jak naprawić WordPress, wp_enqueue_style i minifikację?

W WordPressie nie edytuj ręcznie plików motywu na produkcji bez kopii. Najpierw wyłącz minifikację CSS, łączenie plików i odroczone ładowanie wtyczki cache. Potem sprawdź, czy motyw poprawnie używa wp_enqueue_style, a nie sztywnych linków do starego katalogu.

• wp_enqueue_style powinien wskazywać aktualny URI motywu lub motywu potomnego, a nie ręcznie wpisaną domenę testową.
• Wtyczka cache, na przykład LiteSpeed Cache, WP Rocket albo Autoptimize, może podawać połączony plik CSS, którego już nie ma.
• Motyw potomny może nadpisywać style rodzica i powodować konflikt wersji po aktualizacji motywu.
• Minifikacja CSS powinna być wyłączona na czas diagnostyki, bo utrudnia odczyt konkretnego pliku z błędem.
• Regeneracja critical CSS jest potrzebna, jeśli wtyczka generuje osobne style dla mobile i desktop.

Dla tego scenariusza dobrym punktem kontrolnym jest WordPress cache i minifikacja CSS, bo łączy objawy z typowymi ustawieniami wtyczek.

Jak naprawić Mixed Content i MIME type?

Mixed Content po migracji HTTPS oznacza, że dokument HTTPS próbuje pobrać CSS przez HTTP. Przeglądarki blokują aktywne lub wrażliwe zasoby mieszane, dlatego po migracji certyfikatu popraw adresy w bazie, konfiguracji motywu, CDN i zmiennych środowiskowych.

1. Zmień http:// na https:// w adresach CSS, fontów, CDN i importów wewnątrz arkuszy stylów.
2. Użyj ścieżek względnych, gdy asset jest serwowany z tej samej domeny i nie wymaga osobnego hosta.
3. Wyczyść cache aplikacji, ponieważ stary HTML może nadal zawierać link do HTTP.
4. Ustaw Content-Type: text/css dla rozszerzenia .css w konfiguracji Apache, Nginx, IIS albo hostingu.
5. Sprawdź błędną odpowiedź HTML, bo komunikat MIME często wynika z tego, że serwer zwraca stronę 404 jako text/html.

Jeśli głównym komunikatem jest MIME type stylesheet, przejdź do procedury jak naprawić MIME type CSS, bo tam diagnoza zaczyna się od nagłówka Content-Type, a nie od wyglądu strony.

Cache, CDN i potwierdzenie naprawy

Cache CDN to warstwa pośrednia między użytkownikiem a serwerem, charakteryzująca się przechowywaniem HTML, CSS, JavaScript i obrazów w wielu lokalizacjach brzegowych. Przy awarii CSS najgroźniejszy jest stary HTML wskazujący nowy lub usunięty plik assets.

Kiedy czyścić CDN?

CDN czyść dopiero po potwierdzeniu, że plik na serwerze jest poprawny. Purge cache wykonany zbyt wcześnie utrudnia diagnozę, bo miesza objawy z różnych warstw. W przypadkach, które prowadziłem przy deployach Vite i WordPress, najczęściej wystarczało wyczyścić HTML, manifest i połączone pliki CSS, nie cały CDN.

• Purge HTML wykonaj, gdy index.html lub strona WordPress wskazuje stary plik z hashem.
• Purge CSS wykonaj, gdy CDN zwraca stary arkusz mimo poprawnego pliku na serwerze.
• Purge manifestu assets wykonaj przy aplikacjach, które używają manifest.json lub podobnego pliku mapującego build.
• Purge wtyczki WordPress wykonaj po zmianie ustawień minifikacji, łączenia CSS albo critical CSS.
• Purge DNS nie pomaga, jeśli problemem jest status 404 CSS albo błędny Content-Type na istniejącym pliku.

Jak potwierdzić, że CSS działa?

Potwierdzenie musi obejmować przeglądarkę bez cache, produkcyjny URL i urządzenie mobilne. Nie opieraj się tylko na tym, że strona wygląda dobrze na twoim komputerze po zalogowaniu do panelu administracyjnego.

1. Otwórz produkcyjny adres w incognito i sprawdź, czy layout, fonty, menu i responsywność wyglądają poprawnie.
2. Włącz DevTools Network, zaznacz Disable cache i odśwież stronę skrótem Ctrl+Shift+R.
3. Sprawdź wszystkie pliki CSS, aby każdy miał status 200 lub uzasadnione 304 oraz Content-Type text/css.
4. Przejdź do Console i upewnij się, że nie ma błędów MIME type, Mixed Content, CSP ani 404 dla fontów.
5. Przetestuj mobile przez WiFi i LTE, bo układ mobilny często ładuje dodatkowe style lub osobny critical CSS.
6. Zapisz przyczynę, na przykład zły base path Vite albo cache CDN, żeby poprawić checklistę kolejnego deployu.

Co sprawdzić po kolejnym deployu?

Po kolejnym wdrożeniu porównaj nazwę pliku CSS w HTML z plikami obecnymi na serwerze. Jeśli używasz hashy, nie usuwaj poprzedniej paczki assets natychmiast po deployu, gdy CDN może jeszcze przez chwilę podawać starszy HTML.

• Nowy HTML powinien wskazywać aktualny hash pliku CSS z katalogu produkcyjnego.
• Stary HTML nie powinien wskazywać pliku usuniętego z serwera przed wygaśnięciem cache.
• Service Worker powinien dostać nową wersję cache i nie może serwować starego shell app.
• Monitoring 404 powinien pokazywać, czy użytkownicy nadal odpytują usunięte pliki CSS.
• Rollback powinien obejmować HTML i assets z tej samej wersji, nie tylko sam plik index.html.

„Panel Network pozwala sprawdzać żądania, odpowiedzi, nagłówki, timing oraz cache, dlatego jest podstawowym miejscem diagnozy problemów z ładowaniem zasobów.” Chrome DevTools Documentation, Network panel, 2024

Szybka lista napraw według objawu

Lista objawów CSS to praktyczna mapa decyzji, charakteryzująca się połączeniem komunikatu z DevTools, prawdopodobnej przyczyny i pierwszej bezpiecznej akcji. Użyj jej, gdy potrzebujesz skrócić diagnostykę do kilku minut.

Jak dobrać naprawę do komunikatu?

• Strona wygląda jak czysty HTML oznacza, że główny arkusz stylów nie został zastosowany, więc najpierw sprawdź Network i status pliku CSS.
• Status 404 CSS oznacza brak pliku pod wskazanym adresem, więc napraw href, base path Vite, public path React albo kompletność deployu.
• Status 403 style.css oznacza blokadę dostępu, więc sprawdź uprawnienia pliku, reguły WAF, .htaccess, Nginx albo politykę hostingu.
• MIME type text/html oznacza najczęściej stronę błędu zamiast CSS, więc otwórz Response i sprawdź, co naprawdę zwraca serwer.
• Mixed Content naprawa wymaga zmiany adresów HTTP na HTTPS oraz wyczyszczenia cache HTML i CDN.
• CSS działa lokalnie, ale nie na produkcji wskazuje na różnicę w base URL, katalogu dist, zmiennych środowiskowych albo cache CDN.

Kiedy nie ruszać konfiguracji serwera?

Nie zmieniaj od razu Nginx, Apache ani IIS, jeśli DevTools pokazuje, że HTML wskazuje nieistniejący plik. Konfigurację serwera poprawiaj dopiero wtedy, gdy URL jest prawidłowy, plik istnieje, a problemem pozostaje nagłówek, dostęp albo przekierowanie.

1. Najpierw potwierdź URL, bo błędna ścieżka jest częstsza niż zła mapa MIME na hostingu.
2. Potem potwierdź plik, sprawdzając, czy CSS rzeczywiście znajduje się w katalogu publikowanym przez serwer.
3. Następnie potwierdź nagłówki, szczególnie Content-Type, cache-control i location.
4. Na końcu zmieniaj serwer, zaczynając od minimalnej korekty dla rozszerzenia .css lub katalogu assets.

Jak bezpiecznie pracować na produkcji?

Przed zmianą konfiguracji zrób kopię pliku .htaccess, konfiguracji Nginx, ustawień CDN lub wtyczki cache. Nie czyść całego cache i nie usuwaj katalogu assets bez planu powrotu, bo możesz pogorszyć sytuację dla użytkowników, którzy mają jeszcze stary HTML.

• Kopia konfiguracji pozwala wrócić do poprzedniego stanu po nieudanej zmianie serwera.
• Mała zmiana jest łatwiejsza do potwierdzenia niż jednoczesna edycja CDN, aplikacji i wtyczki cache.
• Okno wdrożeniowe ogranicza wpływ błędu na użytkowników, szczególnie w sklepach i panelach klientów.
• Log zmian ułatwia znalezienie przyczyny, jeśli po kilku godzinach CDN zacznie podawać inną wersję plików.

Jeżeli dopiero rozpoznajesz objaw, zacznij od definicji Strona nie ładuje CSS co oznacza, a dopiero potem przechodź do zmian w konfiguracji.

Najczęściej zadawane pytania

Jak najszybciej sprawdzić, czemu CSS się nie ładuje?

Otwórz DevTools, przejdź do Network, odśwież stronę i przefiltruj zasoby CSS. Status HTTP, nagłówek Content-Type i treść odpowiedzi zwykle wskazują przyczynę. Jeśli Response zawiera HTML, problemem jest ścieżka, routing albo strona błędu zwrócona zamiast arkusza stylów.

Co oznacza status 404 przy pliku CSS?

Status 404 oznacza, że przeglądarka szuka CSS pod adresem, którego serwer nie znajduje. Najczęściej winny jest błędny href, zły base path Vite, niepełny katalog dist albo stary HTML w cache CDN. Naprawę zacznij od porównania adresu z DevTools z realnymi plikami na serwerze.

Jak naprawić CSS blokowany przez Mixed Content?

Zmień adres CSS z HTTP na HTTPS albo użyj ścieżki względnej, jeśli plik jest na tej samej domenie. Potem wyczyść cache aplikacji, WordPressa i CDN, bo stary HTML może nadal wskazywać niebezpieczny adres. Sprawdź też importy wewnątrz CSS, bo fonty i obrazy tła mogą nadal ładować się przez HTTP.

Czy DevTools Disable cache wystarczy?

Disable cache wystarczy do testu w konkretnej karcie przeglądarki, gdy DevTools są otwarte. Nie czyści jednak CDN, cache serwera, Service Workera ani cache wtyczki WordPress. Dlatego po diagnozie i poprawce trzeba osobno wykonać purge właściwej warstwy.

Dlaczego CSS działa lokalnie, ale nie na produkcji?

Lokalnie aplikacja często działa z korzenia domeny i ma inny tryb serwowania plików niż produkcja. Na produkcji problemem bywa base path, brak skopiowanych assets, nieaktualny manifest, konfiguracja CDN albo Linux rozróżniający wielkość liter w nazwach plików. Porównaj lokalny build z plikami faktycznie opublikowanymi na serwerze.

Dlaczego przeglądarka pokazuje MIME type error dla CSS?

Błąd MIME type oznacza, że odpowiedź nie została rozpoznana jako prawidłowy arkusz stylów. Najczęściej serwer zwraca text/html, bo pod adresem CSS znajduje się strona 404, ekran logowania albo fallback aplikacji SPA. Popraw URL lub konfigurację serwera tak, aby pliki .css były zwracane z Content-Type: text/css.

Czy można naprawić CSS bez dostępu do serwera?

Możesz potwierdzić przyczynę w DevTools bez dostępu do serwera, ale trwała naprawa zwykle wymaga zmiany plików, konfiguracji aplikacji, WordPressa albo CDN. Wyjątkiem jest problem lokalny po stronie użytkownika, na przykład cache, rozszerzenie lub uszkodzony profil przeglądarki. Dlatego najpierw ustal, czy błąd widzą wszyscy, czy tylko jedna osoba.

Źródła i literatura

1. MDN Web Docs, The link element, dokumentacja poprawnego podłączania arkuszy stylów CSS w HTML, 2024.
2. MDN Web Docs, MIME types, dokumentacja typów MIME i nagłówka Content-Type dla zasobów HTTP, 2024.
3. Chrome for Developers, Chrome DevTools Documentation, dokumentacja paneli Network i Console, 2024.
4. IETF, RFC 9110: HTTP Semantics, opis statusów HTTP, nagłówków i semantyki odpowiedzi, 2022.
5. Vite Documentation, Shared Options: base, opis konfiguracji ścieżki bazowej dla produkcyjnych assets, 2024.