Кросбраузерна верстка (Chrome, Firefox, Safari, Edge)

Верстка кросбраузерна (Chrome, Firefox, Safari, Edge)

Ви зробили ідеальний макет у Figma, зверстали на React, а клієнт відкриває сайт на Safari — і все роз'їхалося. Знайома історія? Ми стикаємося з цим щодня. За роки роботи накопичили цілу колекцію сюрпризів: від відсутності підтримки CSS Grid subgrid до дивної поведінки scroll-behavior. Кросбраузерна верстка — це не про "однаково", а про "однаково добре" в Chrome, Firefox, Safari та Edge. І якщо з Blink-браузерами проблем майже нема, то Safari (особливо на iOS) потребує особливої уваги.

Чому виникає кросбраузерна несумісність?

Основна причина — різні двигуни рендерингу. Chrome та Edge використовують Blink, Firefox — Gecko, Safari — WebKit. Кожен двигун по-своєму інтерпретує CSS-специфікації, особливо в частині сучасних можливостей. Наприклад, CSS Grid subgrid з'явився у всіх браузерах, але Safari підтримує його тільки з версії 16. А gap у flexbox — у Safari до версії 14.1 його просто нема. Навіть парсинг дат у JavaScript відрізняється: Safari не сприймає дати у форматі YYYY-MM-DD, вимагаючи ISO 8601 або роздільники /. Згідно з MDN Web Docs, ці розбіжності викликані різною швидкістю впровадження стандартів.

Які проблеми ми вирішуємо найчастіше

Наш досвід показує, що 70% інцидентів пов'язані з Safari/iOS. Ось типові розбіжності:

• CSS Grid та Flexbox: Safari на старих версіях не підтримує gap у flexbox, а subgrid — до 16 версії.
• Скрол та анімації: scroll-behavior: smooth у Safari не працює без @media (prefers-reduced-motion: no-preference).
• Позиціонування: position: sticky у таблицях веде себе по-різному.
• Кастомні форми: Firefox вимагає -moz-appearance, Safari — свої вендорні префікси.
• Шрифти та рендеринг: різна товщина шрифтів, кернінг, згладжування.

Ці проблеми призводять до додаткових витрат на доопрацювання. Наша практика показує, що своєчасне тестування та фікси дозволяють заощадити до 40% бюджету підтримки. Наприклад, своєчасна кросбраузерна адаптація дозволяє заощадити до €5000 на рік на виправленні помилок.

Як ми досягаємо єдиного відображення?

Використовуємо триетапний підхід:

1. Перший етап — розробка із запасом. У Chrome пишемо основну верстку, але одразу перевіряємо підтримку CSS-властивостей через caniuse.com та MDN-документацію. Для сумнівних фіч додаємо поліфіли або fallback.
2. Другий етап — ручне тестування в Firefox, Safari (macOS + iOS Simulator) та Edge. Займає від 1 до 2 днів для 5–15 сторінок.
3. Третій етап — автоматизація за допомогою Playwright. Налаштовуємо multi-browser конфігурацію, яка проганяє всі сценарії в Chromium, Firefox, WebKit та мобільному Safari. Наш Playwright-скрипт виконує тестування в 5 разів швидше за ручне: 10 сторінок перевіряє за 2 години, а ручне тестування зайняло б 10 годин.

// playwright.config.ts
export default defineConfig({
  projects: [
    { name: 'chromium', use: { ...devices['Desktop Chrome'] } },
    { name: 'firefox', use: { ...devices['Desktop Firefox'] } },
    { name: 'webkit', use: { ...devices['Desktop Safari'] } },
    { name: 'Mobile Safari', use: { ...devices['iPhone 14'] } },
  ],
});

Що входить у нашу роботу з кросбраузерної верстки

Ми не просто правимо CSS. У послугу включено:

• Перевірка верстки на 4 покоління браузерів (останні 2 мажорні версії кожного).
• Створення конфігурації Browserslist для PostCSS та Babel.
• Написання поліфілів для відсутніх функцій.
• Тестування на реальних пристроях (iPad, iPhone, Android) через BrowserStack.
• Документування знайдених розбіжностей та їх виправлень.
• Гарантія на результат — якщо після здачі правок з'явиться баг на підтримуваному браузері, чинимо безкоштовно протягом 30 днів.

