Архітектура браузера й рендеринг

Що відбувається з моменту, коли браузер отримав HTML, і до появи пікселів на екрані?

Це не одна дія, а фіксований конвеєр етапів. Парсер перетворює розмітку на DOM покроково: байти стають токенами, токени — вузлами, вузли зшиваються в дерево. Стилі окремо збираються в CSSOM. З двох дерев народжується дерево рендерингу — той самий вміст, але вже зі стилями і лише ті вузли, які реально малюватимуться. Далі layout рахує геометрію: скільки місця займає кожен блок і в якій точці екрана він опиниться. Потім paint заповнює пікселі — текст, фони, рамки, тіні, — і саме всередині цього етапу живе растеризація. Завершує composite: намальовані шари складаються на екран у правильному порядку. Цю дорогу до першої появи пікселів називають критичним шляхом рендерингу (critical rendering path). Для AQA із цього випливає головне: «вузол уже в DOM» — найраніша точка конвеєра, а отже найслабша гарантія того, що з елементом можна працювати.

Чим рушій рендерингу відрізняється від JS-рушія?

Поділ обовʼязків простий: рушій рендерингу (rendering engine) відповідає за структуру й вигляд, JS-рушій (JavaScript engine) — за поведінку. Перший розбирає розмітку та стилі, складає з них дерева, рахує геометрію й виводить пікселі; другий виконує код, який ці дерева потім переписує. Blink, Gecko та WebKit — це саме рушії рендерингу, а не браузери; словосполучення «рушій браузера» позначає ту саму сутність, третьої тут немає. Ключова деталь, яку рідко називають: обидва працюють в одному головному потоці, тож виконання скрипта й побудова сторінки не йдуть паралельно — вони чергуються. Звідси практичний наслідок: важкий синхронний JavaScript не просто «повільний», він на цей час спиняє рендеринг. Плутанина в цьому місці породжує хибний діагноз «треба інший селектор» там, де насправді сторінка ще не встигла перебудуватися.

Чому CSS називають ресурсом, що блокує рендеринг?

Тому що до обробки всього набору стилів підсумковий вигляд елемента невідомий: правило, яке приїде останнім, має право перекрити все попереднє. Якби браузер малював по дорозі, користувач бачив би спалах нестилізованого вмісту, а потім стрибок верстки. Тому браузер тримає показ, доки CSSOM не зібрано повністю — і саме цим CSSOM відрізняється від DOM, який будується частинами й не чекає на кінець файлу. Побічний ефект неочевидний: повільний CSS затримує ще й скрипти, що йдуть після нього. Для тестувальника це пояснює білий екран на повільній мережі краще, ніж «щось гальмує»: спершу дивимося, чи не тягнеться довго якийсь стильовий файл, і лише потім шукаємо винних у JS.

Чим async відрізняється від defer і чому це питання ставлять AQA, а не тільки фронтендерам?

Звичайний <script> без атрибутів зупиняє парсинг HTML: парсер мусить зачекати, бо скрипт здатен дописати в документ через document.write і змінити те, що збиралися розбирати далі. Обидва атрибути це блокування знімають, але по-різному. З async парсинг не спиняється, а сам файл виконується щойно догрузиться — момент і порядок відносно інших скриптів не гарантовані. З defer парсинг теж не спиняється, але виконання відкладається до кінця розбору документа, зі збереженням порядку, у якому скрипти оголошені, і перед DOMContentLoaded. Для автоматизації різниця не академічна: усе, що залежить від async-скрипта, гоночне за побудовою, тобто його готовність не привʼязана до жодного стабільного моменту. Такий флак ловлять як дефект і синхронізуються з прикладним сигналом, а не «лікують» його паузою в тесті.

Чим DOMContentLoaded відрізняється від load і чому жодна з цих подій не є «сторінка готова»?

