Після появи Lighthouse з’явилися нові параметри, пов’язані зі швидкістю сторінки. Одним із найважливіших із цих параметрів є First Contentful Paint (FCP). У версії Lighthouse 10, яка діє з червня 2024 року, вплив FCP на загальну оцінку становить 10%.
Щоб прийняти та зрозуміти FCP як метрику, важливо спочатку вивчити психологію, що стоїть за нею. Концепція подібна до дзеркала, встановлені в ліфтах:
Коротко підсумовуючи: у першій половині 1900-х років використання ліфтів у високих будівлях значно зросло, але ліфтові системи були примітивними порівняно з сучасними. Тому виникла ідея встановити дзеркала в ліфтах, щоб скоротити час перебування в ліфті.
Повертаючись до нашої теми: момент, який перцептивно змушує вас чекати під час завантаження під час спроби отримати доступ до сторінки, це FCP. Визначення First Contentful Paint – це час, потрібний для відображення користувачем першого тексту, зображення, небілого полотна тощо.. Одиницею FCP є секунди.
У Lighthouse колірна шкала FCP визначається наступним чином:
- 0-2 секунд: Зелений => Швидко
- 2-4 секунд: Помаранчевий => Потребує вдосконалення
- 4+ секунди: Червоний => Повільний
Згідно з даними HTTP Archive, кількість сайтів, які можуть бути розглянуті швидко 25%, а 50% існуючих сайтів класифікуються як повільні.
Що можна зробити, щоб покращити FCP?
Зменшити час відповіді сервера
Загалом це можна інтерпретувати як необхідні вдосконалення на сервері та програмному забезпеченні. Щоб перерахувати проблеми, які негативно впливають на час відповіді сервера:
- Проблемою може бути спільне використання, конфігурація (тобто налаштування сервера) і ресурси сервера. Місткість вашого сервера повинна бути збільшена відповідно до вашого трафіку. У деяких випадках погано написані запити до бази даних і дуже складні програмні компоненти можуть серйозно вплинути на час відповіді сервера.
- Невикористання CDN (мережі доставки вмісту) може призвести до затримок у доступі до вмісту, що вплине на FCP. У міру збільшення розміру вмісту, наприклад, якщо великий анімований файл GIF або відео намагаються викликати без CDN, а головний сервер знаходиться на іншому континенті, вам може знадобитися розглянути рішення CDN для вирішення FCP.
- Недотримання статичного вмісту з належною та узгодженою політикою кешу може призвести до перевантаження ваш сервер без потреби, оскільки кількість відвідувачів збільшується. Наприклад, якщо ви не зберігаєте свій логотип у довгостроковому кеш-пам’яті під час завантаження його на кожній сторінці, ви без потреби шкодите часу відповіді вашого сервера.
- Непотрібні перенаправлення сторінок під час доступу до сторінки може непотрібно вплинути на ваш FCP.
Наприклад, раніше існували такі налаштування: коли користувач хотів увійти на сайт, було переспрямування HTTP на HTTPS, а якщо це було мобільне – переспрямування HTTPS на мобільний (наприклад, https:// www на https://m), і якщо сторінку видаляли та перенаправляли в інше місце з 301, виникало відчуття, що користувача перекидають зі столу на стіл у податковій інспекції. Це екстремальний приклад для кращого розуміння, але якщо ви перенаправляєте сторінку на іншу URL-адресу за допомогою переспрямування 301, а потім перенаправляєте цю сторінку на іншу сторінку за допомогою 301, можливо, ви робите ту саму нелогічну настройку.
- Якщо ви не використовуйте попереднє підключення або попередню вибірку DNS префіксів під час підключення до сторонніх служб і багатьох сторонніх служб, ви не робите нічого корисного для FCP.
Зменште ресурси, що блокують рендеринг
Мушу визнати, що для вирішення цього єдиного пункту, написаного як рядок, можуть знадобитися місяці.
Щоб досягти цього, існує метод вирішення, де все JS, CSS та подібні ресурси, які блокують рендеринг сторінки, завантажуються після часу створення сторінки, але спочатку завантажується видима частина сайту під час завантаження сайту. Однак для цього потрібно вивчити всі JS, CSS та подібні ресурси, а найбільш трудомісткі процеси потрібно відокремити. Крім того, використання якомога меншої кількості сторонніх служб допомагає оптимізувати FCP.
