Netscape проти Internet Explorer: браузерна війна, що сформувала веб

Чому ця війна була важлива для тих, хто відповідає за продакшен

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

Netscape починав як прихильник ідеї «веб відкритий» (і, чесно кажучи, теж хотів перемогти), тоді як Microsoft сприймала
браузер як розширення операційної системи. Ця різниця важлива з операційної точки зору, тому що вона визначила,
на що стандартизувалися підприємства, як швидко вони виправляли уразливості, що можна було заблокувати, і наскільки крихкими
ставали їхні внутрішні додатки.

Якщо ви керуєте системами, вам варто звернути увагу на три наслідки тієї епохи:

• Фрагментація стала нормою. «Цю сторінку краще переглядати у…» не був мемом; це була вимога розгортання.
• Позиція безпеки прив’язалася до клієнтського рантайму. Один дефектний стек клієнта ставав ризиком для всього флоту.
• Стандарти стали рятівним спорядженням. Не з ідеології — а як операційна необхідність для тих, хто не може диктувати єдиний клієнт.

Браузерні війни дали індустрії урок, який інженери‑оператори повторюють щодня: коли ви дозволяєте одній залежності стати
«платформою», ви обираєте не просто інструмент. Ви обираєте режим відмови.

Короткі історичні факти, які варто пам’ятати

Ось конкретні пункти, що досі мають значення, коли ви намагаєтеся зрозуміти, чому веб виглядає саме так.
Не тривіалізація. Це важелі.

1. Mosaic був раніше за обох: рання команда Netscape значною мірою черпала ідеї та імпульс із NCSA Mosaic; «перша хвиля» вебу передувала війні.
2. IPO Netscape стало сигнальною ракетою: воно допомогло переконати індустрію, що веб — це платформа, а не хобі.
3. JavaScript створили швидко: Netscape ввели його оперативно, щоб зробити сторінки динамічними; швидкість виходу на ринок перемогла елегантність, і ми досі платимо відсотки за це.
4. IE постачався в комплекті: інсталяція Internet Explorer з Windows змінила економіку розповсюдження за одну ніч.
5. ActiveX розширив можливості: але також і площу ураження, бо «нативний код у браузері» небезпечний так, як звучить.
6. «Найкраще переглядати у» було реальністю: розробники орієнтувалися на браузер/версію, бо виявлення можливостей і підтримка стандартів були нерівномірні.
7. IE6 став опорою підприємств: багато інтранетів прив’язалися до нього на роки, перетворивши версію браузера на технічний борг із зарплатою.
8. Робота організацій зі стандартів була важливою: тиск W3C за інтероперабельні специфікації став противагою вендорно визначеним HTML і DOM‑особливостям.
9. Mozilla виросла з Netscape: Netscape відкрив код свого браузера, що посіяло зерно того, що згодом стало Firefox і іншою моделлю управління.

Цитата, яку варто мати на стіні, бо вона застосовна до браузерів, API й усього, що ви коли-небудь випустите:
«Надія — не стратегія.» — генерал Гордон Р. Салліван.

Як велася війна: технології, дистрибуція та важелі впливу

Дистрибуція перемагає інженерію (поки ні)

Початковою перевагою Netscape була впізнаваність. Він здавався швидким, новим і їздив на хвилі, коли «інтернет»
почав з’являтися в презентаціях правління. Перевага Microsoft була в дистрибуції: Windows на десктопах, налаштування за замовчуванням
та машина закупівель, яка віддавала перевагу одному підписаному рішенню.

З точки зору SRE, у Netscape на початку була вища швидкість додавання фіч; Microsoft контролювала канал розгортання.
Якщо ви намагаєтеся здобути прийняття, важить якість доставки. Але контроль над налаштуваннями за замовчуванням важливіший — принаймні
поки операційні витрати фрагментації не стають нестерпними.

Рендеринг‑движки: коли «той самий HTML» — це не одна й та сама система

Під UI‑обгорткою браузери були (і залишаються) складними розподіленими системами, що живуть на одній машині:
парсери, движки макету, JS‑рантайми, мережеві стеки, сховища сертифікатів, рендеринг шрифтів, політики кешування.
Netscape та IE розійшлися в реалізаціях, через що ідентична розмітка поводилася по‑різному.