DOMContentLoaded спрацьовує в момент, коли розбір HTML завершено, а defer-скрипти вже відпрацювали. Зображень, підфреймів та async-скриптів вона свідомо не дожидається. load приходить пізніше — після того, як довантажилися всі ресурси сторінки. Спокуса прив'язати очікування до load виглядає безпечною, а насправді вона груба в обидва боки: сторінка часто стає інтерактивною задовго до цієї події, а буває й навпаки — після load екран ще домальовується даними з відповідей API. Тому обидві події описують стан завантаження документа, а не стан застосунку. У тесті орієнтир інший: чекати треба на прикладний сигнал — конкретний елемент, конкретний текст, конкретну відповідь мережі.

Що таке дерево рендерингу і чим у ньому відрізняються display: none та visibility: hidden?

Дерево рендерингу — результат поєднання DOM і CSSOM: вміст зі стилями, причому тільки ті вузли, які будуть намальовані. Саме тут ховається асиметрія, яку AQA зобовʼязаний памʼятати. Вузол із display: none до дерева рендерингу не потрапляє взагалі: у DOM він далі є, з JavaScript до нього можна дотягнутися, але жодної геометрії в нього немає. Елемент із visibility: hidden у дереві присутній: він займає своє місце в потоці, просто не показується. Практично це два різні діагнози при падінні тесту: у першому випадку елемента фізично немає на екрані і місце під ним не зарезервоване, у другому верстка зсунута не буде, а клік усе одно не пройде. І окремо памʼятайте, що ані те, ані інше не збігається з opacity: 0 — про нього окреме питання нижче.

Що таке reflow і чому він дорожчий за repaint?

Reflow — це повторний прогін етапу layout, тобто перерахунок геометрії сторінки. Він запускається щоразу, коли змінюється дерево рендерингу: додалися чи зникли вузли, змінився вміст, оновилися властивості блокової моделі. Дорогий він через каскадність: зсув одного елемента посуває сусідів, ті — своїх, і перерахунок розповзається на сотні вузлів. Repaint — це перемальовування без зміни геометрії, наприклад нового кольору чи фону; він теж не безкоштовний, але коштує помітно менше, бо етап layout пропускається. Для тестувальника з цього виростає практична річ: сторінка, яка під час завантаження щоразу перераховує геометрію, дає «стрибучі» елементи, а клік у момент стрибка або не потрапляє, або потрапляє не туди. Саме тому інструменти автоматизації перед дією чекають, поки елемент перестане рухатися.

Чому в анімаціях радять transform і opacity, а не top і left?

Тому що не кожна зміна проганяє конвеєр повністю — проходів насправді три. Зміна геометрії тягне повний ланцюг: обчислення стилів, layout, paint, composite. Зміна властивості, яка на геометрію не впливає (умовно «тільки-paint»), пропускає layout. А є клас змін, яким не потрібні ні layout, ні paint, — вони йдуть одразу на композитинг. Саме до нього належать transform і opacity, і тому анімації на них тримають плавність, тоді як анімація top/left перераховує геометрію в кожному кадрі. Окремий шар для елемента замовляють підказкою will-change, і платять за нього памʼяттю GPU — тому розставляють її точково, а не всюди. Для QA-ревʼю це готовий чекліст: побачив анімацію позиціонування замість трансформації — маєш кандидата на просідання кадрів.

Що таке примусовий синхронний layout і layout thrashing?

Примусовий синхронний layout (forced synchronous layout) виникає, коли код спершу щось записує в DOM, а одразу після цього читає геометрію. Браузер зобовʼязаний повернути актуальне значення, тому не може відкласти перерахунок до наступного кадру — він робить layout негайно, поза своїм звичайним ритмом. Одноразово це просто дорого; у циклі це перетворюється на layout thrashing, коли за один прохід відбуваються десятки таких примусових перерахунків і кадр не встигає намалюватися. Ліки прості за формулюванням: спершу зібрати всі читання, потім зробити всі записи, не перемішуючи. З боку тестування симптом упізнаваний — сторінка «залипає» саме під час дії, скрол ривками, а профайлер показує довгий блок layout там, де його ніхто не очікував.

