Przy rewizji strony firmowej Shandong XYN Information Technology Co., Ltd. wiele czasu poświęca się na wizualizację pierwszej strony, podczas gdy funkcje statystyczne, obsługa klienta, piksele, A/B testy, czat oraz SDK mapy są „po prostu umieszczane” w nagłówku. W dokumencie „Third-party JavaScript performance” portalu Google web.dev jasno stwierdzono: skrypty stron trzecich nie tylko spowalniają ładowanie strony, ale także wpływają na prywatność, bezpieczeństwo i zachowanie samej strony; a ponieważ nie są one wpisane w twój harmonogram aktualizacji, problemy te są jeszcze trudniejsze do zlokalizowania i usunięcia. Skrypty synchroniczne blokują analizę dokumentu; jeśli źródło strony trzeciej ulegnie awarii, strona może czekać aż do przekroczenia limitu czasu żądania. Testy jednopunktowe wykonane przez WebPageTest, cytowane przez web.dev, szacują ten okres na 10 do 80 sekund. Dla witryn B2B, które mają zbierać leady, takie opóźnienia są bardziej szkodliwe dla konwersji niż brak dwóch zdjęć produktu.
Po pierwsze — uporządkuj zapasy, dopiero później zadbaj o techniki optymalizacyjne
Pierwszym krokiem zaleconym przez web.dev nie jest modyfikacja kodu, lecz zarządzanie: wybieraj dostawców o mniejszej ilości kodu, ustal budżet wydajnościowy dla stron trzecich, unikaj jednoczesnego używania dwóch systemów zarządzania tagami czy dwóch rozwiązań statystycznych, regularnie przeprowadzaj audyty i usuwaj nieprzyznane piksele. Na wielu stronach firmowych równocześnie istnieją stare statystyki Baidu, nowe platformy analityczne, reklamowe piksele dodane samowolnie przez dział sprzedaży oraz przestarzałe narzędzia obsługi online; każde z nich ma własne frameworki, własne połączenia i bardzo słabe strategie buforowania. Pod względem strategii ładowania, poza skryptami niezbędnymi do kluczowego renderowania, należy stosować async lub defer; web.dev podaje przykład „The Telegraph”, który po zmianie skryptów, w tym tych reklamowych i statystycznych, na defer, osiągnął średnio około 4 sekund szybsze ładowanie reklam. Jeśli chodzi o źródła, które zdecydowanie zamierzasz wykorzystać, to preconnect jest lepszym rozwiązaniem od zwykłego pre-解析u DNS, co pozwala zaoszczędzić kolejny etap handshaku TLS.
1.1 Strony marketingowe i formularze nie powinny korzystać z tej samej polityki bezpieczeństwa
W dyskusji o łańcuchu dostaw front-end OWASP podkreśla, że ten sam fragment kodu analitycznego, umieszczony na stronie z historią marki i na stronie wysyłania formularza kontaktowego, niesie zupełnie różne ryzyko. Incydent z 2025 roku, w którym pakietki chalk, debug i inne zostały przejęte, a łączna liczba pobrań tygodniowo wynosiła około 2,6 miliarda, pokazuje, że utrata konta administratora może rozprzestrzenić się poprzez graf zależności. Nawet jeśli strona główna nie pakuje bezpośrednio tych bibliotek za pomocą npm, wystarczy, że używa automatycznie aktualizowanych tagów lub adresów „najnowszych wersji” na CDN, aby otworzyć sobie drogę atakom.
Drugi punkt: CSP powinien opierać się na losowych liczbach, a nie na bezgranicznym dodawaniu białej listy
Wskazówki MDN dotyczące implementacji CSP stawiają surową politykę opartą na nonce lub hash przed polityką opartą na białej liście domen. Biała lista stopniowo się wydłuża, aż w końcu obejmuje nawet niebezpieczne domeny, co praktycznie znosi wszelkie zabezpieczenia. strict-dynamic służy do rozwiązania problemu „pierwszego zaufanego skryptu, który ściąga kolejne skrypty”, dzięki czemu nie musimy wpisywać połowy Internetu do script-src. Natomiast connect-src ogranicza, gdzie skrypty mogą przesyłać dane — to właśnie klucz do uniknięcia przypadków, gdy statystyczny kod zostanie wykradziony razem z danymi z formularza. Skrypty inline nie mogą być zabezpieczone SRI, więc pozostaje polegać na nonce, który zmienia się przy każdej odpowiedzi. Tylko stałe biblioteki z zapiętymi wersjami nadają się do zastosowania SRI.
| Strona kontrolna | Co rozwiązuje | Rekomendacje dotyczące wdrożenia na stronie głównej |
|---|---|---|
| Zapasy i budżet | Powtarzające się dostawcy, nieprzyznane piksele | Codziennie wymieniaj odpowiedzialnych, a jeśli budżet zostanie przekroczony, odłącz stronę |
| Sposób ładowania | Blokowanie renderowania, pojedyncze przekroczenie limitu czasu | Domyślnie defer, obsługa klienta i piksele odłożone na moment interakcji |
| CSP z nonce i strict-dynamic | XSS i swobodne wstawianie skryptów | Najpierw Report-Only, a następnie obligatoryjne na stronach formularzy |
| connect-src / Permissions-Policy | Przekazywanie danych i nadużycia możliwości przeglądarki | Na stronach formularzy zabrania się dostępów do schowka, kamery i innych niepotrzebnych funkcji |
| SRI i zapięcie wersji | Zmiana plików na CDN | Zakaz publicznych bibliotek „latest” bez hasha |
Trzeci punkt: rewizja powinna zaczynać się od budżetu na skrypty, a nie od projektów wizualnych
O Core Web Vitals już wiele się mówi, ale na stronach firmowych prawdziwe straty często pojawiają się w skryptach stron trzecich, a nie w własnym CSS. web.dev przypomina również: samo nawiązanie połączenia ze źródłem strony trzeciej jest kosztowne; HTTPS wymaga przejścia przez DNS, przekierowań i kilku razy powrotu; gdy na jednej stronie ściągamy wiele różnych źródeł, to jakby stawiamy pierwszą stronę na najwolniejszym z nich. Kiedy XYN Tech tworzy stronę główną, lista tagów jest traktowana jako dokument doroczny na równi z hierarchią sekcji: każdy skrypt zawiera jasne wskazanie celu, nazwę domeny, do której dane są wysyłane, czy ma pojawiać się na stronach formularzy oraz czy w przypadku awarii strona nadal będzie mogła zostać wysłana. Na stronach z formularzami kontaktowymi domyślnie nie ładowane są reklamy i niekonieczne piksele; komponent czatu jest włączany dopiero po kliknięciu, aby nie powierzać losu pierwszej strony dostępności dostawcy obsługi klienta. Permissions-Policy umożliwia wyłączenie dostępu iframe stron trzecich do schowka, kamery i USB, co jest szczególnie przydatne na stronach z uploadem plików czy demonstracjami online.
- Użyj narzędzi deweloperskich, aby wyróżnić wszystkie źródła stron trzecich i zaznaczyć funkcje, które się powtarzają.
- Ustal budżety na skrypty dla strony głównej i strony kontaktowej (w kilobajtach i czasie blokowania głównego wątku).
- Uruchom punkt raportowania CSP, najpierw sprawdź tygodniowe fałszywe alarmy, a dopiero potem wprowadzaj obowiązkowe zasady.
- W umowie wymagaj, aby każdy nowy piksel dodany przez dział marketingu musiał przejść proces zmian, a nie był wprowadzany samowolnie poprzez modyfikację szablonu.
Menedżer tagów często jest uważany za „drzwi tylne”, przez które można dodać piksele bez konieczności kontaktu z deweloperami. Dla zespołu ds. bezpieczeństwa oznacza to przekazanie władzy nad publikowaniem skryptów do działu marketingu. Akceptowalnym warunkiem jest: tylko kontrolowane konta mogą publikować, każda publikacja musi mieć różnice, a kontener produkcyjny domyślnie blokuje niezatwierdzone tagi. W innym przypadku, gdy CSP zostanie zaostrzone, menedżer tagów ponownie wprowadzi dowolne skrypty. Zarządzanie skryptami stron trzecich nie daje miejsca na efekty wrażliwe; to odbiór władzy nad tym, kto może wykonywać kod pod naszą domeną. Jeśli następnym razem będziesz robić rewizję strony głównej i oceniać wyłącznie aspekty wizualne, proszę dołącz do materiałów oceny również zrzuty ekranu panelu sieciowego: te różnokolorowe paski żądań stron trzecich są wspólnym szumem dla konwersji i bezpieczeństwa. Najpierw usuń te, których nikt nie przyznał, a dopiero później decyduj, czy warto wymienić na cięższy system marketingowy.