Така різниця створила ранню форму багатоквартирного хаосу: той самий веб‑додаток, розгорнутий на тому самому сервері,
виконувався по-різному залежно від клієнтського рантайму. Сьогодні ви звинувачуєте «Safari». Тоді ви звинувачували «IE».
Той самий патерн, інший лиходій.

API як територія

Обидві сторони вводили спеціалізовані для свого браузера API. Деякі були корисними. Деякі — захопленням території.
Деякі — випадковими. Важливий момент: кожен нестандартний API створював вартість переключення. Щоразу, коли розробник
покладався на пропрієтарну поведінку, веб ставав менш портативним, а бізнес — більш заблокованим.

Вендор‑API не злі за визначенням. Але операційно вони — борг, якщо ви не обгорнете їх шарами сумісності й не протестуєте виходи.

Жарт №1: браузерні війни були як двоє кухарів, що сварилися за кухню, підпаливши плиту — усі отримали вечерю, але сигналізація диму стала частиною архітектури.

Стандарти проти «фіч»: інженерна дилема, що не зникла

У 1990‑х дотримання стандартів не було очевидною перемогою. Випуск фіч, які робили браузер потужним, приваблював користувачів і розробників.
І розробники, під тиском, використовували те, що працювало сьогодні, а не те, що могло бути інтероперабельним завтра.

З операційної точки зору це створило жорстоку петлю зворотного зв’язку:

• Браузер додає пропрієтарну можливість.
• Розробники використовують її, щоб швидше випустити продукт.
• Додатки стають залежними від цього браузера.
• Підприємства стандартизуються, щоб зменшити навантаження підтримки.
• Оновлення безпеки та модернізація зупиняються, бо апгрейд ламає залежні додатки.

Quirks mode: сумісність як постійний податок

Один з тривалих артефактів — «quirks mode» (режим вад) — поведінка сумісності, коли браузери емулюють старі,
нестандартні правила верстки, щоб не ламати легасі‑сторінки. Операційно quirks mode — це визначення того, що
«ми не можемо видалити старі помилки, бо клієнти побудували на них бізнеси».

Сучасні команди все ще потрапляють у quirks mode через відсутні або неправильно оформлені doctypes. Іронія чудова:
ваш веб‑додаток 2026 року може випадково запросити поведінку 1999 року. Це не машина часу; це те, що трапляється, коли
ви розглядаєте клієнтський рантайм як чорний ящик.

Стандартизація DOM: здобута важко, не неминуча

Коли інженери говорять про «DOM», вони часто говорять так, ніби він завжди існував як узгоджений стандарт.
Це не так. Розбіжні реалізації DOM означали різні моделі подій, різні назви властивостей і різні поведінки в граничних випадках.
Бібліотеки й фреймворки врешті-решт з’явилися як шари сумісності — частково щоб абстрагувати від браузерних відмінностей,
частково щоб дозволити продуктовим командам випускати фічі без вивчення всіх вендорних нюансів.

Якщо ви керуєте продакшеном: саме тому існують абстракції. Не щоб виглядати розумно. А щоб ваша черга інцидентів
не стала музеєм браузерних багів.

Безпека, контроль і довгий відголосок ActiveX

Підприємствам подобався IE не лише тому, що він «був», але й тому, що він інтегрувався з політиками Windows та
системами ідентифікації так, як Netscape — ні. Централізований контроль зменшує навантаження на підтримку. Але він також
збільшує вплив поганого значення за замовчуванням.

ActiveX: потужно, потім дорого

ActiveX дозволяв багаті клієнтські можливості, зокрема прямий доступ до можливостей ОС. Внутрішні корпоративні інтранети
стали використовувати його як скорочений шлях: створити бізнес‑додаток, що поводиться як нативний, але доставляється через браузер.
Це зробило можливими деякі робочі процеси за роки до того, як «веб‑додатки» стали серйозно сприйматися.

Плата була в тому, що «веб‑контент» і «локальне виконання» стали небезпечно близькими. Коли ви дозволяєте браузеру завантажувати
компоненти, які можуть торкатися системи, ваша модель загроз стає «весь інтернет плюс судження користувачів». Це не модель;
це тривожний розлад у архітектурній формі.

Управління патчами та залежність від вендора

Як тільки внутрішній додаток підприємства залежить від конкретної версії браузера, патчинг стає ризиковим. Ризиковий патчинг
відтерміновується. Відтермінований патчинг стає боргом безпеки. Борг безпеки призводить до «ми повинні ізолювати цей підмережу назавжди».

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