Що таке область перегляду і чому в конфізі автотестів її фіксують?

Область перегляду (viewport) — та частина вікна, крізь яку користувач бачить сторінку. Її розмір визначається до розкладки, тож саме від нього залежить результат етапу layout і те, які брейкпоінти адаптиву спрацюють. Звідси й вимога до автотестів: розмір задають явно й свідомо, бо інакше один локатор на широкому та вузькому прогоні приведе до різних елементів — наприклад, до пункту меню в горизонтальній навігації або до його близнюка всередині бургер-меню. Плаваючий viewport дає найнеприємніший клас флаку: тест червоніє залежно від машини чи від того, у якому режимі стартував браузер. Тому в конфізі задають і розміри, і масштаб пікселів, а мобільні перевірки виносять в окремий проєкт із власним viewport, а не залишають на волю випадку.

Адаптив написано правильно, медіазапити на 640 пікселів є, але на мобільному вони не спрацьовують. Чому?

Найімовірніше, сторінці бракує метатега viewport. Частина вузьких екранів історично рендерить сторінку у віртуальній області перегляду, ширшій за фізичний екран — наприклад, у 980 пікселів на екрані 640, — а потім стискає готову картинку. Медіазапит порівнюється саме з цією віртуальною шириною, тож умова «640 і менше» не виконується ніколи, хоч CSS бездоганний. Лікує це <meta name="viewport"> з канонічним значенням width=device-width, initial-scale=1: воно каже браузеру рахувати розкладку від реальної ширини пристрою. Поруч живе друга типова плутанина: CSS-піксель і апаратний — різні одиниці, бо на щільних матрицях кожен CSS-піксель розкладається на кілька фізичних, і це співвідношення звуть DPR. Тому розмита растрова картинка на такому екрані означає не поломку рендерингу, а відсутність файлу під вищу роздільність.

Перевірка в режимі пристрою DevTools — це перевірка на мобільному?

Ні, і це питання перевіряє чесність кандидата з межами інструмента. Режим пристрою (device mode) симулює мобільну область перегляду й дозволяє обмежити ЦП та мережу, але код усе одно виконується на вашому компʼютері, вашим десктопним рушієм. Обмеження ЦП при цьому відносне до потужності саме цієї машини, тому цифри не переносяться між ноутбуками й тим паче не годяться як абсолютний критерій приймання. Що режим пристрою закриває добре: адаптивність — брейкпоінти він показує смугами над областю перегляду, тож їх видно, а не вгадують; і тип взаємодії — від обраного типу пристрою залежить, чи породжує дія сенсорні події, чи звичайні кліки, тож гіпотезу «на мобільному не працює свайп» перевіряють саме перемиканням типу. Чого він не закриває: реальне залізо, реальний рушій мобільного браузера й реальні мережеві умови. Тому в матриці він стоїть як швидкий фільтр перед прогоном на пристроях, а не замість нього.

Чим DOM відрізняється від дерева доступності?

Це два різні подання однієї сторінки. З розібраної розмітки браузер робить DOM, а поверх нього — самостійне дерево доступності (accessibility tree), яке через платформні API дістається допоміжним технологіям: ланцюжок виглядає як DOM, далі браузер, далі API доступності, далі читач екрана. Вузол у цьому дереві описують чотири властивості: імʼя (як до елемента звернутися), опис (додаткова інформація понад імʼя), роль (що це за річ — кнопка, список, панель навігації) і стан (позначено чи ні, згорнуто чи розгорнуто). Читач екрана озвучує імʼя разом із роллю: кнопку з підписом «OK» він вимовляє приблизно як «OK button». Практичний висновок: атрибут role змінює саме це дерево, тому перевіряти доступність по вкладці Elements недостатньо — у DevTools для цього є окрема панель. Кандидат, який цього не розділяє, зазвичай і локатори за роллю вважає «просто ще одним селектором».