Процес роботи

1. Аудит поточної верстки — аналізуємо, які браузери підтримуються, складаємо матрицю сумісності.
2. Правки CSS/JS — вносимо зміни по кожній знайденій розбіжності.
3. Тестування — ручне + автоматизоване (Playwright).
4. Фіксація багів — якщо щось зламалося, виправляємо і повторно тестуємо.
5. Здача — надаємо звіт про виконану роботу.

Терміни та вартість

Для типового проекту (до 20 сторінок, статична верстка) кросбраузерне тестування та правки займають від 1 до 3 робочих днів. Вартість — від €200 до €500 залежно від складності. Для складних SPA з анімаціями — до 5 днів, вартість від €800. Точна ціна визначається після аудиту.

Як уникнути проблем на старті?

Використовуйте CSS-методології (наприклад, BEM) та уникайте вендоро-залежних властивостей без fallback. Заздалегідь налаштуйте Browserslist:

// .browserslistrc
> 0.5%
last 2 versions
not dead
not IE 11

Це автоматично додасть префікси через Autoprefixer та транспіляцію через Babel.

Таблиця поширених розбіжностей

Порівняння підходів до тестування

Наші компетенції

У нас за плечима більше 150 комерційних проектів з обов'язковою кросбраузерною версткою. Працюємо з 2018 року, маємо досвід понад 6 років. Ми постійно моніторимо оновлення браузерів та специфікацій, щоб ваша верстка працювала стабільно. Отримайте консультацію — допоможемо з будь-якими браузерними проблемами.

Чому юніт-тести важливі, але не панацея?

Баг, знайдений юніт-тестом, коштує хвилини виправлення. Той самий баг у продакшені — години інциденту, компенсації та втрата довіри. На проекті інтернет-магазину помилка в розрахунку знижки пройшла ручне тестування, потрапила в прод і за 4 години обробила 37 замовлень за нульовою ціною. Автотест на граничні випадки розрахунку зловив би її при першому ж push. Оцініть свій проект — ми проведемо аудит поточного покриття і дамо рекомендації.

Jest — стандарт для JavaScript/TypeScript, але юніт-тести виправдані тільки там, де є ізольована логіка: функції трансформації, валідатори, бізнес-правила, утиліти. Тестувати React-компоненти через Jest + Testing Library правильно для поведінкових тестів: «кнопка з'являється після завантаження», «форма показує помилку при порожньому email». Снепшот-тести (toMatchSnapshot) — пастка: вони ламаються при будь-якій зміні верстки і стають шумом, який розробники оновлюють не дивлячись. Покриття коду (code coverage) — погана метрика якості: 80% coverage можна отримати тестами, які нічого не перевіряють. Coverage показує, що код виконався, а не те, що він працює правильно.

Vitest як альтернатива Jest для Vite-проектів: в 10–20 разів швидше завдяки нативним ES modules без трансформації через Babel. Для монорепозиторіїв з тисячами тестів різниця у швидкості відчутна. Детальніше про юніт-тестування.

Як налаштувати E2E тести, які не будуть flaky?

Playwright обійшов Cypress за ключовими параметрами: нативна підтримка multi-tab, multi-origin, iframe; паралельне виконання на рівні тестів; WebKit, Firefox, Chromium з коробки; немає iframe для додатку — тести працюють в реальному браузері.

Playwright codegen записує дії та генерує тест — хороша точка старту, але згенерований код потрібно рефакторити. Локатори за text content крихкі: getByRole('button', { name: 'Оформить заказ' }) — стійкіше, ніж locator('.btn-primary').

Page Object Model — стандарт організації E2E тестів. Кожна сторінка — окремий клас з методами замість прямих локаторів. Коли кнопка переїхала з хедера в сайдбар — міняємо в одному місці, не шукаємо по всіх тестах.

// Погано
await page.click('#submit');
await page.waitForTimeout(2000);
await expect(page.locator('.success')).toBeVisible();