Жарт №2: ActiveX був фактично «sudo для браузера», тільки з меншою кількістю людей, що визнають, що запускали це в продакшені.

Практичні операційні завдання: перевірити, відтворити, вирішити (з командами)

Браузерні війни велися на десктопах, але операційні уроки — серверні: вам потрібні відтворювані докази, контрольовані змінні та
здатність швидко звузити відмову до одного шару. Нижче — практичні завдання, які ви можете виконати сьогодні, щоб діагностувати
повідомлення «ламається лише в браузері X», включно з тим, що означає вивід і яке рішення прийняти.

Завдання 1: Підтвердіть, що сервер фактично відправляє (заголовки)

cr0x@server:~$ curl -sS -D- -o /dev/null https://app.example.internal/
HTTP/2 200
content-type: text/html; charset=utf-8
content-security-policy: default-src 'self'; script-src 'self' 'nonce-3s9...'; object-src 'none'
strict-transport-security: max-age=31536000; includeSubDomains
x-content-type-options: nosniff
vary: Accept-Encoding

Що це означає: ви зафіксували канонічні заголовки відповіді. CSP, MIME‑тип і HSTS безпосередньо впливають на поведінку браузера.

Рішення: якщо поведінка відрізняється між браузерами, спочатку перевірте, чи заголовки однакові в різних середовищах і шляхах (автентифікація проти оболонки додатку).

Завдання 2: Перевірте MIME‑типи для JS/CSS (класична IE‑ера проблема, досі трапляється)

cr0x@server:~$ curl -sS -I https://app.example.internal/static/app.js | grep -i content-type
content-type: text/javascript

Що це означає: ви перевіряєте, чи сервер каже правду про ресурс.

Рішення: якщо бачите text/plain або відсутні типи, виправте конфіг серверу; деякі браузери виконають ресурс будь‑як, деякі відмовляться при суворіших політиках.

Завдання 3: Перевірте сумісність протоколу/шифру TLS

cr0x@server:~$ openssl s_client -connect app.example.internal:443 -servername app.example.internal -tls1_2
CONNECTED(00000003)
Protocol  : TLSv1.2
Cipher    : ECDHE-RSA-AES128-GCM-SHA256
Verify return code: 0 (ok)

Що це означає: переговори TLS пройшли з TLS 1.2. Старі клієнти можуть говорити лише старими протоколами; сучасні сервери можуть їх вимикати.

Рішення: якщо ваша база користувачів включає застарілі клієнти (кіоски, вбудовані пристрої, регульовані десктопи), вирішіть, чи підтримувати їх через сумісну кінцеву точку або вимагати оновлення.

Завдання 4: Визначте поведінку HTTP‑протоколу (HTTP/2 vs HTTP/1.1)

cr0x@server:~$ curl -sS -o /dev/null -w "%{http_version}\n" https://app.example.internal/
2

Що це означає: сервер погодив HTTP/2.

Рішення: якщо проблема корелює з протоколом, протестуйте з примусовим HTTP/1.1; деякі проміжні пристрої все ще некоректно обробляють HTTP/2 у корпоративних мережах.

Завдання 5: Примусити HTTP/1.1, щоб ізолювати проблеми з проміжними проксі

cr0x@server:~$ curl --http1.1 -sS -o /dev/null -w "%{http_version} %{remote_ip}\n" https://app.example.internal/
1.1 10.20.30.40

Що це означає: ви явно обходите HTTP/2 і підтвердили, куди підключилися.

Рішення: якщо баг зникає на HTTP/1.1, досліджуйте проксі, ALPN‑переговори або серверні налаштування HTTP/2.

Завдання 6: Перевірте заголовки кешування (відмінності браузерних кешів можуть виглядати як «баги верстки»)

cr0x@server:~$ curl -sS -I https://app.example.internal/static/app.css | egrep -i "cache-control|etag|last-modified|expires"
cache-control: public, max-age=31536000, immutable
etag: "a1b2c3d4"

Що це означає: ресурс агресивно кешується.

Рішення: якщо користувачі повідомляють «лише деякі клієнти зламалися після деплою», підозрюйте застарілі кешовані активи. Переконайтесь, що імена файлів хешуються за вмістом; не покладайтеся на перевірку кеша.

Завдання 7: Підтвердьте наявність хешування в іменах файлів (уникнути «болю ери IE6» в сучасному вигляді)

