"},{"@type":"HowToStep","position":3,"name":"Zmień target build","text":"W webpack/Vite/esbuild ustaw target: \"es2017\" lub nowszy. Nie transpiluj async/await, arrow functions, destructuring - wszystkie nowoczesne przeglądarki to obsługują natywnie."},{"@type":"HowToStep","position":4,"name":"Audytuj polyfille","text":"Wiele starych bibliotek przewozi własne polyfille (Promise polyfill, fetch polyfill). Sprawdź czy są jeszcze potrzebne - natywne implementacje są od lat we wszystkich przeglądarkach."}]}]}
Optymalizacja

Stary JavaScript - dlaczego nowe przeglądarki dostają niepotrzebny kod

Stary kod (transpilowany pod IE), który nowoczesne przeglądarki dostają niepotrzebnie - zbędne kilobajty do pobrania i parsowania.

Aktualizacja:
Krótka odpowiedź

Legacy JavaScript to kod transpilowany do standardu ES5, żeby działał na starych przeglądarkach jak Internet Explorer. Zawiera polyfille i helper functions, których nowoczesne przeglądarki nie potrzebują. Microsoft zakończył wsparcie dla IE w czerwcu 2022, ale większość stron wciąż serwuje legacy kod każdemu - w tym 99,7% użytkowników nowoczesnych przeglądarek.

Kluczowe fakty
Lighthouse audit legacy-javascript
Typowy zysk 20-50% bundle JS mniej
Wpływa na metryki LCP, TBT (przez mniej kodu do parsowania)
Microsoft zakończył wsparcie IE Czerwiec 2022

Co to jest legacy JavaScript?

Większość frameworków JS i build toolsów domyślnie transpiluje kod do starszego standardu (ES5), żeby działał na każdej przeglądarce - w tym Internet Explorer. To dodaje sporo balastu: polyfille, helper functions, fallbacki dla syntaxu, którego nowoczesne przeglądarki obsługują natywnie.

Dlaczego to problem?

Microsoft zakończył wsparcie dla IE w czerwcu 2022. Globalny udział IE w 2025 spadł poniżej 0,3%. Mimo to większość stron wciąż serwuje kod transpilowany pod IE każdemu użytkownikowi - w tym 99,7% korzystającym z nowoczesnych przeglądarek.

Jak to naprawić?

  1. Differential serving - dwa bundle'e: nowoczesny i fallback. Przeglądarka wybiera odpowiedni:
    <script type="module" src="app.modern.js"></script>
    <script nomodule src="app.legacy.js"></script>
  2. W build config (webpack, Vite, esbuild) ustaw target: "es2017" lub nowszy
  3. W browserslist: not IE 11 + last 2 versions
  4. Sprawdź dependencies - niektóre stare biblioteki przewożą polyfille same z siebie

Najczęstsze pytania

Czy mogę całkiem porzucić wsparcie IE?
Z perspektywy 2025-2026 - tak, dla zdecydowanej większości polskich stron. Internet Explorer ma globalnie poniżej 0,3% udziału, w Polsce praktycznie zero. Korporacje wewnętrzne czasem trzymają IE dla starych systemów, ale to bardzo specyficzny use case (intranet, panele admina), nie typowy ruch ze strony publicznej.
Co konkretnie zyskam wycinając legacy JS?
Typowo 20-50% mniejszy bundle JavaScript. Dla strony z 500 KB JS to oznacza 100-250 KB mniej do pobrania i parsowania. Translacja: szybszy LCP o 0,3-1,0 sekundy, niższy TBT, lepsze INP. Konkretne korzyści zależą od strony, ale rzadko spotyka się scenariusz, w którym zysk byłby mniejszy niż 15%.
Czy „type=module" wyłącza działanie skryptu w IE?
Tak - to celowy efekt. <script type="module"> jest ignorowany przez IE i starsze przeglądarki, które nie wspierają ES modules. Razem z <script nomodule> (ignorowane przez nowoczesne, wykonywane przez stare) daje to dwa kanały serwowania kodu bez dodatkowej logiki po stronie serwera.
Powiązane pojęcia
Nieużywany JavaScript - co to jest i jak go wyciąćTBT (Total Blocking Time)

Sprawdź swoją stronę

Wpisz adres swojej strony, w 30 sekund zobaczysz konkretną listę problemów do naprawy - wraz z wpływem na sprzedaż, SEO i koszty reklam.

Zacznij test →