Чому локатор за роллю й доступним іменем стабільніший за CSS-селектор?

Бо він спирається на властивості дерева доступності, а не на верстку. Перейменування CSS-класів, заміна контейнерів, рефакторинг сітки — усе це дерево доступності не змінює, доки роль і видимий підпис лишаються тими самими. Звідси стійкість: локатор ламається тоді, коли змінюється те, що бачить і чує користувач, а це чесний привід переглянути тест. Друга вигода бонусна: якщо елемент не має доступного імені або отримав неправильну роль, ви одночасно знайшли дефект доступності й майбутній нестабільний локатор — один симптом на дві проблеми. Найтиповіший приклад — клікабельний div без ролі: пошук за роллю кнопки його просто не знайде, і це правильна поведінка, а не обмеження інструмента.

Елемент є в DOM, але тест не може на нього клікнути. Твої дії?

Спершу я не чіпаю ні паузу, ні force, бо обидва глушать діагностику. Інструмент перед дією проганяє набір перевірок придатності (actionability) і тримає паузу, доки потрібні не стануть істинними; у падінні з таймаутом він називає ту, що не спрацювала, — це і є діагноз. Для кліку список такий: локатор дає рівно один збіг, а сам елемент видимий, стабільний, отримує події й увімкнений; для введення тексту додається ще «редагований» — тобто увімкнений і без readonly. Далі кожен пункт читається буквально: «більше одного збігу» — проблема локатора; «не видимий» — нульовий розмір або display: none; «не стабільний» — елемент ще їде в анімації; «не отримує події» — зверху лежить оверлей, модалка чи спливний тост; «не увімкнений» — атрибут disabled, батьківський fieldset або aria-disabled="true". Тільки перший пункт стосується самого локатора, решта — стану сторінки, і правити треба передумову тесту, а не селектор. Якщо жодна перевірка не скаржиться, а клік усе одно нічого не робить, наступна гіпотеза — заблокований головний потік або обробник, який ще не навісився після гідратації.

Чому opacity: 0 не робить елемент невидимим з погляду перевірок придатності?

Бо критерій видимості формулюється через геометрію, а не через те, чи бачить елемент людина. Видимим елемент рахується тоді, коли його bounding box непорожній, а обчислене значення visibility не дорівнює hidden. Нульова прозорість жодну з цих умов не порушує: коробка на місці, властивість visibility не змінена — тож елемент повністю придатний до дії. Невидимість дає інше: display: none або нульовий розмір. Це одна з найчастіших несподіванок на практиці: тест успішно «клікає» те, чого користувач фізично не бачить, і сценарій проходить там, де мав би впасти. Тому фейд-анімації й «приховані» через прозорість шари перевіряють явним асертом на потрібний стан, а не сподіванням, що інструмент сам відмовиться діяти.

Що насправді робить force: true і чому після нього тест зелений, а баг лишився?

Опція force вимикає необовʼязкові перевірки придатності — зокрема ту, що контролює, чи справді елемент отримує вказівникову подію в точці кліку. Тобто вона прибирає рівно той сигнал, який фіксував проблему: якщо кнопку перекривав оверлей або спливне повідомлення, з force клік «пройде», але реальний користувач у тій самій ситуації не клікне нічого. Падіння «елемент перехоплює вказівникові події» тому й корисне: воно вказує або на дефект UX, або на власну помилку тесту, який не дочекався закриття модалки. Правильна реакція — прибрати перешкоду в передумові: закрити тост, дочекатися зникнення оверлея, згорнути банер. force лишається інструментом для рідкісних свідомих випадків, а не універсальним засобом від червоного прогону — і в код-ревʼю тесту він має супроводжуватися поясненням, чому перевірку тут вимкнено навмисно.

Чому кросбраузерний дефект часто не видно в консолі й з чого починати його розбір?

