Що таке browser target і чому фронтенд не збирається для всіх браузерів однаково

Зачіпка

Browser target — це відповідь на просте, але дуже дороге питання: для яких браузерів ми взагалі збираємо фронтенд? Якщо відповіді немає, build tool вирішує за вас, а користувачі з “трохи старішим” браузером можуть отримати білий екран замість сайту.

Проблема / Контекст

Сучасний JavaScript і CSS розвиваються швидше, ніж парк браузерів у реальних людей. На ноутбуці розробника все може працювати в останньому Chrome, але частина аудиторії відкриває сайт у Safari на старішому iPhone, Android WebView всередині застосунку або корпоративному браузері, який оновлюється раз на кілька епох.

Фронтенд-збірка має вирішити, який код залишити сучасним, а який перетворити через транспіляцію. Наприклад, сучасний синтаксис може бути зручним для команди, але не всі браузери однаково розуміють нові можливості. Build tool дивиться на target і вирішує, наскільки “обережним” має бути output.

Проблема в тому, що browser target часто живе десь у конфігу і про нього згадують лише після помилки. У Vite це може бути build.target, у частини проєктів — browserslist у package.json, у старіших стеках — комбінація Babel, Autoprefixer і окремих legacy-плагінів. Якщо ніхто не знає, який target зараз активний, команда не керує сумісністю — вона просто сподівається.

Чому це важливо

Browser target впливає одразу на кілька речей.

По-перше, на стабільність. Якщо у збірці залишився синтаксис, який не підтримує мінімальний браузер, сторінка може впасти ще до того, як користувач побачить інтерфейс. Це особливо неприємно: помилка не завжди відтворюється у розробника.

По-друге, на розмір бандлу. Чим старіші браузери треба підтримувати, тим більше перетворень і додаткового коду може знадобитися. Це не означає, що старі браузери завжди треба відрізати. Це означає, що підтримка має бути свідомим рішенням.

По-третє, на CSS. Префікси, нові селектори, сучасні одиниці виміру і layout-можливості теж мають межі підтримки. Якщо target описаний тільки для JavaScript, можна випадково отримати красивий код і некрасивий інтерфейс.

По-четверте, на тестування. Неможливо чесно сказати “ми підтримуємо Safari 16”, якщо ніхто не відкривав preview у Safari 16 або хоча б не проганяв сумісність через відповідні інструменти.

Ілюстрація: одна ціль — різний output

Уявіть build tool як перекладача між командою розробки і браузерами користувачів. Ліворуч — сучасний код, який зручно писати. Праворуч — різні браузери з різним рівнем підтримки. Browser target каже перекладачу: “Ось мінімальна аудиторія, нижче не опускаємось”.

Якщо target сучасний, output може залишатися компактнішим і ближчим до початкового коду. Якщо target старіший, збірка мусить бути обережнішою: перетворити частину синтаксису, додати polyfill або попередити, що певну можливість без окремого рішення не підтримати.

Важливий момент: target не робить неможливе можливим. Якщо браузер не має певної платфорної можливості, build tool не завжди може її “намалювати” зверху. Іноді потрібен polyfill, іноді — fallback у коді, а іноді — чесне рішення не підтримувати цей браузер.

Як це зробити

1. Знайдіть, де target задано

Почніть із package.json і конфігів збірки. У Vite часто зустрічається такий варіант:

// vite.config.js
export default {
  build: {
    target: "es2020"
  }
};

Це означає, що збірка орієнтується на рівень можливостей, близький до ES2020. Але не копіюйте це сліпо. Для іншого продукту правильним може бути інший target.

У деяких проєктах список браузерів живе в package.json:

{
  "browserslist": [
    "last 2 Chrome versions",
    "last 2 Firefox versions",
    "Safari >= 16"
  ]
}

Browserslist можуть читати різні інструменти. Тому важливо зрозуміти не тільки що написано, а й хто це реально використовує у вашому стеку.

2. Переведіть бізнес-вимогу в технічний target

Поганий target звучить так: “підтримуємо все”. Добрий target звучить конкретно: “підтримуємо останні дві версії основних браузерів і Safari від версії, яка відповідає нашій статистиці”.

Якщо є аналітика, подивіться на реальні браузери користувачів. Якщо аналітики немає, зафіксуйте розумне припущення і дату перегляду. Гірше за неправильний target тільки target, який ніхто не може пояснити.

3. Запустіть production build і прочитайте warning-и

Команда зазвичай знайома:

npm run build

Після цього не ігноруйте warning-и. Build tool може прямо сказати, що певна можливість не трансформується під заданий target або що CSS-можливість має обмежену підтримку. Warning — це не шум, а ранній сигнал, який дешевше перевірити зараз, ніж після релізу.

4. Перевірте preview у мінімальному браузері

Якщо ви заявили підтримку певного мінімального браузера, відкрийте саме його. Не тільки останній Chrome на машині розробника. Перевірте старт сторінки, навігацію, форми, модальні вікна, lazy loading, оплату або інші критичні сценарії.

Для простого сайту достатньо короткого ручного smoke test. Для важливого продукту краще додати перевірку в CI або хоча б окремий release checklist.

5. Не лікуйте все polyfill-ами

Polyfill корисний, коли він точково закриває реальну прогалину. Але якщо додати все “про всяк випадок”, користувачі отримають важчий JavaScript, а команда — складніший debug. Спершу визначте target, потім дивіться, які саме можливості не покриті.

Антипатерни

• залишати target за замовчуванням і не знати, що він означає;
• копіювати browserslist з чужого проєкту без прив’язки до аудиторії;
• тестувати тільки в останньому Chrome;
• підтримувати дуже старий legacy browser без оцінки вартості;
• додавати великий набір polyfills без конкретної причини;
• плутати browser target із версією Node.js для build-скриптів;
• міняти target перед релізом без preview і smoke test.

Висновок / План дій

Browser target — це не дрібна технічна настройка, а домовленість між продуктом, командою і реальними браузерами користувачів. Він визначає, наскільки сучасним може бути output і яку сумісність ви обіцяєте.

Що зробити далі:

1. знайти активний target у проєкті;
2. перевірити, чи він відповідає реальній аудиторії;
3. запустити production build і прочитати warning-и;
4. відкрити preview у мінімальних підтримуваних браузерах;
5. задокументувати рішення, щоб наступний розробник не грав у археолога.

Офіційні джерела:

• https://vite.dev/config/build-options.html#build-target
• https://esbuild.github.io/api/#target
• https://github.com/browserslist/browserslist
• https://developer.mozilla.org/en-US/docs/MDN/Writing_guidelines/Page_structures/Compatibility_tables