cr0x@server:~$ curl -sS https://app.example.internal/ | grep -Eo "/static/app\.[a-f0-9]{8,}\.js" | head -n 1
/static/app.9f3a1c2b7d4e.js

Що це означає: HTML посилається на файл з хешем.

Рішення: якщо хеша немає, виправте збірку. «cache-control: no-cache» — це не стратегія; це капітуляція.

Завдання 8: Перегляньте серверні логи за кластеризацією user agent (знайдіть когорту «це лише IE‑режим»)

cr0x@server:~$ sudo awk -F\" '{print $6}' /var/log/nginx/access.log | head -n 3
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/121.0 Safari/537.36
Mozilla/5.0 (Windows NT 10.0; Win64; x64; Trident/7.0; rv:11.0) like Gecko
Mozilla/5.0 (Macintosh; Intel Mac OS X 14_2) AppleWebKit/605.1.15 (KHTML, like Gecko) Version/17.2 Safari/605.1.15

Що це означає: ви витягуєте user agent; другий рядок показує Trident (движок IE).

Рішення: якщо інциденти корелюють з певним движком, вирішіть: заблокувати, плавно деградувати або створити підтримуваний шлях сумісності.

Завдання 9: Знайдіть заголовки «X-UA-Compatible» (тригер режиму IE у корпоративних налаштуваннях)

cr0x@server:~$ curl -sS -I https://app.example.internal/ | grep -i x-ua-compatible
X-UA-Compatible: IE=edge

Що це означає: цей заголовок впливає на поведінку IE/режиму сумісності в певних налаштуваннях.

Рішення: якщо бачите примусову сумісність, перевірте, чи це свідомо. У сучасних середовищах це може спричинити дивні режими документа й ламати стандартну поведінку.

Завдання 10: Відтворіть у реальному движку браузера в CI (headless)

cr0x@server:~$ node -v
v20.11.1

Що це означає: у вас є рантайм, придатний для автоматизації Playwright/Puppeteer.

Рішення: якщо ви не маєте детермінованого відтворення, додайте його. Браузерні баги, які неможливо відтворити, стають «він/вона сказав/сказала» — квитками, що ніколи не помирають.

Завдання 11: Перевірте DNS і split‑horizon поведінку (корпоративні мережі люблять сюрпризи)

cr0x@server:~$ dig +short app.example.internal
10.20.30.40

Що це означає: ви бачите резольвну IP‑адресу у поточному контексті резолвера.

Рішення: якщо користувачі в VPN бачать іншу поведінку, порівняйте DNS‑результати всередині й зовні мережі. «Проблема браузера» часто — «інший бекенд».

Завдання 12: Підтвердьте стиснення й коректність content-length

cr0x@server:~$ curl -sS -I -H "Accept-Encoding: gzip" https://app.example.internal/ | egrep -i "content-encoding|content-length|vary"
content-encoding: gzip
vary: Accept-Encoding

Що це означає: стиснення включене і варіювання встановлено правильно.

Рішення: якщо певні клієнти бачать обрізані ресурси, перевірте, чи проксі не пошкоджують gzip. Вимкніть стиснення для проблемного шляху як пом’якшення, потім виправте ланцюг.

Завдання 13: Перевірте змішаний контент і ланцюги редиректів

cr0x@server:~$ curl -sS -L -o /dev/null -w "%{url_effective} %{num_redirects}\n" http://app.example.internal/
https://app.example.internal/ 1

Що це означає: HTTP переадресовано на HTTPS в один хоп.

Рішення: якщо деякі браузери ламають логін‑потоки, перевірте на змішаний контент, незахищені cookies або дивні цикли редиректів. Різні браузери застосовують різну суворість.

Завдання 14: Перевірте атрибути cookie з сервера (SameSite — новий «режим документа»)

cr0x@server:~$ curl -sS -I https://app.example.internal/login | grep -i set-cookie
Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax

Що це означає: атрибути cookie визначають міжсайтову поведінку й безпеку.

Рішення: якщо SSO ламається в одному браузері, порівняйте обробку SameSite. Виправляйте прапори cookie на сервері замість сліпого копіювання фронтенд‑хаків.

Завдання 15: Переконайтесь, що серверна контентна нотація не розгалужує поведінку

cr0x@server:~$ curl -sS -H "Accept: text/html" -o /dev/null -w "%{http_code}\n" https://app.example.internal/
200