Такі дефекти мовчазні за природою. Оголошення чи правило, якого рушій не знає, він просто викидає: застосування немає, повідомлення теж немає. Так само поводяться медіазапити, @font-face і блоки @supports, а нерозпізнані HTML-елементи трактуються як анонімні рядкові, тобто без будь-якої семантики. Тому «в консолі чисто» не означає «проблем немає» — перевіряти треба вигляд і поведінку. Три гіпотези закривають більшість випадків. Зник цілий блок стилів — шукайте невалідний селектор: у переліку через кому один зіпсований вимикає весь блок. Працює тільки в Chrome — пошукайте самотній -webkit--префікс, замість того щоб заводити задачу «підтримати Firefox». Вигляд правильний, а поведінка дивна — проженіть сторінку через валідатор W3C, бо DevTools віддає вже автовиправлену браузером структуру й ховає вихідні помилки HTML. Нові можливості підключають детекцією через @supports, а не префіксами навмання: префіксовані реалізації ніколи й не задумувалися як механізм для продакшену.

Чому баг верстки з Chrome майже завжди відтворюється в Edge, а в Safari — ні?

Бо матриця будується не за браузерами, а за рушіями. Chrome, Edge і Opera побудовані на Blink, тому баг розкладки, знайдений в одному з них, майже напевно відтвориться в решті: це один рушій, а не три незалежні перевірки. Firefox працює на Gecko, Safari — на WebKit, а на WebKit тримається й помітна частина мобільних браузерів, тому прогін на iOS покриває не одну клітинку матриці, а кілька. Окремий сюрприз — Trident: здається реліктом, проте режим IE в Edge його досі активує, тож корпоративний Edge цілком може малювати сторінку повз Blink. І остання деталь, яку рідко називають: різниця між рушіями не зводиться до CSS — Gecko, наприклад, містить і мережевий стек, і графічний, і віртуальну машину JavaScript, тож «кросбраузерний дефект» цілком може виявитися різницею в поведінці мережі чи виконання скриптів, а не розкладки.

Що означає «JavaScript у браузері однопотоковий» і як це виглядає з боку автотесту?

Однопотоковий саме JS-рушій: у кожен момент часу він виконує рівно один фрагмент коду. Браузер загалом однопотоковим не є — мережеві запити, таймери, декодування зображень обслуговують окремі механізми поза цим потоком. Наслідок болючий: доки виконується довгий синхронний код, не обробляються кліки, не рухаються анімації, не перемальовується сторінка й не запускаються відкладені колбеки. Звідси й найпоширеніший хибний баг-репорт: кнопку видно, а натиснути її неможливо. Тест у цій ситуації повідомить про неклікабельний елемент чи таймаут, хоча причина не у відсутності вузла, а в тому, що потік просто не дійшов до обробника. Лікується це на боці продукту: важку роботу розбивають на частини або виносять у Web Worker — окремий потік, який до DOM доступу не має. А діагностується в панелі продуктивності, де етапи конвеєра видно окремими записами; памʼятайте, що запис paint там уже включає растеризацію, тож шукати її окремим рядком марно.

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

Кейс 1. Клік не проходить: читаємо діагноз замість перебору селекторів

Тест падає на кнопці «Оплатити». Локатор коректний, елемент видно на скріншоті, у DOM він є. Спокуса — додати очікування на дві секунди або force: true, і прогін позеленіє. Спокуса помилкова: інструмент уже назвав причину в тексті падіння, її лишається прочитати.

Перед кожною дією виконується набір перевірок придатності, і повідомлення про таймаут вказує, яка саме не пройшла. Далі — переклад із мови інструмента на мову діагнозу.

Тільки перший рядок стосується самого локатора. Решта — про стан сторінки, тобто правити треба передумову тесту.

// Погано: пауза наосліп і маскування перевірки
await page.waitForTimeout(2000);
await page.getByRole('button', { name: 'Оплатити' }).click({ force: true });

