W 2026 roku tryb ciemny przestał być „gadżetem dla deweloperów”. Badania użycia pokazują, że od 60 do 80 % użytkowników włącza tryb ciemny w systemie przynajmniej przez część dnia. iOS przełącza się automatycznie wieczorem wraz z True Tone, macOS i Windows mają własne ustawienia automatycznej jasności, a zaawansowani użytkownicy trzymają go włączonego na stałe, żeby ograniczyć zmęczenie wzroku. Sklep, który nie oferuje trybu ciemnego, nie odpowiada już oczekiwaniom UX roku 2026 i wysyła odwiedzającym agresywny biały błysk przy każdym ładowaniu strony, szczególnie dokuczliwy wieczorem i na urządzeniach mobilnych.
Shopware 6.7 nie oferuje natywnego trybu ciemnego po stronie storefrontu. Ten brak nie jest błahy: czyste wdrożenie wymaga ogarnięcia kilku zagadnień technicznych (anti-FOUC, trwałość między urządzeniami, zgodność z Bootstrapem, synchronizacja z innymi komponentami), które rzadko są dobrze zrobione bez dedykowanej wtyczki. Ten przewodnik szczegółowo omawia, jak wdrożyć kompletny i wydajny tryb ciemny w Shopware 6.7, wraz z pułapkami technicznymi do uniknięcia.
Dlaczego tryb ciemny stał się standardem UX w 2026 roku
Trzy siły sprawiły, że tryb ciemny stał się oczekiwaniem, a nie bonusem.
Użycie systemowe się upowszechniło. Od czasu iOS 13 (2019) i macOS Mojave (2018) systemowy tryb ciemny przeszedł z niszy do mainstreamu. Statystyki z 2025 roku wskazują, że 80 % użytkowników iOS i 65 % użytkowników Androida włączyło tryb ciemny przynajmniej okazjonalnie, a 35 % trzyma go na stałe. Na desktopie jest to trochę mniej (od 40 do 50 %), ale wskaźnik stale rośnie.
Zmęczenie wzroku to uznany temat zdrowotny. Kilka badań (w tym publikowanych przez American Academy of Ophthalmology) udokumentowało wpływ jasnej bieli w porze nocnej na jakość snu i zmęczenie oczu. Tryb ciemny przestał być preferencją estetyczną. To praktyka komfortu wpisana w cyfrowe rutyny użytkowników wrażliwych na te kwestie.
Oczekiwania UX się wyrównały. Wielkie platformy (X, Reddit, GitHub, Notion, Linear, Slack, Discord) oferują dopracowany tryb ciemny. Użytkownicy przyzwyczajają się, że mogą przełączyć na ciemny w dowolnym interfejsie, i negatywnie postrzegają witryny, które za tym nie nadążają. Dla sklepu internetowego to subtelny, ale realny sygnał jakości, szczególnie w segmentach technologicznych, kreatywnych i młodych, gdzie tryb ciemny jest niemal normą plemienną.
Zaległość Shopware w tym punkcie nie jest krytyczna w wartościach bezwzględnych (platforma pozostaje solidna w swoich fundamentach), ale zostawia sklepy bez funkcji, której nowocześni sprzedawcy oczekują. Zasypanie tej luki w czysty sposób daje zysk na trzech osiach: komfort użytkownika, postrzegany sygnał jakości oraz uznanie wśród odbiorców wrażliwych na nowoczesny UX.
Pułapka białego błysku (FOUC) i dlaczego dyskwalifikuje pod względem UX
FOUC oznacza „Flash of Unstyled Content”, a w odniesieniu do trybu ciemnego to krótki biały błysk widoczny, zanim JavaScript trybu ciemnego zdąży się wykonać i zastosować ciemny motyw. U odwiedzającego, który ustawił system w trybie ciemnym, ten błysk trwa zwykle od 100 do 400 milisekund przy pierwszym ładowaniu strony, czyli dokładnie tyle, ile człowiek potrzebuje, żeby dostrzec niespójność wizualną.
Dlaczego to dyskwalifikuje:
Poznawczo błysk sygnalizuje błąd. Ludzki mózg interpretuje gwałtowne zmiany wizualne jako anomalie. Strona, która startuje na biało, a potem przechodzi w ciemny, wygląda na wadliwą, nawet jeśli wynik końcowy jest poprawny. To odwrotność tego, do czego dążymy w UX klasy premium.
Na urządzeniach mobilnych jest to fizycznie nieprzyjemne. W użyciu nocnym (czyli wtedy, gdy tryb ciemny jest najbardziej potrzebny) błysk 300 ms pełnej białej jasności odbierany jest jak agresja wizualna. Użytkownicy postrzegają witrynę jako „niepoważną” i często zamykają kartę bez świadomego powodu.
Po stronie Core Web Vitals psuje to odczuwane LCP. LCP (Largest Contentful Paint) mierzy moment wyrenderowania największego widocznego elementu. Jeśli Twoje LCP wynosi 1,8 s, ale biały błysk dokłada kolejne 300 ms, użytkownik odczuwa w rzeczywistości 2,1 s ładowania, a jego wrażenie jakości witryny się pogarsza.
Techniczna przyczyna FOUC jest znana: większość wtyczek trybu ciemnego stosuje motyw przez JavaScript w zdarzeniu DOMContentLoaded, które uruchamia się po pierwszym malowaniu przeglądarki. Kolejność wygląda więc tak: (1) HTML jest renderowany domyślnie w trybie jasnym, (2) przeglądarka wykonuje pierwsze malowanie, (3) uruchamia się DOMContentLoaded, (4) JS stosuje ciemny motyw, (5) przeglądarka maluje ponownie. Między krokiem 2 a 5 mamy biały błysk.
Rozwiązanie jest równie znane: wstrzyknąć minimalistyczny skrypt inline bezpośrednio w sekcji head, który odczytuje cookie z preferencją (synchronicznie, około 10 linii JS) i ustawia atrybut data-bs-theme na elemencie głównym strony przed pierwszym malowaniem przeglądarki. To rozwiązanie rzadko bywa jednak poprawnie wdrożone w Shopware, bo wymaga modyfikacji bazowego layoutu Twig o skrypt inline, czego niewielu deweloperów robi naturalnie.
Architektura czystego trybu ciemnego w Shopware 6.7
Kompletny i wydajny tryb ciemny opiera się na pięciu komponentach, które muszą ze sobą współpracować.
Konwencja CSS obsługiwana przez Twój motyw. Bootstrap 5.3 wprowadził data-bs-theme="dark" jako konwencję standardową i większość motywów Shopware 6.7 opartych na Bootstrapie ją stosuje. Starsze motywy albo motywy na zamówienie mogą używać klasy .dark na elemencie html albo body. Przede wszystkim sprawdź, jakiej konwencji używa Twój motyw, bo to ona decyduje, gdzie tryb ciemny zostanie zastosowany.
Skrypt anti-FOUC na początku sekcji head. Ten skrypt odczytuje preferencję odwiedzającego (cookie albo detekcja przeglądarki) i ustawia atrybut data-bs-theme przed pierwszym malowaniem. To jedyny komponent czystego wdrożenia, który nie podlega negocjacji.
Przełącznik w nagłówku. Przycisk albo suwak, którym użytkownik przełącza między trybem Auto (podąża za przeglądarką), Jasnym (wymuszony) i Ciemnym (wymuszony). Wzorzec trzech stanów stał się standardem w 2026 roku: nie tylko Jasny i Ciemny, ale też Auto, aby uszanować wybór systemowy użytkownika bez konieczności klikania za każdym razem.
Trwałość przez cookie. Żeby wybór przetrwał między sesjami, potrzebne jest cookie przeglądarki (zwykle roczne, z SameSite=Lax). Bez cookie odwiedzający przy każdej wizycie wraca do trybu Auto, co niweczy sens ręcznego ustawienia.
Trwałość po stronie klienta dla zalogowanych. Dla klientów logujących się do konta Shopware preferencja musi być przechowywana po stronie serwera (custom field klienta), aby dało się ją odnaleźć na dowolnym urządzeniu. Bez tego klient, który ustawi tryb ciemny na telefonie, wchodzi na komputer i na nowo odkrywa domyślny tryb jasny.
Orkiestracja: przy logowaniu synchronizujemy cookie z custom fieldem klienta (cookie zapisywane wartością klienta, jeśli ma zapisany wybór). Przy każdej zmianie przez przełącznik aktualizujemy cookie ORAZ zapisujemy custom field, jeśli użytkownik jest zalogowany. Efekt to tryb ciemny działający „między urządzeniami”, który podąża za klientem wszędzie.
Wdrożenie krok po kroku w storefroncie Shopware 6.7
Wdrożenie przebiega w pięciu uporządkowanych etapach.
Etap 1: sprawdź konwencję CSS swojego motywu. Przejrzyj katalog theme/Resources/app/storefront/src/scss/, aby ustalić, czy motyw używa selektora [data-bs-theme="dark"], czy innej konwencji. Jeśli w użyciu jest Bootstrap 5.3 lub nowszy (a tak jest w motywach Shopware 6.6 i wyżej), powinieneś znaleźć reguły ciemne oparte na tej konwencji. Jeśli nie, będziesz musiał dodać własne style ciemne pod wybranym przez siebie selektorem.
Etap 2: dodaj skrypt anti-FOUC do bazowego layoutu. Nadpisz base.html.twig w swoim motywie, aby w bloku odpowiadającym sekcji head dodać skrypt inline odczytujący cookie df-dark-mode i ustawiający atrybut. Skrypt musi znaleźć się możliwie najwyżej w sekcji head, najlepiej przed każdym innym skryptem i arkuszem stylów, aby wykonać się przed pierwszym malowaniem.
Etap 3: utwórz komponent przełącznika. Prosty komponent Twig dark-mode-toggle.html.twig z przyciskiem cyklicznie przechodzącym przez 3 stany. Dołącz go do bloku base_header_actions_wishlist bazowego layoutu albo do innego bloku zgodnie z Twoim projektem. Przełącznik powinien pokazywać ikonę reprezentującą bieżący stan (księżyc dla ciemnego, słońce dla jasnego, półksiężyc albo ikona złożona dla trybu auto).
Etap 4: zaimplementuj logikę JavaScript. Wtyczka JS storefrontu (dark-mode-toggle.plugin.js), która: (a) nasłuchuje kliknięć w przełącznik, (b) wylicza nowy stan, (c) zapisuje cookie, (d) aktualizuje atrybut data-bs-theme, (e) emituje zdarzenie własne df-dark-mode-changed, aby inne komponenty mogły zareagować, (f) jeśli użytkownik jest zalogowany, wysyła żądanie POST na trasę Shopware aktualizującą custom field klienta.
Etap 5: wtyczka PHP dla custom fielda klienta i trasy AJAX. Standardowa wtyczka Shopware 6.7, która: (a) tworzy przy instalacji custom field df_dark_mode_preference na encji klienta (typ Select z 3 opcjami), (b) udostępnia trasę AJAX /df-dark-mode/save, która waliduje otrzymany tryb i zapisuje custom field, (c) podpina się pod CustomerLoginEvent, aby zsynchronizować cookie przy logowaniu, (d) czysto usuwa custom field przy odinstalowaniu.
Ręczne wdrożenie zajmuje doświadczonemu deweloperowi Shopware pół dnia plus kilka godzin testów. Da się to zrobić. Ale to również typowa funkcja, którą rozwija się raz i wdraża na wielu sklepach, stąd sens dedykowanej wtyczki.
Dokładnie to robi nasza wtyczka DataFirefly Dark Mode: przełącznik 3 stanów w nagłówku, gwarantowany anti-FOUC przez skrypt inline, trwałość przez cookie dla odwiedzających i custom field klienta dla zalogowanych, synchronizacja przy logowaniu, zdarzenie JS dla integracji zewnętrznych oraz dołączone wielojęzyczne snippety. Instalacja w 3 minuty, sprawdzona konfiguracja domyślna.
Trwałość preferencji: cookie kontra custom field klienta
Trwałość to obszar, w którym większość wtyczek trybu ciemnego idzie na kompromisy pogarszające doświadczenie.
Podejście z samym cookie. Najprostsze: cookie utrzymuje preferencję przez rok. Zalety: zero wpływu na bazę danych, działa bez logowania, natychmiastowe. Ograniczenie: preferencja jest przypisana do urządzenia i przeglądarki. Klient, który zmieni urządzenie albo przejdzie w tryb prywatny, traci swoje ustawienie.
Podejście z samym custom fieldem klienta. Preferencja przechowywana na encji klienta po stronie serwera. Zalety: odnajdywana na wszystkich urządzeniach klienta, trwała. Ograniczenie: działa wyłącznie dla zalogowanych klientów i wymaga zapytania do serwera, żeby odczytać wartość, więc nie da się jej użyć do anti-FOUC, który musi być synchroniczny po stronie przeglądarki.
Podejście hybrydowe (to właściwe). Cookie dla anti-FOUC i trwałości po stronie przeglądarki plus custom field klienta dla zalogowanych. Przy zmianie preferencji zapisujemy w obu miejscach. Przy logowaniu synchronizujemy cookie z wartością custom fielda. Ten hybrydowy projekt łączy zalety obu podejść i eliminuje ich ograniczenia.
Szczegół techniczny, który robi całą różnicę, to synchronizacja przy logowaniu. Bez niej klient logujący się na nowym urządzeniu zobaczy tryb domyślny zamiast odnaleźć swoje wcześniejsze ustawienie. Z nią doświadczenie jest spójne na wszystkich urządzeniach klienta. To detal niewidoczny, gdy działa dobrze, ale natychmiast odczuwalny, gdy go brakuje.
Synchronizacja trybu ciemnego z innymi komponentami strony
Gdy tryb ciemny już działa, część komponentów zewnętrznych musi wiedzieć, który motyw jest zastosowany, żeby się dostosować. Najczęstsze przypadki: wykresy Recharts albo Chart.js, zewnętrzne ramki iframe (kalendarz, osadzone wideo, formularz zewnętrzny), widgety czatu na żywo, odtwarzacze audio i wideo. Bez synchronizacji te komponenty zostają w trybie jasnym na ciemnym tle, co daje nieprzyjemne kontrasty i psuje spójność wizualną.
Czyste rozwiązanie: własne zdarzenie JavaScript emitowane na obiekcie document przy każdej zmianie motywu. Standardowy wzorzec używa zdarzenia o nazwie df-dark-mode-changed z ładunkiem udostępniającym surową preferencję (auto, light, dark) oraz motyw faktycznie zastosowany (light albo dark wyliczony po rozstrzygnięciu trybu auto).
Zainteresowane komponenty nasłuchują zdarzenia przez document.addEventListener i odpowiednio dostosowują renderowanie: wykres Recharts renderuje się ponownie z dopasowaną paletą, zewnętrzna ramka iframe dostaje postMessage z poleceniem przełączenia motywu, a odtwarzacz wideo przełącza swoje nakładki.
Ta mechanika jest czysta, bo rozprzęga komponenty: wtyczka trybu ciemnego nie musi znać komponentów zewnętrznych i odwrotnie. Zdarzenie własne pełni rolę neutralnego interfejsu. Koszt wdrożenia po stronie wtyczki jest minimalny (jedno dispatchEvent przy każdej zmianie), a korzyść po stronie integracji zewnętrznych znaczna.
Podsumowanie: umiarkowana inwestycja, mocny sygnał jakości
Tryb ciemny w Shopware 6.7 nie jest zagadnieniem technicznie bardzo złożonym, gdy patrzeć na jego elementy osobno. Łączy jednak kilka detali (anti-FOUC, trwałość między urządzeniami, zgodność z Bootstrapem, zdarzenie synchronizacji), które wszystkie muszą być dobrze zrobione, żeby doświadczenie było czyste. Źle zrobiony tryb ciemny pogarsza UX zamiast go poprawiać: biały błysk, utracona preferencja między urządzeniami, konflikty z motywem, zepsute kontrasty na komponentach zewnętrznych.
Inwestycja się opłaca, bo sygnalizuje odwiedzającym, że Twój sklep trzyma standardy UX roku 2026, i bo przynosi szczególnie wyraźną korzyść wśród odbiorców wrażliwych na UX (segmenty technologiczne, kreatywne, zaawansowani użytkownicy). Koszt jest umiarkowany (pół dnia pracy dewelopera w wersji ręcznej, 49 € za dedykowaną wtyczkę), a korzyść trwała.
Aby pogłębić pokrewne tematy, przejrzyj kategorie Konwersja i UX oraz Wydajność i Core Web Vitals. A po gotowy do wdrożenia tryb ciemny dla Shopware 6.7 z gwarantowanym anti-FOUC, hybrydową trwałością i natywnym zdarzeniem synchronizacji sięgnij po wtyczkę DataFirefly Dark Mode, która realizuje całość tego artykułu w kilka minut instalacji.
Aby przejść do działania: nasz wybór rozszerzeń Shopware do designu i personalizacji.