Що це означає: сервер повертає 200 для звичного Accept header для HTML.

Рішення: якщо конкретний браузер отримує іншу розмітку (часто через UA‑сніфінг), припиніть сніфінг і використовуйте виявлення можливостей на клієнті або прогресивне покращення.

Завдання 16: Перевірте рівні помилок і хвостову латентність по шляхах (бекенд може бути «багом браузера»)

cr0x@server:~$ sudo tail -n 5 /var/log/nginx/access.log
10.1.2.3 - - [21/Jan/2026:09:14:01 +0000] "GET /static/app.9f3a1c2b7d4e.js HTTP/2.0" 200 82341 "-" "Mozilla/5.0 ..."
10.1.2.3 - - [21/Jan/2026:09:14:01 +0000] "POST /api/login HTTP/2.0" 502 173 "-" "Mozilla/5.0 ..."
10.1.2.3 - - [21/Jan/2026:09:14:02 +0000] "GET /healthz HTTP/2.0" 200 2 "-" "kube-probe/1.28"

Що це означає: 502 на /api/login — це не проблема рендерингу. Це відмова апстріма.

Рішення: перед тим як звинувачувати браузер, перевірте стабільність бекенда на точних ендпойнтах, які вражені. Кореляція з браузером може бути наслідком shaping‑трафіку, а не поведінки клієнта.

Плейбук швидкої діагностики

Коли хтось каже «в IE‑режимі не працює» або «в Chrome працює, а в тім — ні», у вас нема часу на філософські дебати про стандарти.
Потрібна петля тріажу, що сходиться.

По-перше: доведіть, чи це контент, транспорт або виконання

1. Паритет контенту: порівняйте байти HTML/JS/CSS, які віддаються різним клієнтам (заголовки + тіло). Якщо контент відрізняється — зупиніться і виправте серверну варіацію.
2. Паритет транспорту: порівняйте версію TLS, версію HTTP, шлях через проксі та редиректи. Якщо транспорт різний — відтворіть з примусовим HTTP/1.1 та на альтернативних мережах.
3. Паритет виконання: якщо байти й транспорт збігаються, тепер можна звинуватити движок браузера (відмінності DOM/CSS/JS, політики, розширення).

По-друге: ідентифікуйте когорту і звузьте площу ураження

• Витягніть user agent‑и і згрупуйте відмови за сімейством движків (Chromium, Gecko, WebKit, Trident/EdgeHTML).
• Перевірте, чи когорту розміщено за проксі/VPN, який перезаписує заголовки або агресивно кешує.
• Швидко вирішіть свою політику підтримки: блокувати з повідомленням, запропонувати «полегшений» шлях або випустити гаряче виправлення сумісності.

По-третє: оберіть найдешевше надійне пом’якшення

• Якщо ламає політика безпеки: тимчасово послабте CSP вузько для проблемного скрипта, потім почистіть; не вимикайте CSP глобально.
• Якщо ламає кеш: очистіть CDN і переконайтесь у хешованих іменах файлів; не просіть користувачів «очистити кеш», якщо вам не подобається бути проігнорованими.
• Якщо синтаксис JS ламає: виправте цілі транпиляції; не віддавайте рантайм‑поліфіли сліпо без вимірювань.
• Якщо це корпоративна пастка IE‑режиму: випустіть підтримувану сумісну збірку або примусьте standards mode; не дозволяйте «тимчасовому» стати десятиліттям.

Три корпоративні міні-історії з польових боїв

Міні‑історія 1: інцидент через неправильне припущення

Середня компанія підтримувала портал клієнта, що модернізувався шарами: новий фронтенд на React, старіша служба автентифікації
та CDN, доданий пізніше через пріоритет продуктивності. Вони викотили незначне оновлення UI — нове стилювання сторінки логіну,
кілька SVG‑іконок і рефактор завантаження оболонки додатку.

До полудня кількість заявок у саппорт зросла: «Кнопка входу нічого не робить». Поведінка виглядала специфічною для браузера, і перше припущення
з’явилося швидко: «Це старий браузер, ігноруйте». Але вражена група зовсім не була старою — багато хто працював на керованих Windows‑десктопах з сучасним Chrome.
Спільним було корпоративне проксі.