// Теж погано: умовна гілка на isVisible() нічого не чекає й відповідає одразу,
// тож на швидкому прогоні банер «не побачать», і клік знову перехопить оверлей
const cookieBanner = page.getByRole('dialog', { name: 'Cookie' });
if (await cookieBanner.isVisible()) {
  await cookieBanner.getByRole('button', { name: 'Прийняти' }).click();
}

// Добре: банера немає за передумовою — згоду кладемо в контекст до відкриття сторінки
await page.context().addCookies([
  { name: 'cookie_consent', value: 'accepted', domain: 'shop.example', path: '/' },
]);
await page.goto('/checkout');

const payButton = page.getByRole('button', { name: 'Оплатити' });
await expect(payButton).toBeEnabled();
await payButton.click();

Що дивитися і чому:

• opacity: 0 не рятує від кліку. Видимість визначається геометрією: непорожній bounding box і відсутність обчисленого visibility: hidden. Прозорий елемент обидві умови виконує, тож тест спокійно «клікне» те, чого користувач не бачить. Якщо сценарій залежить від завершення фейду — асертіть кінцевий стан явно, а не сподівайтеся, що інструмент відмовиться діяти.
• Оверлей ловиться саме перевіркою «отримує події». У DevTools це підтверджується за секунду: наведіть курсор на точку кліку й подивіться в Elements, який вузол підсвітився. Якщо це не ваша кнопка, а div з тостом — діагноз закритий, і він не про локатор.
• Умовна гілка if (await …isVisible()) — це не передумова, а друга гонка. isVisible() не чекає жодної секунди: він перевіряє локатор і повертає відповідь одразу. На швидкому прогоні банер ще не встиг зʼявитися, гілка не спрацює — і клік перехопить оверлей, який ви «вже закрили». Передумова має бути детермінованою: покласти згоду кукою в контекст (addCookies — її побачать усі сторінки контексту) або підняти тест уже з готовим станом (storageState, що переносить кукі, localStorage та IndexedDB).
• force вимикає необовʼязкові перевірки, зокрема цю саму. Тобто прибирає рівно той сигнал, який фіксував проблему. Тест зелений, оверлей на місці, користувач далі не клікне нічого — це приховування дефекту, а не полагоджений тест.
• Жодна перевірка не скаржиться, а клік нічого не робить. Тоді гіпотеза інша: або обробник ще не навісився після гідратації, або головний потік зайнятий довгим синхронним кодом і не дійшов до події. Перевіряється панеллю продуктивності — довгий суцільний блок JS у момент кліку видно одразу.

Кейс 2. Мобільний адаптив «не працює»: режим пристрою і фіксований viewport

Приходить баг: на телефоні макет десктопний, хоча медіазапити написані під 640 пікселів і на звуженому вікні Chrome усе перемикається правильно. Це класика, і причина зазвичай не в CSS.

Порядок перевірки:

1. Звузити вікно десктопного браузера — адаптив спрацював. Отже, самі медіазапити живі.
2. Увімкнути режим пристрою й вибрати мобільний профіль. Смуги над областю перегляду показують брейкпоінти сторінки — їх видно, а не вгадують. Якщо на 640 смуга є, а стилі не перемикаються, дивимося глибше.
3. Подивитися в head документа наявність метатега viewport.

<!-- без цього рядка вузький екран може рендерити сторінку у віртуальному вікні,
     ширшому за фізичне, і медіазапит на 640 не спрацює ніколи -->
<meta name="viewport" content="width=device-width, initial-scale=1" />

Далі — таблиця рішень для найчастіших мобільних симптомів.

// playwright.config.ts — розмір області перегляду має бути свідомим рішенням,
// інакше один локатор на різних прогонах веде до різних елементів
export default defineConfig({
  projects: [
    {
      name: 'desktop',
      use: { viewport: { width: 1280, height: 720 }, deviceScaleFactor: 1 },
    },
    {
      name: 'mobile-web',
      use: { ...devices['iPhone 13'] },
    },
  ],
});

