Наш сайт вантажився 9,3 секунди. Ось що ми насправді полагодили

Швидкість сайту — та річ, про яку згадують, коли вже пізно: відвідувач відкрив сторінку, почекав кілька секунд і закрив вкладку. Майже те саме сталося з нашим власним сайтом — і причина виявилась не там, де ми її шукали.

Що показала перша перевірка

Перевірка швидкості завантаження сайту через Google PageSpeed Insights видала мобільний бал 50 зі 100. Найбільша проблема — LCP (Largest Contentful Paint), час, за який людина на екрані бачить найбільший видимий елемент сторінки. Простими словами: Core Web Vitals що це — три метрики, якими Google міряє відчуття швидкості реальними людьми, і LCP одна з них. У нас він становив 9,3 секунди — Google вважає прийнятним показник до 2,5.

Як читати звіт PageSpeed

Звіт PageSpeed Insights має дві частини, і їх легко сплутати. Угорі показано дані реальних відвідувачів за останні 28 днів, якщо сайт має достатньо трафіку. Нижче йде лабораторний тест: Google один раз завантажує сторінку на імітованому повільному телефоні й виставляє оцінку від 0 до 100.

Оцінка зручна, щоб порівняти «до» і «після», але важливіші метрики під нею. Зараз Core Web Vitals складаються з трьох показників:

• LCP. Коли з'являється найбільший елемент першого екрана. Добрий результат — до 2,5 секунди.
• INP. Як швидко сторінка реагує на натискання й дотики. Добрий результат — до 200 мілісекунд. У 2024 році ця метрика замінила стару FID.
• CLS. Наскільки сторінка стрибає, поки завантажується. Добрий результат — до 0,1.

Мобільну й десктопну версії Google перевіряє окремо. Починайте з мобільної: вона майже завжди гірша.

Ми шукали не там

Два дні ми оптимізовували власний код — стискали зображення, чистили CSS, переносили скрипти в кінець сторінки. Локально LCP показував менше секунди. На проді — та сама цифра, 9,3.

Розгадка знайшлась у детальному звіті: 1253 з 2880 кілобайт сторінки і понад 5 секунд процесорного часу забирав скрипт recaptcha__en.js — форму reCAPTCHA без async чи defer вставляла сама Netlify (хостинг, на якому розміщений наш сайт), а не наш код. Цього скрипта не було в жодному файлі нашого репозиторію.

Чому локально все було швидко

Netlify додає цей скрипт сама, коли бачить на формі спеціальний атрибут data-netlify-recaptcha. Тобто скрипт з'являється лише на живому сайті. На комп'ютері розробника сторінка відкривалась без нього, локальні заміри показували менше секунди, і ми щиро думали, що проблему розв'язано.

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

Що ми зробили

Рішення — власний віджет reCAPTCHA з власними ключами замість вбудованого рішення хостингу; серверна перевірка при цьому нікуди не зникає. Паралельно перевели шрифти на self-host — раніше вони тягнулись із Google Fonts, і на холодному кеші це коштувало ще майже 3 секунди — і прибрали з коду шрифт, який був підключений, але жодного разу не використовувався в CSS.

Як капча завантажується тепер

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

Дорогою вилізли дві дрібниці. Зарезервувати під віджет лише висоту виявилось замало: він має фіксовану ширину 304 пікселі, і сторінка смикалась на 25 пікселів, доки ми не зарезервували повний розмір. А поки віджет вантажився лише після дотику, люди бачили порожній прямокутник і вирішували, що капча зламалась. Тепер вона з'являється трохи раніше, ніж відвідувач догортає до форми. Після змін ми перевірили обидві форми на живому сайті: заявки приходять.

Результат

PageSpeed для мобільної версії піднявся з 50 до 74 балів, LCP — з 9,3 до приблизно 1 секунди. Час блокування головного потоку (TBT) впав з 630 до 70 мілісекунд, вага сторінки — з 2880 до 1307 кілобайт. Перевірити швидкість завантаження сайту гугл-інструментом тепер можна за секунду — і ми регулярно так робимо, щоб цифра не поповзла назад непомітно. Це не просто цифра для звіту: швидкість — один з факторів SEO-просування, і повільний сайт Google показує в пошуку гірше.

Чому 74, а не 100

Помітно змінився ще один показник. Speed Index, який показує, як швидко сторінка наповнюється вмістом, зменшився з 9,0 до 3,1 секунди. Проте до зеленої зони оцінка не дійшла, і цього разу причина наша. Найбільше її стримує власна інтро-заставка на головній.

Заставка з'являється один раз за сесію, тож постійний відвідувач бачить швидкий сайт. Тест Google щоразу приходить як новий гість і щоразу її бачить. Поки ми її залишили й повернемось до питання, коли зросте трафік. Пізніше знайшлась ще одна причина: заголовок і картинка першого екрана з'являються з анімацією, і поки вона не закінчиться, Google вважає їх невидимими. Як це виправити, ми знаємо, і запланували на потім. Тож оцінку 74 ми поки приймаємо свідомо.

Як перевірити швидкість сайту самостійно

Базова перевірка займає кілька хвилин, і розробник для неї не потрібен:

• Відкрийте PageSpeed Insights (pagespeed.web.dev), вставте адресу головної сторінки й перейдіть на вкладку «Мобільний».
• Якщо вгорі є дані реальних відвідувачів, почніть з них. Лабораторний тест допомагає знайти причину, а реальні дані показують, що відчувають люди.
• Запустіть тест два-три рази. Перший прогін часто гірший, бо сервер чи мережа ще не «прогрілись». У нас перший замір відповіді сервера показав понад 1,5 секунди, а серія з п'яти дала близько 0,1.
• Перевірте не лише головну. Сторінка послуги чи стаття в блозі можуть мати власні проблеми.
• Міряйте живий сайт, а не копію на комп'ютері розробника. Наш випадок показує, наскільки вони різняться.

Що перевірити в сторонніх скриптах

Сторонній скрипт — це код, який сторінка завантажує з чужого сервера. У ваших файлах його не видно, але відвідувач чекає на нього так само. Поставте кожному такому скрипту кілька запитань:

• Чи потрібен він на кожній сторінці? Капча має сенс лише там, де є форма. Чат — там, де клієнт справді може мати запитання.
• Чи вантажиться він з async або defer? Без них браузер зупиняє обробку сторінки, доки скрипт не завантажиться й не виконається.
• Хто його додав? Хостинг, плагін, менеджер тегів або підрядник, з яким ви давно не працюєте. Від цього залежить, де його вимикати.
• Скільки він коштує сторінці? Діагностика PageSpeed показує вагу кожного скрипта і його процесорний час.

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

Що ми винесли з цього кейсу

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

Найпростіше — написати нам у Telegram або залишити заявку.

← Назад до блогу