Encoders & Utilities

Minifier CSS / JS

Minifikuj CSS lub JavaScript: usuwa komentarze i spacje z autodetekcją, statystykami i kopiowaniem.

What this does

CSS — strips /* comments */, collapses whitespace, removes trailing semicolons, tightens punctuation.
JavaScript — strips // line and /* block */ comments, collapses whitespace, tightens braces and parens. Preserves string and template literals.

Note: this is a safe regex minifier — no variable renaming (mangling) and no dead-code elimination. Use Terser / esbuild in your build pipeline for production-grade compression.

O tym narzędziu

CSS / JS Minifier usuwa wszystko, czego przeglądarka nie potrzebuje: komentarze, redundantne białe znaki, końcowe średniki i (dla CSS) opcjonalne jednostki po zerze. Wklej plik lub upuść go na stronę; narzędzie autodetektuje, czy dałeś mu CSS czy JavaScript, i aplikuje odpowiedni ruleset. Oryginalny i zminifikowany rozmiar są pokazane obok siebie z procentem oszczędności.

Dla CSS podążamy konserwatywnym zestawem reguł — bezpiecznym we wszystkich przeglądarkach, bez zmian specyficzności, bez przepisywania shorthands, które mogłoby zmienić zachowanie cascade. Dla JavaScript minifier usuwa komentarze i kolapsuje białe znaki, ale nie zmienia nazw zmiennych ani nie mangluje identyfikatorów (to wymagałoby parsera i ryzykuje złamanie eval / dynamicznego dostępu do property). Dla agresywnej minifikacji (terser, esbuild, swc) użyj narzędzia build-time; to jest właściwe narzędzie do szybkich zadań "uczyń to mniejszym przed wklejeniem do e-maila".

Kiedy używać tego narzędzia

Szybki win przed wdrożeniem. Mały inline <style> lub <script>, który nie przechodzi przez bundler, nadal skorzysta na minifikacji.
E-mail i template AMP. Inline CSS uderza w limity rozmiaru; stripowanie białych znaków może oszczędzić 30–40%.
Copy-paste do konfiguracji. Długie snippety JS w plikach konfiguracji YAML lub JSON stają się znacznie czytelniejsze gdy zminifikowane.
Weryfikacja oszczędności bajtów przed commitowaniem zmiany narzędzia build.

Czego celowo nie robimy

Brak renamingu zmiennych, brak eliminacji martwego kodu, brak przepisywania wyrażeń. Te zmiany mogą złamać kod polegający na nazwach identyfikatorów (debug, monkey-patching, dynamiczne this), a gwarancje bezpieczeństwa wymagają w pełni AST-aware parsera. Dla buildów produkcyjnych użyj terser lub esbuild; oszczędności są większe, ale powierzchnia bezpieczeństwa znacznie szersza. To narzędzie daje Ci łatwe 50% z zerowym ryzykiem.

Najczęstsze pytania

O ile mniejszy będzie mój plik?

Typowe oszczędności: 30–50% dla CSS, 20–40% dla JavaScript. Mocno skomentowane pliki źródłowe mogą uderzyć w 60%+ oszczędności. Już zminifikowane inputy dostają mało korzyści (minifier nadal działa idempotentnie — uruchomienie go dwa razy nic nie psuje). Dla agresywniejszych oszczędności sparuj z kompresją gzip/brotli na poziomie serwera, która jest multiplikatywna z minifikacją.

Czy działa na TypeScript?

Nie bezpośrednio — TypeScript nie jest poprawnym JavaScript, a nasz minifier oczekuje JS. Skompiluj swój TS do JS najpierw (tsc, esbuild, swc) i zminifikuj output. Dla type-annotated source TS-aware narzędzie jak esbuild lub swc robi zarówno type-stripping, jak i minifikację w jednym przebiegu i jest właściwym wyborem.

Czy zminifikowany CSS złamie mój layout?

Nie — minifier zachowuje specyficzność selektorów, kolejność property i strukturę at-rule dokładnie. Jedyną zmianą behavioralną jest kolapsowanie białych znaków i usuwanie komentarzy, oba są traktowane przez CSS jako nieznaczące. Jeśli widzisz wizualny diff po minifikacji, trafiłeś w bug — zgłoś z inputem.

Czy działa dla inline source map?

Stripuje je (komentarz //# sourceMappingURL= jest komentarzem i idzie sobie). Na produkcji zwykle chcesz wygenerować osobny plik .map obok zminifikowanego output, serwowany warunkowo. Nasze narzędzie nie generuje source mapy — to wymaga pełnego parsera i jest odpowiedzialnością pipeline build. Użyj esbuild / terser do tego workflow.