Реальна відмова: команда припустила, що CDN і проксі поважатимуть Vary: Accept-Encoding і коректність content‑type.
Проксі закешував стиснену відповідь і віддавав її клієнтам, які не вели ту саму переговори. Деякі клієнти отримали пошкоджений JS. Браузер тихо
провалював парсинг, тому обробник логіну ніколи не приєднався.

Виправлення було не на фронтенді. Воно полягало в ужорсточенні правил кешування і виправленні заголовків, щоб проміжні елементи мали менше можливостей «проявити креатив».
Також додали синтетичну перевірку, яка завантажувала й парсила головний JS‑бандл з мережного шляху, що імітував проксі.

Урок старий і досі актуальний: ніколи не припускайте, що байти, що покидають сервер, — це ті самі байти, що доходять до браузера. Вимірюйте. Захоплюйте. Порівнюйте.

Міні‑історія 2: оптимізація, що обернулася проти

Інша організація мала внутрішню панель управління для операційного персоналу. Додаток був «достатньо швидким», але інженер, що дбав про продуктивність,
вирішив оптимізувати початкове завантаження. Він інлайнув критичний CSS, відклав неважливі скрипти й замінив кілька PNG на SVG. Рейтинг Lighthouse покращився.
Усі похлопали один одному по плечах і продовжили працювати.

Через два тижні з’явився тихий збій: частина користувачів не могла взаємодіяти з панеллю після обідньої перерви. Сторінка завантажувалась, але кліки не реєструвалися.
Повторне завантаження двічі часто вирішувало проблему. Початкова реакція була «мережева нестабільність», бо поведінка здавалася випадковою.

Виявилось, оптимізація змінила таймінг виконання скриптів. Старий внутрішній плагін — встановлений як частина пакета безпеки — інжектував скрипт,
що очікував наявність конкретного DOM‑елемента під час парсингу. З новою стратегією defer інжекція змагалася з ініціалізацією додатку. В деяких випадках плагін перезаписував глобал,
і прив’язки подій додатку ніколи не прикріплювалися.

«Оптимізація» зробила систему більш чутливою до невизначеної поведінки в клієнтському середовищі. Виправили це, прибравши залежність від глобалів,
прив’язавши ініціалізацію до детермінованої події і додавши моніторинг JS‑помилок через endpoint. Також відкотили inlining, бо він ускладнював CSP і відлагодження.

Робота над продуктивністю — це добре. Але якщо ви оптимізуєте pipeline завантаження без моделювання загроз клієнтського середовища (розширення, інжектори, корпоративні утиліти),
ви оптимізуєте для лабораторії, а не для продакшену.

Міні‑історія 3: нудна, але правильна практика, що врятувала ситуацію

Команда фінансових послуг підтримувала потік онбордінгу клієнтів, що мав працювати на заблокованих десктопах. Їхня політика була некрасива: кожне розгортання включало автоматизовані перевірки крос‑движків,
і кожний основний потік мав «знімок байтів на дроті», збережений для кожного релізу. Вони також вели матрицю підтримуваних браузерів з явними «ні», а не розмитими обіцянками.

Постачальник ідентифікації третьої сторони вніс зміну: тонку різницю в редиректах і зсув атрибутів cookie, яку одні браузери терпіли, а інші відкинули. Вночі конверсії впали — але не рівномірно.
Команда не сперечалася, хто винен. Вони виконали плейбук.

Спочатку вони порівняли заголовки й редиректи з їхніми збереженими знімками та помітили зміну cookie. По‑друге, відтворили з headless‑браузером у CI, використавши той самий потік ідентифікації.
По‑третє, випустили серверне виправлення: встановили прапори cookie відповідно до правил сучасних браузерів і забезпечили послідовність HTTPS.

«Нудна практика» не була героєм‑інженером. Це була дисципліна: артефакти, відтворюваність і відмова випускати без крос‑браузерних доказів. Інцидент обробили як операційну проблему, а не як дебатний клуб.

Поширені помилки: симптом → корінна причина → виправлення

1) «Працює в Chrome, білий екран в IE‑режимі»

Симптоми: білий екран, очевидних серверних помилок немає, лише в керованих середовищах Windows.

Корінна причина: JS‑бандл використовує синтаксис, який не підтримують застарілі рушії (або корпоративний «IE‑mode» примушує стару поведінку документа).

