Аудит продуктивності, який ми робимо перед будь-яким редизайном

Команда приходить і каже: «Хочемо редизайн». Перше, що ми питаємо: «Ви виміряли, що насправді зламано?».

Близько 70% часу відповідь — ні. Сайт відчувається повільним, bounce rate високий, конверсія застрягла, і команда припускає, що редизайн це виправить. Іноді — так. Частіше — проблеми конкретні і вимірюваль, і редизайн без вимірювань виправить частину з них, поламавши інші.

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

Це те, що в аудиті, що він зазвичай знаходить, і реальний приклад того, що змінилось, коли ми його запустили.

Що ми вимірюємо

Сім речей, приблизно у такому порядку:

1. Lighthouse, lab data.

Lighthouse запускається у вашому браузері або через CI. Це синтетичний тест за контрольованих умов. Бали — не суть; суть — конкретні знахідки. Lighthouse каже:

• Core Web Vitals (LCP, INP, CLS) за симульованих умов
• Проблеми з оптимізацією зображень (неоптимізовані формати, завеликі зображення)
• Render-blocking ресурси
• Порушення доступності
• SEO-базис (відсутні мета, немає canonical тощо)
• Порушення best-practices (HTTPS-проблеми, помилки консолі, вразливі бібліотеки)

Ми запускаємо Lighthouse на головній і трьох-чотирьох інших ключових сторінках. Мобілка і десктоп. Уся штука займає тридцять хвилин.

2. CrUX, real-user data.

Chrome User Experience report. Метрики реальних користувачів, агреговані Google. Інше за Lighthouse: це те, що реальні користувачі відчувають, не те, що знаходить синтетичний тест у лабі.

Двоє часто не сходяться. Lighthouse каже, що LCP — 1.8s; CrUX каже, що 75-й перцентиль — 4.2s. Обидва правдиві. Lighthouse вимірює один пристрій у одній мережі. CrUX вимірює усіх, включно з юзером на Android 2017 у latentній 4G. CrUX — це цифра, що має значення для SEO і для чесного UX.

3. WebPageTest, waterfall analysis.

WebPageTest дає waterfall запитів. Видно точно, що завантажується, у якому порядку, з якими залежностями. Це там, де знаходять речі типу:

• Шрифти блокують рендеринг, бо preload-хінт відсутній
• 200KB JS-файл, що вантажиться на кожній сторінці, а використовується на одній
• Third-party скрипти додають 500ms до першого паінту
• Послідовні залежності, що мали б бути паралельними

Waterfall корисніший за будь-який Lighthouse-бал для розуміння, що насправді виправляти.

4. Bundle analysis.

Для JS-важких сайтів — аналіз JS-бандла. Що в ньому. Які бібліотеки великі. Що завантажується, але ніколи не використовується.

Ми використовуємо @next/bundle-analyzer для Next.js-сайтів, vite-bundle-visualizer для Vite. Вихід — treemap бандла. Часті знахідки:

• Moment.js, що відправляє 70KB, тоді як date-fns підійшла б
• Бібліотека графіків, забандлена на кожну сторінку, але використовується на одній
• Polyfill-и для браузерів, якими вже ніхто не користується
• Важка CMS-preview-бібліотека, забандлена у прод

5. Серверна продуктивність.

Для динамічних сайтів time-to-first-byte (TTFB) часто домінує над усім іншим. 1.5s TTFB означає, що сторінка не може бути швидкою, навіть якщо все клієнтське ідеальне.

Ми дивимось:

• Тайминг database-запитів (повільні запити у шляху запиту)
• Cache hit rate (Vercel Edge, Cloudflare, application cache)
• Частота cold-start на serverless
• Тиск пам'яті або CPU-сатурація на long-running серверах

Це та частина аудиту, що часто дивує клієнтів. Вони місяці оптимізували зображення і JS, але сторінка висить 800ms до того, як приходить один байт.

6. Поведінка мережі і CDN.

Де насправді знаходяться користувачі і звідки сервуються активи? Сайт, хостований у us-east-1, сервує європейських юзерів зі 150ms мережевої затримки на кожному запиті. CDN це сплющує; відсутність — поширена і виправна проблема.

Перевіряємо:

• Заголовки кешування статичних активів на CDN
• Поведінку image-CDN (чи /image.jpg?w=400 справді сервується з кешу?)
• HTML-кешування (більшість динамічних сторінок можна кешувати на 5-60 секунд, ніхто не помітить)

7. Сприйнята продуктивність.

Попередні метрики кількісні. Сприйнята продуктивність — якісна: чи сайт відчувається швидким? Чи є layout shift, що ловлять око? Чи loading-стан видимий достатньо довго, щоб різати? Чи інтеракції відчуваються відгукливими, чи є затримка між кліком і фідбеком?