Що дивитися і чому:

• Розмір області перегляду обчислюється до розкладки. Тому це не косметика, а вхідний параметр етапу layout: змінили ширину — змінилася геометрія, а разом із нею й те, який елемент опиниться під локатором. Пункт меню в горизонтальній навігації та його близнюк усередині бургер-меню — типова пара, на якій це вилазить.
• Режим пристрою — наближення першого порядку. Він чесно закриває адаптивність і тип подій, але код усе одно виконується вашим десктопним рушієм на вашому залізі. У критерії приймання цифри звідси не переносять; для перевірки мобільного рушія потрібен прогін на реальному пристрої або хоча б на WebKit.
• Мобільний проєкт у конфізі — не «те саме, але вужче». Разом із розміром змінюється й тип пристрою, а від нього залежить, чи породжує взаємодія сенсорні події, чи кліки — тож сценарії, писані під мишу, там перевіряють окремо, а не переносять як є.

Кейс 3. У Safari блок поїхав, у консолі тиша

Верстка розсипалася тільки на Safari. Розробник відкриває консоль, бачить нуль помилок і пише «не відтворюється». Насправді тиша тут — не доказ, а симптом: нерозпізнане CSS-оголошення чи правило браузер мовчки пропускає, без застосування й без запису в журнал. Так само поводяться медіазапити, @font-face і блоки @supports, а нерозпізнані HTML-елементи трактуються як анонімні рядкові, тобто без семантики.

Тріаж у три гіпотези, від найдешевшої:

Мінімальна перевірка на рівні матриці:

// той самий сценарій на трьох рушіях; Chrome і Edge — це один Blink,
// тож окремий рядок під Edge дасть майже ту саму інформацію
export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
  ],
});

Що дивитися і чому:

• Матриця будується за рушіями, а не за назвами браузерів. Chrome, Edge і Opera побудовані на Blink, тому баг розкладки з одного майже напевно відтвориться в решті. Firefox стоїть на Gecko, Safari — на WebKit, а на WebKit тримається й помітна частина мобільних браузерів, тому прогін на iOS покриває кілька клітинок матриці одразу. Окремий сюрприз — режим IE в Edge: під ним корпоративний браузер малює сторінку через Trident, тобто повз Blink.
• Кросбраузерний дефект не обовʼязково про CSS. У складі рушія живуть і мережевий стек, і графічний, і віртуальна машина JavaScript — тож «поїхала верстка» іноді виявляється різницею в поведінці мережі чи виконання скриптів. Якщо на одному рушії блок не намальовано взагалі, спершу перевірте, чи прийшли всі відповіді, а не тільки стилі.
• Скріншот-порівняння тут корисніше за асерт на текст. Мовчазний дефект стилів не змінює ані DOM, ані вміст, тож функціональний тест лишиться зеленим — ловить його саме візуальна перевірка або асерт на конкретну обчислену властивість.
• Нову можливість підключають детекцією, а не префіксом. Блок @supports дає керовану поведінку на рушії, який фічі не має; префіксовані реалізації для продакшену ніколи й не призначалися, тож ставка на них — відкладений баг, а не сумісність.

Підсистеми браузера і два рушії

• Знаю різницю між рушієм рендерингу (структура й вигляд) і JS-рушієм (поведінка) та памʼятаю, що «рушій браузера» — друга назва першого, а не третя сутність.
• Можу пояснити, чому обидва живуть в одному головному потоці й чому через це довгий синхронний JavaScript не «гальмує», а спиняє рендеринг; памʼятаю, що однопотоковий саме JS-рушій, а не браузер, і як заблокований потік виглядає з боку тесту (намальована, але «мертва» кнопка, неклікабельний елемент, таймаут).

Конвеєр рендерингу