Виправлення: скоригуйте цілі транпиляції; випустіть сумісний бандл; виявляйте та блоковуйте непідтримувані клієнти з чітким повідомленням. Не робіть логіку через UA‑сніфінг — використовуйте виявлення можливостей і коректні відмови.

2) «Після деплою тільки деякі користувачі бачать зламану верстку»

Симптоми: CSS виглядає напівоновленим; перезавантаження іноді виправляє; кластери по місцю офісу.

Корінна причина: застарілі кешовані активи або кеш‑поізонінг через проміжні елементи; HTML посилається на новий JS, а CSS — старий (або навпаки).

Виправлення: імена файлів з хешем за вмістом, коректний cache‑control і стратегія purge. Перевірте заголовки Vary. Припиніть відправляти змінні імена файлів з довгим TTL.

3) «Цикл логіну тільки в одному браузері»

Симптоми: безкінечний редирект між додатком і IdP; cookies виглядають неконсистентно.

Корінна причина: невідповідні прапори SameSite/Secure для потоку; змішані HTTP/HTTPS; різниця в блокуванні сторонніх cookie.

Виправлення: встановіть Secure і відповідний SameSite; забезпечте канонічний HTTPS; уникати залежності від сторонніх cookie, де можливо.

4) «Завантаження працює в IE, але не в сучасних браузерах»

Симптоми: файл відкривається в одному середовищі, деінде — відмовляється або пошкоджений.

Корінна причина: некоректний content‑type, content‑disposition або припущення щодо newline/кодування; застаріла поведінка толерована старими клієнтами.

Виправлення: виправте заголовки сервера; тестуйте з кількома клієнтами; розглядайте доставку файлів як API з явними контрактами.

5) «Випадкові JS‑помилки після «поліпшення продуктивності»»

Симптоми: періодичні undefined‑змінні; лише на деяких десктопах.

Корінна причина: зміни таймінгу виявляють умови гонки з інжектованими скриптами, розширеннями або застарілими shim‑ами.

Виправлення: прибрати залежність від глобалів; детермінована ініціалізація; надсилати клієнтські помилки на сервер для кореляції; документувати підтримувані розширення/інструменти безпеки.

6) «Постраждали лише внутрішні користувачі»

Симптоми: зовнішній трафік у порядку; внутрішня мережа зламана; та ж версія браузера.

Корінна причина: split‑horizon DNS, переписування проксі, SSL‑інспекція або закешований проміжний контент.

Виправлення: трасуйте шлях запиту; тестуйте зсередини мережі; порівнюйте DNS і ланцюги сертифікатів; координуйтеся з мережевими/безпековими командами з доказами, а не відчуттями.

Чеклісти / покроковий план

Покроково: коли спрацьовує інцидент, специфічний для браузера

1. Закріпіть звіт: зафіксуйте версію браузера, ОС, мережу (VPN? проксі?) і точний URL‑шлях. Якщо користувач не може надати — відтворіть зі скринкастом.
2. Перевірте здоров’я сервера: рівні помилок і upstream 5xx на ураженому ендпойнті. Не ганяйтеся за фантомами клієнта, поки ваш API повертає 502.
3. Захопіть байти: збережіть заголовки й тіло для HTML і основних бандлів. Підтвердіть MIME‑типи і поведінку стиснення.
4. Порівняйте транспорт: версія TLS, HTTP/2 vs HTTP/1.1, ланцюг редиректів і шлях довіри сертифікатів.
5. Перевірте кешування: валідуйте хешовані імена файлів, cache‑control і чи проміжні елементи можуть порушувати Vary.
6. Відтворіть детерміновано: використайте headless‑прогін у CI принаймні для одного Chromium і одного Gecko/WebKit. Якщо залучено корпоративний IE‑режим — відтворіть у контрольованій VM або спеціальному тестовому середовищі.
7. Оберіть пом’якшення: блокуйте непідтримувані клієнти, випустіть сумісну збірку або відкотіть ризикову зміну. Оберіть найменшу зміну, що зупиняє кровотечу.
8. Задокументуйте контракт: оновіть матрицю підтримуваних браузерів і додайте регресійний тест, який би це впіймав.

Покроково: як зменшити ризик «браузерної війни» в організації

