Encoders & Utilities

CSS / JS Minifier

Мініфікуй CSS або JavaScript: коментарі й пробіли геть, з автовизначенням і копіюванням.

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.

Про цей інструмент

CSS / JS Minifier прибирає все, що браузер не потребує: коментарі, надлишкові пробіли, trailing semicolons і (для CSS) опційні units після нуля. Вставте файл або киньте на сторінку; інструмент авто-детектить, CSS це чи JavaScript, і застосовує відповідний ruleset. Оригінальний і мінімізований розміри показано side-by-side із відсотком збереженого.

Для CSS ми йдемо консервативним rule-set — безпечним між усіма браузерами, без specificity-змін, без shorthand-rewrites, що могли б змінити cascade-поведінку. Для JavaScript мінімізатор прибирає коментарі і колапсує whitespace, але не перейменовує змінні і не mangle-ить ідентифікатори (це б вимагало парсера і ризикувало зламати eval / dynamic property access). Для агресивного minification (terser, esbuild, swc) використовуйте build-time-інструмент; це правильний інструмент для швидких «зроби менше перед вставленням в email»-задач.

Коли використовувати цей інструмент

Pre-deploy quick win. Малий inline <style> або <script>, що не проходить через ваш bundler, все одно виграє від minification.
Email і AMP templates. Inline CSS б'є size-ліміти; стрипання whitespace може зекономити 30–40%.
Copy-paste в config. Довгі JS-снипети в YAML або JSON config-файлах стають значно читабельнішими в мінімізованому вигляді.
Верифікація byte-савінгів перед комітом до build-tool-зміни.

Чого ми свідомо не робимо

Немає variable renaming, dead-code elimination, expression rewriting. Ці зміни можуть зламати код, що покладається на identifier-імена (debug, monkey-patching, dynamic this), а гарантії безпеки вимагають full AST-aware парсера. Для production-builds використовуйте terser або esbuild; savings більші, але safety-surface значно ширша. Цей інструмент дає вам легкі 50% з нульовим ризиком.

Часті запитання

На скільки менший буде мій файл?

Типові savings: 30–50% для CSS, 20–40% для JavaScript. Heavily-commented source-файли можуть досягати 60%+. Already-minified input отримує мало користі (мінімізатор працює ідемпотентно — запуск його двічі нічого не ламає). Для агресивніших savings парте з gzip/brotli-компресією на server-level — вона мультиплікативна з minification.

Чи працює воно на TypeScript?

Не напряму — TypeScript не валідний JavaScript, а наш мінімізатор очікує JS. Скомпілюйте TS у JS першим (tsc, esbuild, swc) і мінімізуйте output. Для type-annotated source TS-aware-інструмент на кшталт esbuild або swc робить і type-stripping, і minification в одному проході, і це правильний вибір.

Чи зламає мінімізований CSS мій layout?

Ні — мінімізатор зберігає selector specificity, property order і at-rule структуру точно. Єдина поведінкова зміна — whitespace collapse і comment removal, обидва з яких CSS трактує як незначні. Якщо бачите visual diff після minification, ви знайшли баг — повідомте з input.

Чи працює це для inline source maps?

Воно їх прибирає (коментар //# sourceMappingURL= — це коментар, і він зникає). Для продакшну зазвичай хочете генерувати окремий .map-файл поруч із мінімізованим output, що подається умовно. Наш інструмент не генерує source maps — це вимагає повноцінного парсера і є відповідальністю build pipeline. Використовуйте esbuild / terser для цього workflow.