• Можу назвати конвеєр у правильному порядку: DOM і CSSOM → дерево рендерингу → layout → paint → composite, і знаю, що вся дорога до першого показу зветься критичним шляхом рендерингу.
• Знаю різницю display: none vs visibility: hidden у дереві рендерингу: перший з дерева випадає й геометрії не має, другий у дереві лишається й місце займає.
• Памʼятаю, що растеризація живе всередині paint, а не composite, і що запис paint у панелі продуктивності вже враховує її.

Критичний шлях: що блокує показ

• Можу пояснити, чому CSS блокує рендеринг (пізніше правило каскаду перекриває раніше, тож потрібен увесь набір) і чому повільний стильовий файл затримує ще й скрипти після себе — на відміну від DOM, який будується частинами.
• Знаю, чому звичайний <script> зупиняє парсинг HTML, і чим від нього відрізняються async та defer за трьома осями: блокування парсера, момент виконання, порядок — а також чому async робить залежну поведінку гоночною й дає законний флак.
• Знаю різницю DOMContentLoaded vs load і чого перша НЕ чекає (зображення, підфрейми, async-скрипти), а чому друга надто груба як сигнал готовності для тесту.

Reflow, repaint і композитинг

• Можу пояснити, чому reflow дорожчий за repaint (перерахунок геометрії каскадний), і назвати три скорочені проходи конвеєра, включно з прямим шляхом у композитинг для transform та opacity; памʼятаю, що will-change коштує памʼяті GPU.
• Можу пояснити примусовий синхронний layout і layout thrashing та правило «спершу всі читання, потім усі записи».

Область перегляду й режим пристрою

• Розумію, що розмір області перегляду обчислюється до розкладки, тож від нього залежать і геометрія, і брейкпоінти — і тому в автотестах його фіксують, інакше один локатор на різних прогонах веде до різних елементів.
• Знаю проблему віртуальної області перегляду й навіщо існує <meta name="viewport"> зі значенням width=device-width, initial-scale=1.
• Не плутаю CSS-піксель з апаратним (DPR) і можу назвати межі режиму пристрою: брейкпоінти й тип подій він показує чесно, а залізо — ні, бо код виконується на моїй машині.

Дерево доступності

• Знаю різницю між DOM і деревом доступності, можу назвати чотири властивості вузла (імʼя, опис, роль, стан) і розумію, чому role перевіряють в окремій панелі, а не у вкладці Elements.
• Можу пояснити, чому локатор за роллю й доступним іменем не залежить від верстки і чому його поломка часто означає одночасно дефект доступності.

Готовність елемента до дії

• Знаю перелік перевірок придатності для кліку: рівно один збіг, видимий, стабільний, отримує події, увімкнений — і що для введення тексту додається «редагований».
• Памʼятаю точні означення: видимий — непорожній bounding box без обчисленого visibility: hidden (тому opacity: 0 вважається видимим); стабільний — та сама коробка щонайменше два кадри поспіль; отримує події — є ціллю вказівникової події в точці дії; увімкнений — без disabled, батьківського fieldset чи aria-disabled="true".
• Можу читати діагноз за перевіркою («більше одного збігу» — про локатор, решта — про стан сторінки), розумію, що саме вимикає force і чому падіння «елемент перехоплює вказівникові події» — корисний сигнал; памʼятаю межі автоочікування: прикладних станів воно не знає, і domcontentloaded тут не рятує.

Різні рушії й головний потік

• Знаю, який браузер на якому рушії (Blink — Chrome, Edge, Opera; Gecko — Firefox; WebKit — Safari і чимало мобільних; Trident досі живий через режим IE в Edge) і що різниця між рушіями не зводиться до CSS: у складі є й мережевий стек, і графічний, і віртуальна машина JavaScript.
• Памʼятаю мовчазність кросбраузерних дефектів і три гіпотези розбору: зник цілий блок стилів → невалідний селектор у переліку через кому; «працює тільки в Chrome» → самотній -webkit--префікс; дивна поведінка при правильному вигляді → валідатор W3C.