• Припиніть UA‑сніфінг для логіки. Використовуйте виявлення можливостей і прогресивне покращення.
• Відправляйте ресурси з хешованими іменами. Невідповорність кешування: незмінні імена з хешем, короткий TTL для HTML.
• Зробіть CSP практичним. Нонси/хеші, без сплесків inline‑скриптів і канал репортування порушень.
• Ведіть бюджет сумісності. Визначте, які застарілі клієнти ви підтримуєте і як довго. Проставте дати для винятків.
• Тестуйте як продакшен. Включіть шляхи з проксі/VPN і сценарії SSL‑інспекції, якщо ваші користувачі там живуть.
• Зберігайте «байти на дроті». Знімки й дифи за реліз. Це нудно, але неймовірно ефективно.

Питання й відповіді (FAQ)

Чи «винайшов» веб Netscape?

Ні. Веб існував до Netscape. Netscape індустріалізував перегляд і прискорив комерціалізацію,
а потім боровся за формування платформи в міру її розширення.

Чи був вирішальним ходом бандлінг Internet Explorer з Windows?

Це була вирішальна перевага в дистрибуції. Але вона також створила довгострокову крихкість: підприємства стандартизувалися на
версії браузера й потім не могли оновлювати без ламання внутрішніх додатків.

Чому з’явилося «best viewed in»?

Тому що покриття стандартів було непослідовним, а вендорні API були спокусливими. Команди орієнтувалися на цільовий рантайм,
щоб зменшити витрати підтримки — часто обмінюючи короткострокову передбачуваність на довгострокову залежність.

Чи ActiveX — головна причина поганої репутації безпеки IE?

ActiveX — велика частина причин, головно тому, що він розмив межу між веб‑контентом і локальним виконанням. Але репутація безпеки — завжди мультифакторна:
частота патчів, екосистема, значення за замовчуванням і корпоративні обмеження.

Який сучасний еквівалент браузерних війн?

Це менше про одного вендора проти іншого і більше про монокультуру рушіїв, обмеження мобільних платформ і
застосування політик (запобігання трекінгу, правила cookie, екосистеми розширень). Механізм відмови — фрагментація поведінки — нікуди не зник.

Чи варто сьогодні хвилюватися про IE6 або IE‑mode?

Якщо ви керуєте внутрішніми додатками в великих організаціях: так, тому що «IE‑mode» може підтримувати старі поведінки документа.
Турбуватися не означає підтримувати вічно; це означає виявляти, визначати політику і планувати вихід.

Чи завжди правильним є дотримання стандартів?

Практично — так, якщо ви хочете портативності й передбачуваних операцій. Але вам все одно потрібні тести. Стандарти зменшують
варіативність; вони не усувають баги в реалізаціях.

Який найефективніший спосіб запобігти браузерним‑специфічним інцидентам?

Розглядайте клієнт як частину продакшену: автоматизуйте крос‑движкові тести для критичних потоків і зберігайте артефакти
(заголовки + тіла), щоб ви могли віддифити «що змінилося» без здогадів.

Чому команди продовжують робити ті самі помилки?

Тому що стимули винагороджують випуск фіч і карають за інциденти пізніше. Лікування — впровадити перевірки сумісності в pipeline постачання,
щоб робити правильне було дешевше, ніж пояснювати провал.

Висновок: практичні наступні кроки

Netscape проти Internet Explorer були не просто суперечкою; це було підліткове десятиліття вебу: неряшливе, швидке й повне рішень, прийнятих під тиском.
Веб вижив тому, що стандарти поступово перемогли, і тому, що інженери побудували шари сумісності, коли реальність відмовлялася вестися.

Якщо ви сьогодні керуєте продакшен‑системами, візьміть ці операційні уроки й пропустіть ностальгію:

1. Інструментуйте межу клієнта. Захоплюйте заголовки, редиректи й JS‑помилки з достатнім контекстом, щоб згрупувати за движком і мережею.
2. Зробіть сумісність явною. Опублікуйте матрицю підтримуваних браузерів і примусьте її виявленням і повідомленнями.
3. Автоматизуйте крос‑браузерні перевірки. Критичні потоки мають детерміновані тести в CI, а не «хтось спробував на ноуті».
4. Проектуйте вихід. Якщо ви приймаєте вендор‑специфічну фічу, задокументуйте, як ви її видалите. Майбутнє ви не згадає, чому це було «тимчасово».

Браузерні війни закінчилися, по суті. Операційні наслідки — ні. Веб усе ще розподілена система, де найменш передбачуваний вузол — це рантайм користувача, який ви не контролюєте.
Ставтеся до нього відповідно.