Ми робимо це вручну. Відкриваємо сайт у свіжому браузері, тротлимо до mid-tier мобільного профілю, користуємось десять хвилин. Помічаємо, що відчувається не так.

Сприйнята продуктивність часто розходиться з виміряною. Сайт з відмінними Lighthouse-балами може досі відчуватись повільним через одну конкретну інтеракцію. Сайт з гіршими балами може відчуватись швидким, бо повільні частини — off-path для типового користувача.

Що аудит зазвичай знаходить

Паттерни, які бачимо повторно:

Hero-зображення — найбільша перформанс-ціна. Часто завантажується як завеликий JPG або PNG, без srcset, без priority-хінта. Перехід на WebP/AVIF, додавання srcset і додавання fetchpriority="high" зазвичай ріже 1-2 секунди з LCP на mid-tier мобільному.

Web-шрифти блокують рендеринг. Сторінка невидима 500-800ms, поки вантажиться кастомний шрифт. Фікс: font-display: swap (гірший FOUT, набагато кращий LCP) або system-fallback, що збігається з метриками кастомного шрифту достатньо близько, щоб уникнути layout shift.

Third-party скрипти додають багато ваги. Аналітика, чат-віджети, A/B-тести, customer support чати. Кожен — «лише маленький скрипт». Складіть — і у вас 800KB third-party-коду, що вантажиться на головній.

Бандл удвічі більший, ніж мав би. Moment.js, коли підійшла б date-fns. Lodash, імпортований як ціле, замість per function. UI-бібліотеки, імпортовані як цілі пакети замість named-імпортів. 30-хвилинний прохід з bundle analyser зазвичай ріже бандл на 30-50%.

TTFB поганий, і ніхто не знав. Команда оптимізувала фронтенд, але API, що сервує сторінку, забирає 800ms через відсутній індекс у database-запиті. Один індекс, один деплой, сайт удвічі швидший.

Немає CDN або CDN неправильно сконфігурований. Статичні активи сервуються з origin. Зображення не кешуються. CDN існує, але cache-заголовки неправильні, тож він не кешує нічого. Фікс: ревью cache-заголовків, виставлення правильно, спостереження, як кількість запитів на origin падає на 90%.

Реальний аудит і що змінилось

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

Ми зробили аудит замість редизайну. Знахідки у порядку імпакту:

1. Hero-зображення було 1.4MB PNG. WebP-версія — 180KB. LCP впав з 4.8s до 2.1s. Одна файлова заміна.
2. Кастомний шрифт вантажився без font-display: swap. Сторінка була невидимою 700ms, поки він вантажився. Додавання рядка значно скоротило час до першого вмісту.
3. У сайту був 600KB JS-бандл на кожній сторінці. Bundle-аналіз показав бібліотеку графіків, що використовувалась рівно на одній внутрішній адмін-сторінці. Code-split. Бандл впав до 220KB.
4. Індекс блогу робив окремий API-виклик на пост, щоб отримати інфу про автора. 30 постів — 31 запит. Об'єднали в один. Час завантаження сторінки індексу блогу впав з 3.2s до 0.9s.
5. У сайту не було CDN. Статичні активи сервувались з origin у регіоні, відмінному від більшості користувачів. Поставили Cloudflare попереду. Час завантаження активів покращився всюди.

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

Це аргумент за аудит. Близько 30% часу, коли ми аудитуємо сайт, результат — «редизайн не потрібен, виправте ці п'ять речей». Інші 70% — аудит показує, що пріоритизувати під час редизайну, тож редизайн реально виправляє проблему.

Коли пропустити аудит

Рідко, але буває:

• Сайт фундаментально зламаний архітектурно, і вимірюваний аудит просто підтвердив би те, що всі вже знають. Іноді WordPress із 47 плагінами не потребує аудиту; він потребує перебудови.
• Бренд змінився, і редизайн — з brand-причин, не perf-причин. Аудит усе ще корисний, але не блокуючий.
• Сайт настільки малий (одна лендінг-сторінка), що тридцятихвилинний Lighthouse-прогін — це і є весь аудит.

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

Що ви отримуєте з аудиту

Деліверейбл — це письмовий звіт:

• Executive summary: топ-три знахідки і рекомендовані дії
• Деталь на категорію вимірювань (Lighthouse, CrUX, waterfall, bundle, сервер, мережа, сприйнята)
• Пріоритизований список фіксів з оцінкою зусиль і очікуваним імпактом
• Рекомендація: редизайн потрібен, не потрібен, або потрібен для частини сторінок

Тижневий проєкт. Реальні цифри. Чесна рекомендація, навіть коли чесна рекомендація — це «вам не треба нас наймати на редизайн».

Якщо дивитесь на сайт, що відчувається повільним, і думаєте, що робити, подивіться, як ми працюємо з редизайном і підтримкою. Іноді відповідь — аудит. Іноді — редизайн. Скажемо вам, яка.