// Добре
await page.click('#submit');
await page.waitForResponse(resp =>
  resp.url().includes('/api/orders') && resp.status() === 201
);
await expect(page.getByRole('alert', { name: /заказ создан/i })).toBeVisible();

Наші інженери гарантують стабільність тестів у CI. Документація Playwright — основний інструмент на проектах з мільйонами користувачів.

Навантажувальне тестування з k6

k6 — інструмент для навантажувального тестування з JavaScript API. Сценарії пишуться як код, версіонуються в git, запускаються в CI. Три основних сценарії:

• Spike test — різке зростання навантаження: 0 → 1000 користувачів за 30 секунд. Імітує запуск рекламної кампанії. Показує здатність системи реагувати на піки.
• Soak test — стабільне навантаження на 2–4 години. Виявляє memory leaks, connection pool exhaustion, деградацію продуктивності.
• Stress test — навантаження вище розрахункової (150–200% від очікуваного піку). Показує точку відмови та graceful degradation.

Порогові значення:

thresholds: {
  http_req_duration: ['p95<500', 'p99<1000'],
  http_req_failed: ['rate<0.01'],
}

p95 < 500ms означає: 95% запитів відповідають швидше півсекунди. Якщо поріг не виконується — k6 завершується з кодом помилки, CI-пайплайн падає.

На одному проекті інтернет-магазину ми виявили деградацію API на 4-й годині тесту: p95 зріс з 200ms до 2s через витік з'єднань. Після оптимізації клієнт заощадив значну суму на інцидентах та зайвих ресурсах. Отримайте аналогічний аудит вашого проекту — замовте навантажувальне тестування.

Як Core Web Vitals впливають на ранжування?

Google використовує Core Web Vitals у ранжуванні. Lighthouse CLI в CI-пайплайні: при кожному деплої перевіряємо, що LCP < 2.5s, CLS < 0.1, INP < 200ms. Детальніше про веб-продуктивність. Реальні проблеми, які Lighthouse знаходить:

• Hero image без атрибутів width/height: CLS 0.35 при завантаженні.
• JavaScript-бандл 2.1MB синхронно блокує парсинг: INP 450ms.
• Шрифти без font-display: swap: невидимий текст до завантаження шрифту (FOIT).
• Неоптимізований hero image 4MB: LCP 8.2s.

Lighthouse CI (lhci) зберігає історію метрик і надсилає коментар до PR з деградацією. За даними Google, 53% користувачів залишають сайт при завантаженні довше 3 секунд — наші тести запобігають таким втратам.

Піраміда тестування в проекті

Що входить в роботу?

• Аудит поточного покриття та визначення критичних user flows.
• Написання unit-тестів для ключової бізнес-логіки, інтеграційних тестів для API, E2E для сценаріїв користувача.
• Налаштування паралельного виконання в CI (sharded workers для Playwright).
• Навантажувальне тестування зі звітом та рекомендаціями.
• Документація за тест-кейсами, навчання вашої команди роботі з тестами.
• Гарантійна підтримка 1 місяць після впровадження.

Процес роботи

1. Аналітика — аудит поточного тестування, виявлення слабких місць, визначення пріоритетів.
2. Проектування — вибір інструментів, написання тест-плану, узгодження.
3. Реалізація — написання тестів, інтеграція в CI.
4. Тестування — прогін всіх рівнів, аналіз результатів, виправлення помилок.
5. Деплой — запуск в прод, моніторинг метрик, навчання команди.

Терміни

Налаштування повного тест-пайплайна (Jest + Playwright + k6 + Lighthouse CI) з нуля: 2–4 тижні. Покриття E2E-тестами існуючого проекту (20–30 сценаріїв): 3–6 тижнів. Навантажувальне тестування зі звітом та рекомендаціями: 1–2 тижні. Вартість розраховується індивідуально після аудиту.

Готові обговорити ваш проект? Залиште заявку — ми проведемо аудит поточного тестування безкоштовно і запропонуємо план з економією до 60% часу на інциденти. Отримайте консультацію з тестування веб-додатків — напишіть нам.