Посібник з підвищення швидкості завантаження сторінок від початку до кінця

Посібник з підвищення швидкості завантаження сторінок від початку до кінця
Вміст Сховати

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

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

Якщо ви розумієтеся на технічних питаннях, то можете встановити плагін/модуль для прискорення роботи, ось деякі з них:

WordPress:

  • WP Rocket (paid) + плагін для оптимізації зображень.
  • Autoptimize + плагін для кешу.
  • Drupal
  • AdvAgg + модуль оптимізації зображень.

Що таке швидкість сторінки

Швидкість сторінки – це час, необхідний для її завантаження. Для цього поняття важко надати одне значення, оскільки різні метрики фіксують елементи по-різному, для різних цілей і з різними умовами тестування.

Чому слід піклуватися про швидкість сторінки

Останнім часом швидкість завантаження з мобільних пристроїв стала фактором ранжування: з’явився звіт Google Search Console; співробітники Chrome пояснили, що роботи можуть помічати повільні сайти та занижувати їх у SERP.

Швидкість завантаження сторінок – фактор ранжирування з 2010 року.

Ось причини, через які ви повинні оптимізувати сайт:

  • Вплив на лояльність користувачів та їх досвід із взаємодією з сайтом. Люди нетерплячі, якщо сайт буде довго завантажуватися, вони швидко закриють його. Будь-яка затримка чи гальмування сприяє відмові, тобто. виходу людини з веб-ресурсу.
  • Вплив на аналітику. Швидкий сайт реєструватиме більше відвідувачів, тому що тег аналітики завантажиться швидше. Якщо людина йде до того, як завантажиться тег, реєстрація в системі аналітики не відбудеться.
  • Згідно з офіційною заявою, оновлення Speed ​​Update торкнеться лише найповільніших сайтів. Нововведення торкнеться невеликого відсотка ресурсів. Але хочемо відзначити, що Google обробляє до 4 млрд пошукових запитів на день, а отже, «невеликий відсоток» – поняття далеко відносне.

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

За словами Google, новий алгоритм торкнеться невеликого відсотка ресурсів. Хочемо відзначити, що Google обробляє до 4 млрд пошукових запитів на день, а отже, «невеликий відсоток» – поняття далеко відносне.

Існує безліч досліджень, що показують, що якщо збільшити швидкість завантаження сторінки такі показники, як органічний трафік, співвідношення кліків та відвідувань, збільшення кількості відвідувачів загалом і багато інших почнуть зростати. У WPO Stats є багато прикладів досліджень щодо покращення швидкості.

Однак попереджаємо – деякі з цих досліджень можуть вводити в оману. Google повідомляє, що підвищення продуктивності не впливає на рейтинг, тільки якщо раніше не ресурс не був дуже повільним.

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

Як швидко має завантажуватися сторінка

Офіційної інформації щодо порога не існує. Одна з найпоширеніших рекомендацій – ваш сайт повинен завантажуватись менше ніж за три секунди. Ймовірно, це випливає з дослідження Google, згідно з яким 53% мобільних відвідувачів йде, якщо сайт завантажується більше трьох секунд.

Ця рекомендація також заснована на показнику Speed ​​Index, про який ми поговоримо пізніше, але це лише припущення, що ґрунтуються на тому, що було головним показником на момент проведення дослідження. Навряд чи Google колись позначав конкретний показник швидкості завантаження сторінок. Зазвичай Google дає загальні та поверхові рекомендації, наприклад, «зробіть сайт швидше для користувачів» або «зробіть сайт швидше настільки, наскільки це можливо».

Як влаштована сторінка

Щоб зрозуміти, як збільшити швидкість завантаження ресурсу, необхідно знати, як браузер створює веб-сторінку. Для цього ми в основному розглядатимемо діаграми Waterfall, щоб побачити, які ресурси завантажуються. Ви також можете побачити це в браузері, клацнувши правою кнопкою миші – і відкривши вкладку “мережа” під час завантаження.

Встановлення взаємозв’язків

Зелений, помаранчевий та фіолетовий кольори позначають час, необхідний для встановлення з’єднання з веб-сайтом. Нижче розповімо про кожен колір та про те, що він позначає.

DNS (Зелений)

Система доменних імен (DNS) вважається телефонною книгою інтернету. Ви вводите у свій браузер веб-сайт, і він перевіряє DNS-сервер, щоб отримати IP-адресу (позначку розташування), яка вказує, де розміщено веб-сайт. Це схоже на збереження контактів у телефоні, де вам достатньо знати ім’я, а не номер телефону.

У більшості випадків DNS належатиме реєстратору домену (де ви купили домен) або Content Delivery Network (мережі доставки контенту – CDN).

Не всі DNS-провайдери однакові. Якщо вам важлива кожна мілісекунда, можливо, вам варто подумати про використання іншого DNS-провайдера. За даними DNSPerf, середня швидкість запиту у Cloudflare становить 12,6 мс, тоді як у інших провайдерів, таких як GoDaddy (46,04 мс) та Rackspace (90,38 мс), вона в середньому нижча. Однак, ці цифри не є абсолютними, оскільки DNS може кешуватися (тимчасово зберігатися) у браузері після відвідування веб-сайту. Час кешування називається TTL (Time to Live). Поки кеш зберігається, браузеру не потрібно підключатися до сервера DNS, щоб перейти на сайт.

Connect (Помаранчевий)

Тут браузер встановлює з’єднання з сервером. Протокол керування передачею/інтернет-протокол (TCP/IP) складний, але просто подумайте про те, як ви дістаєтеся на роботу. Швидше за все це непряма лінія, вам доведеться повертати і будуть райони з вищою прохідністю. Ви змінюєте маршрут і навіть повертаєтеся неправильно. Так працює ця система – вона прокладає маршрут від вашого браузера до сервера та назад.

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

Проблема може бути пов’язана з маршрутизацією запиту по мережі. Скільки кроків вам потрібно пройти, як далеко, як багато іншого трафіку в мережі – це все схоже на те, скільки поворотів потрібно зробити, як далеко ви знаходитесь від роботи і як багато інших машин на дорозі, які можуть сповільнити вас.

Також існує обмеження швидкості та пропускної здатності з’єднання на сервері, що схоже на тунель, який пропускає лише певну кількість машин за один раз.

Багато з цих проблем вирішуються шляхом скорочення відстані до сервера та використання більш інтелектуальної маршрутизації, що можуть робити багато CDN. Маючи мережу серверів по всьому світу, відвідувачі зазвичай можуть підключитись до найближчого з них.

Деякі провайдери CDN також керують великою кількістю інтернет-запитів і можуть у режимі реального часу бачити, де можуть бути пробки. Якщо вони виявляють швидший варіант, то перенаправляють трафік – подібно до того, як GPS спрямовує вас в об’їзд пробки.

Secure Sockets Layer (SSL) (фіолетовий)

На сайтах, що встановлюють захищене з’єднання (HTTPS), браузер і сервер узгоджують версію протоколу TLS (Transport Layer Security), шифр (рівень безпеки) і перевіряють сертифікат (щоб переконатися, що сайт є тим, кого себе видає).

Можливо, ви думаєте, що можете зробити свій сайт швидше, просто не використовуючи HTTPS. Частково це правда. Але є й інші переваги використання HTTPS. Наприклад, те, що браузери не дозволяють використовувати HTTP/2 (H2) без HTTPS.

H2 має деякі переваги, такі як постійні з’єднання, тому йому не потрібно постійно відкривати нове з’єднання для файлів на тому ж сервері.

Заголовки у цих запитах також менші, ніж у HTTP/1.1 і кілька файлів можна передавати одночасно. У більшості випадків сайти, що використовують HTTPS та H2, працюють швидше, ніж сайти на HTTP.

Найбільший виграш тут дає оновлення протоколу (наприклад, TLS 1.3 швидше, ніж TLS 1.2) та впровадження HTTP Strict Transport Security (HSTS), який вказує браузеру завжди використовувати захищене з’єднання.

Браузер змінює запити з HTTP на HTTPS без необхідності зв’язуватися з сервером та виконувати перенаправлення. На зображенні нижче показано перенаправлення з HTTP на HTTPS та час, витрачений на нього. Це можна було б усунути завдяки використанню HSTS.

Також можна розглянути використання HTTP/3 для більш швидкого з’єднання.

Важливо: пристрій, місцеперебування та мережа мають значення.

Наприклад, підключення до веб-сайту на смартфоні середнього класу з повільним з’єднанням 3G займає ~2 секунди. На тому ж телефоні з LTE-з’єднанням цей час скорочується до ~0,41 секунди. На робочому столі з нормальною швидкістю – менше 0,1 секунди.

Майте це на увазі: якщо ви бачите триваліший час з’єднання, це може бути пов’язане з обмеженою пропускною здатністю або обчислювальною потужністю тестового пристрою. Ці чинники – поряд із кешуванням – дуже важливі. Наприклад, вони можуть допомогти вам, пояснити людині з просунутим смартфоном, на якому дані закешовані, що сприйняття його телефоном сайту відбувається в ідеальних умовах.

Завантаження та обробка HTML

HTML-код сторінки – це те, що спочатку завантажується браузером. Саме цю інформацію ви бачите, коли клацаєте правою кнопкою миші на сайті та вибираєте “Перегляд коду сторінки”. Після встановлення з’єднання і браузер отримує перший біт інформації від сервера, ми отримуємо час до першого байта (TTFB), який є типовим показником початкового часу відгуку.

Як показано помаранчевими лініями нижче, цей час від початку запиту HTML (світло-блакитний колір) до моменту, коли HTML починає завантажуватись (темно-синій колір).

Якщо для TTFB відбувається затримка, це може бути пов’язано із запитами до бази даних, ресурсами сервера, очікуванням завершення Server Side Render (SSR) або іншими речами, які зазвичай пов’язані зі створенням динамічного контенту. Час завантаження буде залежати від таких факторів, як з’єднання та розмір файлу.

Тут браузер починає конструювати сторінку. Коли HTML завантажений, браузер розбирає їх у об’єктну модель документа (DOM), з допомогою якої комп’ютер розуміє структуру вмісту. Цей процес аналізу використовує головний потік браузера для обробки дій користувача та відтворення ресурсу, виконання JavaScript, а також компонування, повернення та збору сміття. Поки що просто знайте, що цей основний потік існує і виконує безліч різних завдань. Ми розповімо про це трохи згодом.

Якщо ви бачите розрив між HTML і наступним запитом, найбільш імовірною причиною є те, що процесор зайнятий обробкою HTML для створення DOM. Оскільки йдеться про процесор (все залежить від пристрою), ви здатні провести тестування розриву на більш потужному пристрої, щоб перевірити, чи зберігається він.

Для HTML та інших типів файлів, таких як CSS та JavaScript, можна скоротити час за рахунок використання меншої кількості коду, мініфікації для видалення з нього непотрібних символів, таких як коментарі та пробіли, а також стиснення для зменшення розміру файлів.

Сенс у тому, щоб зробити завантаження файлу менше, щоб ця частина завантаження проходила швидше. Однак існує не один спосіб мініфікації та стиснення. У багатьох випадках цим займається CDN або сервер (Apache або Nginx – звичайні сервери), або плагін/модуль/пакет.

Обробка додаткових підключень

Після завантаження HTML будуть оброблені посилання на інші файли та інші сервери, розпочнуться нові з’єднання. Зазвичай сюди додаються інші файли, такі як JavaScript, CSS, зображення та шрифти. На цьому етапі все може ускладнитись – одні файли посилаються на інші, і починається ланцюжок з’єднань для завантаження. Кожна точка – це індивідуальний запит, а кожна лінія – це місце, де один файл посилається на інший, який потрібно завантажити. Загалом це 363 запити через 128 з’єднань.

По можливості використовуйте той самий сервер для запитів

Найкращим рішенням раніше вважалося розміщення ресурсів на домені без cookie, які не збігалися з основним доменом. А іноді було вигідно використовувати кілька доменів (процес називається «шардинг доменів») через обмеження кількості запитів на з’єднання, встановлених браузером. Починаючи з HTTP/2, цей спосіб вважається не найкращим.

Наприклад, візьмемо сайт cdn.ahrefs.com на наведеному нижче графіку.

Якщо цей файл розмістити на ahrefs.com, йому навіть не довелося б встановлювати з’єднання. Затримка відбувається через час на встановлення з’єднання з DNS, підключення та підтвердження безпеки. Якщо не робити зайві кроки, то файл отримаємо раніше, а значить, сторінка завантажиться ще швидше.

Самостійне розміщення деяких файлів, таких як шрифти може покращити ситуацію, але є й інші рішення. Наприклад, кешування (зберігання копії файлу), коли браузери можуть іноді кешувати спільні ресурси. Якщо ви відвідали сайт, на якому використовувався шрифт з Google Fonts, а потім перейшли на інший сайт, який використовує той самий шрифт, цей файл зберігається в локальному кеші і не завантажується заново.

Використовуйте Preconnect або DNS-Prefetch (при іншому сервері)

Якщо ви збираєтеся використовувати інший сервер, попередньо підключіться до серверів, які містять файли, необхідні на ранніх етапах завантаження. Це дозволить встановити з’єднання з іншим сервером раніше, ніж це зазвичай відбувається. Нижче показано, як одне із з’єднань для Amazon починається ще до того, як HTML закінчить обробку.

Приклад коду: <link rel = «preconnect» href =”https://site.com»>

Існує також DNS-prefetch, якщо ви хочете обробити тільки цю частину з’єднання на ранній стадії. Зелена (DNS) частина буде підключена раніше, але решта з’єднання відбудеться пізніше.

DNS-prefetch має кращу підтримку, ніж preconnect, але якщо ви подивитеся на поточну статистику використання, різниця буде незначною. Preconnect буде ефективнішим, якщо ви знаєте, що для функціонування сторінки щось із сервера має бути завантажено раніше. Проте preconnect вимагає більше роботи для маршрутизації та безпеки (помаранчевий та фіолетовий кольори), тому він також буде більш ресурсомістким на ранніх етапах.

Приклад коду: <link rel=«dns—prefetch» ​​href=«//asset1.com»>

Як браузери відображають сторінку

Спочатку у нас є різні типи файлів, такі як CSS, JavaScript, зображення та шрифти, і браузер повинен перетворити їх разом з HTML у щось корисне.

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

Шлях рендерингу

HTML перетворюється на DOM-дерево (кожен HTML-тег є об’єктом; вкладені теги є «дітьми» батьківського елемента; текст, що знаходиться всередині тега, також є об’єктом).

CSS аналізується в об’єктній моделі CSS (CSSOM), яка повідомляє браузеру, як все оформлено, доповнено, розфарбовано, який має розмір і т. д.

CSSOM + DOM разом становлять так зване дерево рендерингу.

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

На екрані з’являються пікселі, тому замість білого екрана ви починаєте бачити кольори, форми, текст та зображення.

Мета – отримати необхідні елементи якомога раніше, щоб первинне уявлення сформувалося якнайшвидше. Видимий час завантаження – це уявлення людей про швидкість роботи сторінки, тобто про те, як швидко вміст з’являється на екрані. Найбільше цього впливає те, як завантажуються ресурси. Зазвичай до обов’язків CMS або JavaScript Framework входить допомога браузеру у визначенні пріоритетів, коли/які/як/у якому порядку завантажувати ресурси, щоб сайт відображався швидше. Докладніше про це трохи пізніше.

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

Показники візуального навантаження

  1. First Paint (FP) – браузер відображає щось уперше.
  2. First Contentful Paint (FCP) – браузер відображає щось із DOM (Document Object Model), це може бути текст або зображення.
  3. First Meaningful Paint (FMP) – найважливіші елементи візуально завантажені.
  4. Largest Contentful Paint (LCP) – завантаження найбільшого контенту.
  5. Visually Complete – візуальне навантаження.
  6. Speed ​​Index – розрахований бал для візуального навантаження у момент часу.
  7. Cumulative Layout Shift (CLS) – зсув макету.

Перегляд візуального навантаження разом із графіком каскадної моделі

У розділі Summary у WebPageTest, якщо ви увімкнете запис, у вас має з’явитися стовпець Video в основній таблиці з Filmstrip View. Червона лінія зверху з візуальними кадрами знаходиться в тій же точці, що й червона лінія внизу каскадної моделі.

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

Наприклад, якщо ви бачите, що більша частина вашої сторінки завантажена, за винятком тексту, але відразу після цього завантажується шрифт і з’являється текст, це ознака того, що для відображення тексту був потрібен шрифт. Також можна визначити заздалегідь, які зображення знадобляться в різних областях перегляду, просто подивившись на згенеровані скріншоти.

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

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

Тип файлу CSS

Складність зі швидкістю ресурсу в тому, що в багатьох випадках немає єдиного правильного способу зробити щось. У більшості методів є компроміси, а деякі з них складні в реалізації та підтримці. Ви повинні вирішити, що буде простіше, швидше і краще за ваших обставин.

Якщо подивитися на файли CSS, за замовчуванням вони блокують рендеринг, тобто їх необхідно завантажити і обробити, перш ніж браузер відобразить вміст користувачеві. Якщо ви кешуєте (зберігайте копію файлу, про що йдеться далі в статті), цей файл може бути повторно використаний при наступних завантаженнях. Це означає, що його не потрібно завантажувати знову, і наступні перегляди відбуватимуться швидше.

Більшість інструментів перевірки швидкості тестують перший перегляд, тому багато з того, що ви бачите в інструменті PageSpeed ​​Insights, відноситься до користувача, який вперше переглядає сторінку, а не до того, хто часто повертається на сайт. Вашою метою має бути оптимізація як першого, так і подальших переглядів для користувачів.

Асинхронне завантаження CSS

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

Він завантажує CSS без блокування рендерингу (тому що в цьому випадку ми повідомляємо браузеру, що таблиця стилів призначена для друку, а не для цієї версії сторінки), а потім застосовується до всіх типів медіа (тим, які не призначені для друку) після завантаження.

Наприклад, це: <link rel=«stylesheet» href=«/my.css»>

Стає цим: <link”stylesheet” href=”/my.css” media=”print” onload=”this.media= ‘all’»>

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

Inline

Код Inline, необхідний для відображення вмісту у верхній частині вкладки, передається разом з HTML-відповіддю, а не в окремому файлі. Як правило, це найшвидший спосіб скоротити час, необхідний для відображення початкового вигляду.

Найпростіше уявити, що ви берете критичні частини файлів CSS і JS і розміщуєте їх безпосередньо в HTML. Початковому HTML потрібно трохи більше часу на завантаження та розбір, але рендеринг сторінки тепер може відбуватися ще до завантаження всіх інших файлів.

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

Але якщо ви вбудували код для кожної сторінки, це означає, що наступні також містять додатковий код. Це просунутий варіант, який передбачає використання робочих служб, але ви маєте право використовувати як вбудовування, так і кешування. У поєднанні з асинхронністю CSS, яку ми говорили вище, це практично ідеальний варіант.

Пам’ятайте, що мініфікувати вбудований код CSS ніхто не забороняє. Як згадувалося вище в розділі HTML, при цьому видаляються непотрібні інтервали та зайві символи, що робить код меншим і швидшим для завантаження.

Можливо, ви не бажаєте вбудовувати весь вміст кожного файлу. Будьте уважні та вставляйте лише найважливіший вміст. Технічно ви здатні вбудовувати всі CSS і JS, а також шрифти та зображення, але в результаті у вас вийде гігантське завантаження HTML, де більшість коду не використовується. Це фактично робить ваш сайт повільнішим. Але якщо у вас є кілька файлів розміром всього в пару КБ, і ви хочете вбудувати їх повністю, то вперед.

Вбудовування критичного CSS у масштабі

Швидше за все, ви захочете використовувати автоматизовану систему, а не працювати з кожною сторінкою окремо. Тоді має сенс вбудовувати лише CSS у головну теми WordPress, оскільки там зазвичай використовується інша таблиця стилів, на відміну інших сторінок.

Зазвичай для цього існує якийсь плагін/модуль/пакет чи версія Critical або Critical CSS. Вони існують для будь-якого диспетчера завдань або пакета, який ви використовуєте, наприклад, Grunt, Gulp, Webpack, або Framework, React, Angular, Vue.

Можна знайти навчальні посібники, специфічні для WordPress або Drupal, або навіть сторінок, створених вручну. Вони визначать, який CSS є критично важливим для відкриття вікна браузера при різних розмірах, або нададуть вам код, або розділять код на критичні та некритичні елементи, щоб ви могли завантажити їх відповідним чином.

Кілька прикладів навчальних посібників

Grunt

https://github.com/filamentgroup/grunt-criticalcss

https://www.npmjs.com/package/grunt-critical-css

https://github.com/bezoerb/grunt-critical

Gulp

https ://github.com/addyosmani/critical

https://www.npmjs.com/package/gulp-critical-css

Webpack

https://github.com/anthonygore/html-critical-webpack-plugin

https://github .com/GoogleChromeLabs/critters

https://github.com/anthonygore/html-critical-webpack-plugin

https://www.npmjs.com/package/critical-css-webpack-plugin

React

https://www.npmjs .com/package/react-critical-css

https://github.com/addyosmani/critical-path-css-tools

https://github.com/sergei-zelinsky/react-critical-css

Angular

https://github .com/addyosmani/critical-path-angular-demo

Vue

https://github.com/anthonygore/vue-cli-plugin-critical

https://vuejsdevelopers.com/2017/07/24/critical-css-webpack/

Drupal

https://www.fourkitchens.com/blog/article/use-gulp-automate-your-critical-path-css/

WordPress

https://wordpress.org/plugins/wp-criticalcss/

Hand-coded

https://www.sitelocity.com/critical-path-css-generator

https://jonassebastianohlsson.com/criticalpathcssgenerator/

Попереднє завантаження

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

Браузер надає кожному запиту на файл пріоритет. Щоб отримати файли, необхідні для відображення вмісту у верхній частині вкладки раніше (з більш високим пріоритетом) і відкласти ті, що не потрібні, на більш пізні етапи процесу. Пріоритет файлів можна переглянути на вкладці Network у Chrome Dev Tools. Просто клацніть правою кнопкою миші на панелі, виберіть Priority і додайте його як стовпчик.

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

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

Приклади коду:

<link”preload” href=”/my.css” as=”style”>

<link”stylesheet” href=”/my.css” media=”print” onload=”this.media =’all’»>

Вибір файлів для попереднього завантаження

Зазвичай у вас є основний файл теми, який містить більшу частину CSS для сайту. Розробники часто називають його «стиль», ім’ям теми чи самого сайту. Якщо вам важко визначити цей файл або ви вважаєте, що інші файли, можливо, також необхідно завантажити, то найпростіший спосіб перевірити – використовувати функцію блокування запитів в Chrome Dev Tools.

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

Що потрібно знати про попереднє завантаження

  1. Вам потрібен Cross-origin для шрифтів, інакше ви отримаєте подвійне завантаження файлу.
  2. Вам, як і раніше, потрібні звичайні звернення до файлів JS + CSS, тому не видаляйте їх.
  3. Є можливість завантажити шрифт, навіть якщо він викликається з іншого файлу, наприклад, у файлі CSS.
  4. Будьте обережні під час попереднього завантаження. Можна зіткнутися з проблемами, намагаючись завантажити занадто багато файлів.

Server Push

HTTP/2 Server Push дозволяє серверу, сумісному з HTTP/2, надсилати ресурси клієнту, сумісному з HTTP/2, перш ніж він запросить їх. Таким чином, минаючи ланцюжок HTML > CSS > Font, це дозволяє сайту сказати: «Мені потрібний цей шрифт, просто надішліть його».

Server Push досить проблематичний і краще його не використовувати, але якщо ви добрий розробник або вже працювали з ним, варто спробувати. Він запитує файли з сервера по тому з’єднанню, як і запит сторінки. Server Push може завантажувати ресурси двічі. Є обхідний шлях, який використовує файли cookie та перевіряє, чи ви відправили ресурси користувачам, але це складна реалізація.

Ще одна проблема, пов’язана з підключенням, може призвести до того, що файли взагалі не завантажаться. Незважаючи на всю додаткову роботу, ви все одно не побачите значних змін у порівнянні з попереднім завантаженням, оскільки браузери перевіряють кеш ресурсу перед кешуванням push.

Тип файлів JavaScript

JavaScript також може бути складним через велику кількість опцій. Іноді він використовується для забезпечення функціональності, іноді для отримання основного контенту або навіть для внесення змін до CSS. Крім того, для правильної роботи певного коду може знадобитися інший код. Це називається залежностями, і зміна способу завантаження JavaScript може призвести до порушення функціональності.

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

Найпростіший спосіб дізнатися, чи потрібний JavaScript – це натиснути на замок у Chrome та відкрити налаштування сайту. Ви побачите список дозволів, одним з яких є JavaScript, де ви дозволите або заблокуєте його.

Блокування JavaScript, перезавантаження сторінки та порівняння сайту з JavaScript і без нього повинні показати, чи на вкладці відсутні елементи. Якщо чогось не вистачає, знову дозвольте JavaScript і зробіть той же процес блокування, що й у випадку з CSS, щоб з’ясувати, які файли є критичними для відображення вмісту.

Перенесення у Footer (підвал)

Для вбудованих сценаріїв можна розглянути можливість їх переміщення до підвалу. Пам’ятайте, що JavaScript блокує парсер, тобто блокує HTML читання.

Переміщення цих сценаріїв у підвал гарантує, що більшість даних буде оброблена до того, як відбудеться блокування. У вас є інші варіанти посилань на сценарії, які, ймовірно, краще – відстрочка та асинхронність.

Defer/Async (відстрочка/асинхронність)

Defer та Async – це атрибути, які можна додати до тега скрипту. Зазвичай завантажуваний скрипт блокує парсер під час завантаження та виконання. Async дозволяє парсингу та завантаженню відбуватися одночасно, але при цьому блокує виконання скрипту. Defer не блокує парсинг під час завантаження та виконується лише після завершення парсингу HTML.

Приклади коду Defer/Async

Normal:

<script src=”https://www.domain.com/file.js”></script>

Async:

<script src=”https://www.domain.com/file”. js» async></script>

Defer:

<script src=«https://www.domain.com/file.js» defer></script>

Адді Османі доступно описав блокування, асинхронність, відстрочку та передзавантаження, а також те Як вони впливають на пріоритети браузера.

Відгук

Відгук зазвичай вимірюється затримкою першого введення (FID), тобто часом, що проходить з взаємодії користувача з вашим ресурсом до моменту, коли вона завантажиться. Максимальний потенційний FID – це найгірший випадок FID, з яким можуть зіткнутися ваші користувачі. Багато хто зазвичай вимірює час інтерактивності (Time To Interactive, TTI) – час, необхідний для того, щоб вкладка браузера стала повністю інтерактивною.

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

На відгук впливає JavaScript. Весь JavaScript, завантажений для виконання різних завдань, має виконуватись в одному місці.

На зображенні вище показано, як виглядає основний потік. Ці червоні галочки на вкладці Performance у Chrome Dev Tools вказують на можливі проблеми. Зазвичай відзначаються завдання, що вимагають надто багато часу для виконання в основному потоці. Кожна з них означає, що йде перевантаження роботою та здатності оперативно реагувати на запит користувачів немає.

Поки завдання виконується, сторінка не може реагувати на запит користувача. Це є затримка, яку відчуває користувач. Чим довше завдання, тим довша затримка, що відчувається користувачем. Перерви між завданнями – це можливість перейти на запит користувача та відповісти на нього.

Сторонні теги

Це ще один звіт, який можна знайти у PageSpeed ​​Insights. Він показує розмір та час, протягом якого сторонні скрипти блокували основний потік та впливали на інтерактивність.

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

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

Common Sources of JavaScript Bloat

  • Системи A/B тестування.
  • Системи теплових карток.
  • Системи моніторингу реальних користувачів (RUM)
  • Системи живого чату.

Варіанти очищення

  1. Використовуйте менше відстеження/скриптів. Це може бути непростим рішенням, тому що маркетологи люблять статистичні дані, але іноді обсяг даних, що збираються, просто абсурдний.
  2. Консолідуйте системи з аналогічною функціональністю, наприклад, якщо ви використовуєте кілька систем аналітики або інші системи, які мають інформацію про користувачів. Багато програм мають кілька функцій, і іноді ви отримуєте сценарії, які мають такі ж чи схожі функції, тому теорія має спосіб обійтися без однієї з них.
  3. Сегментація. Наприклад, деякі системи A/B-тестування збережуть і змусять вас завантажити список всіх тестів, що знаходяться в системі, збільшуючи розмір завантаження. Ви можете сегментувати сайт за розділами та створювати зменшені версії файлу.
  4. Відстеження за сервера замість спостережень за клієнта. Такий спосіб має свої недоліки, про які не буде розказано тут, але можна знайти багато інформації про те, чому можливо використовувати один спосіб замість іншого.
  5. Використовуйте веб-воркери, щоб перемістити обробку з основного потоку. Зворотною стороною цього є те, що веб-воркер не матиме доступу до DOM. Це також досить складне завдання, яке потребує досвідчених розробників.
  6. Service Workers/Edge Workers. Вважається, що на цю технологію чекає велике майбутнє. По суті вона дозволяє виконувати JS на рівні Edge (або CDN), а не в браузері клієнта. Так, для системи A/B-тестування може виявитися, що файл завантажується, а потім обробляється та виконується у браузері користувача. Оскільки тест може перезаписувати частини DOM і відбуватися пізніше під час завантаження, вам вдасться побачити візуальні ефекти при зміні ситуації. Тепер потрібно попередньо обробити зміни, які будуть внесені, та передати їх у HTML, який буде доставлений ботам та користувачам. Деякі платформи вже використовують цю перевагу.
  1. Просто відкладіть виконання завантаження файлу, якщо він не потрібний прямо зараз, або ініціюйте запит файлу тільки на підставі дії, наприклад, клацання миші. Онлайн-консультант, ймовірно, не потрібен протягом перших п’яти секунд завантаження сторінки, тому відкладіть його завантаження. Також є варіант запросити файл після того, як хтось наведе курсор або натисне кнопку, щоб він взагалі не завантажувався разом з початковою сторінкою. Або використовувати зображення з кнопкою відтворення замість вбудовування відео YouTube і завантажувати лише його елементи, а відтворювати вміст, коли користувач натискає кнопку.

Переваги JS фреймворків

JavaScript фреймворки, такі як React, Angular та Vue, мають деякі переваги перед традиційними системами.

  • Tree shaking. Доставка тільки коду, який використовується на вкладці браузера. Будь-які додаткові файли або код, які не потрібні, не завантажуються, що призводить до зменшення розміру файлів та сторінок. Це усуває код, традиційно необхідний інших сторінок і дій.
  • Поділ коду. Розділяйте файли на дрібніші фрагменти, це дасть більше можливостей для інтерактивності. Допустимо, у вас є JS-файл розміром 1 МБ, який запускається як довге завдання в основному потоці та блокує інтерактивність на час виконання. Ви можете розділити його на фрагменти по 50 КБ, щоб завдання виконувались не так довго, а між ними залишалося більше проміжків у короткі періоди, коли сторінка реагує на запит користувача.

Шрифти

У випадку зі шрифтами у вас є багато можливостей, про які ми говорили раніше (наприклад, вбудовування або попереднє завантаження потрібного шрифту). Тут ви знайдете приклади коду для завантаження шрифтів, якщо захочете піти цим шляхом.

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

Якщо ви використовуєте шрифти Google, це ще простіше. Все, що вам потрібно зробити, це додати &display=swap як параметр URL-адреси.

<link href=«https://fonts.googleapis.com/css?family=Whatever&display=swap» rel=«stylesheet»>

Зображення

Основна проблема із зображеннями – це їх розмір та вага. Вам потрібні оптимізовані зображення, що завантажуються в потрібному розмірі та якості для певного пристрою.

Зображення завантажуються асинхронно, тому вони не блокують завантаження, але можуть збільшувати вагу та загальний час взаємодії.

Ще одна потенційна проблема пов’язана з розстановкою пріоритетів, коли деякі зображення можуть бути розставлені неправильно або пріоритетніше критично важливих файлів, таких як CSS та JS. Також можуть виникнути умови, коли завантажується багато зображень, що призводить до максимального використання ресурсів та низької пропускної здатності, а отже, уповільнює загальне завантаження сторінки.

Багато з того, про що ми говорили, наприклад inline і preload, можна використовувати для зображень, але з тими ж умовами, такими як кешування. Правило номер один – не використовувати багато зображень або великих зображень у верхній частині вікна браузера. Немає потреби у гігантських фонових зображеннях на мобільних пристроях. Але якщо без цього не обійтися, краще використовувати попереднє завантаження.

Завжди виконуйте масштабування зображення. Існує безліч варіантів зробити це, наприклад, за допомогою CDN, сервера, CMS та API. Ось кілька варіантів:

Оптимізація зображень CDNs:

Оптимізація зображень APIs:

GUI:

Command Line:

  • Imagemin,також є npm модуль, якщо ви використовуєте webpack, gulp або grunt.

JPEG:

PNG:

GIF:

WordPress/Drupal:

Лініве завантаження зображень

Якщо хтось каже, що вам потрібно “розмістити зображення за межами екрана”, це вам підходить. По суті, це відстрочка завантаження зображень, розташованих не над згином, тому що вони поки що не потрібні. Як тільки користувач почне прокручування, зображення завантажаться.

Спеціаліст Ahrefs радить вам бібліотеку, яка використовує Intersection Observer, але, ймовірно, має поліфіл через підтримку браузера. Найпопулярніша бібліотека для цього – lazysizes, але можна знайти багато варіантів для вашої системи.

Починаючи з Chrome 76, ліниве завантаження було впроваджено у браузер. Очікується, що незабаром це зроблять і інші браузери, але ми можемо використовувати цей метод для Chrome з поліфілом для інших браузерів.

Адаптивні зображення / зображення зі зміненим розміром

Мова йде про передачу правильного зображення на потрібний екран. Завантаження великого зображення та подальше його зменшення лише забирає час та ресурси. І тому існує безліч автоматизованих рішень. Наприклад, багато мереж CDN впораються з цим завданням, а також sharp npm, ImageMagick CLI або різні плагіни/модулі для різних систем.

Зміна формату зображення

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

Розмір/вага сторінки

Це розмір всіх ресурсів, разом узятих. Сторінки із меншою вагою працюють швидше. Ми вже говорили про багато покращень, таких як мініфікація, стиснення і просто порятунок від усього, що не використовується. Чим менше доводиться завантажувати спочатку, тим швидше буде відображатися ресурс.

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

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

Інші можливості веб-продуктивності

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

Кешування

Кеш – це просто збережена копія файлу. Кешовані файли можна повторно використовувати на наступній сторінці без необхідності повторного завантаження.

Кеш сервера

Саме звідси браузер бере файли, що запитуються. В ідеалі ви хочете використати найближчий до користувача кеш. Мається на увазі, що кеш може зберігатися на різних рівнях з різними значеннями TTL, встановленими для кожного з них, що призводить до закінчення терміну дії кешу.

Існує баланс між кешуванням на більш тривалі періоди та швидким оновленням вмісту при змінах. Все не так просто, оскільки є можливість при оновленні очистити кеш на різних рівнях, що є ідеальним способом разом із системою «теплого» кешу. Вона відправляє робота для відновлення кешу, а не чекає, поки користувач запитає файли. Це означає, що користувачеві не потрібно чекати, доки буде створено початковий кеш.

Перевірка зазвичай виглядає так: Кеш CDN > Кеш сервера (наприклад, Varnish) > Origin (має створювати сторінку моментально). Як правило, кеш вищого рівня, наприклад CDN, буде швидше, тому необхідно, щоб більшість ваших запитів були на цьому рівні.

Наприклад, на одному з сайтів на Cloudflare, показаному нижче, спостерігається трохи більше 50% потрапляння до кешу на рівні CDN. На жаль, це означає, що багато запитів не обслуговуються CDN і змушені повертатися до кешу на рівні сервера. Або якщо там немає поточної кешованої версії, доведеться створювати сторінку на ходу, що використовує багато ресурсів бази даних і буде повільніше для користувача.

Кеш браузера

Навіть якщо у вас великий сайт з поганими показниками швидкості, між першим і другим завантаженням сторінки або навігацією між декількома, може бути значна різниця. Багато чого з того, про що було сказано раніше, спрямоване на прискорення початкового завантаження. Це те, що бачить більшість інструментів тестування і це перше враження користувача про ваш сайт. Коли відвідувач заходить на ресурс, браузер може кешувати багато файлів локально на комп’ютері користувача, і вони можуть бути використані повторно при наступних переглядах.

Наприклад, подивіться на різницю між першим і другим завантаженням для Ahrefs. Більшість файлів, які потрібно було завантажити при першому завантаженні, кешуються на стороні клієнта (браузера), а це означає, що при другому завантаженні можна використовувати вже завантажені файли для створення сторінки. Скорочення часу з’єднання та завантаження означає, що сторінка завантажується значно швидше. У цьому випадку First Paint завантажується приблизно вдвічі швидше при другому завантаженні.

1 завантаження:

2 завантаження:

У таких інструментах, як Lighthouse, проблеми з кешуванням будуть відзначені як «обслуговування статичних ресурсів за допомогою ефективної політики кешування». Встановлення тривалості часу для кешу залежить від системи, але, як правило, все, що вам потрібно зробити, це використовувати HTTP-заголовок Cache-Control. Max-age – це час, який ви хочете зберегти в секундах, і його можна задати таким чином: Cache-Control: max-age=31536000

Встановіть бюджет продуктивності

Бюджет продуктивності – це набір самостійно встановлених обмежень на показники, що впливають на продуктивність. Це може бути розмір, кількість файлів певного типу або деякі показники швидкості, про які ми вже говорили.

Адаптивне завантаження

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

Однією із складових цього процесу є Network Information API, який надає вам інформацію про підключення користувача. Ви можете змінити свої зображення/контент або зробити щось на зразок відключення відео, ґрунтуючись на інформації про мережу вхідного запиту. Багато CDN для зображень роблять це за допомогою Network Information API.

Використовуйте інші підказки ресурсу

Prefetch

Prefetch – це підказка ресурсу, яка отримує файл, перш ніж він знадобиться. Це можуть бути цілі сторінки, скрипти або файли CSS. Один із найкращих способів використання цієї функції – Guess.js, який використовує передиктивну попередню вибірку. Guess підключається до вашого аналітичного сервісу та підбирає найбільш ймовірну наступну сторінку, ґрунтуючись на поточній поведінці користувача.

Preload

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

AMP

AMP попередньо завантажується у пошукову видачу, тому частина сайту вже завантажена до натискання. Перевага AMP полягає в тому, що візуальне завантаження сторінки виконується ще до натискання. AMP виглядає швидше, ніж звичайні веб-сторінки, які з’являються в результатах пошуку, тому що видима частина вже завантажена.

AMP має інші переваги, тому ми рекомендуємо розглянути цей варіант. Проте це ще одна система, яку потрібно підтримувати, і вона має нюанси, з якими необхідно ознайомитися до використання.

Тестування швидкості сторінки та інструменти

Лабораторні та польові дані

Лабораторні дані. Характерними рисами є контрольоване середовище, повторюваність процесу контроль параметрів. PageSpeed ​​Insights – чудовий приклад. Тест проводиться в тому самому середовищі з однаковими налаштуваннями, і результати будуть приблизно однаковими при кожному запуску.

Польові дані. Моніторинг реального користувача (RUM) це те, як користувачі сприймають ресурс. Він враховує все, наприклад, кешування, пристрої та мережі, але обмежений за показниками та можливостями налагодження.

Будьте обережні з тим, як довго ви використовуєте інструменти Real User Monitoring (RUM). Хоча ці інструменти добре підходять для того, щоб побачити, як завантажуються сторінки для користувачів, вони також можуть збільшити час завантаження. Ваша мета – зробити сайт швидше, і ці інструменти можуть бути корисними для діагностики проблем. Пам’ятайте – якщо їх залишити увімкненими, вони можуть призвести до уповільнення завантаження.

Інструменти для вимірювання швидкості сторінок

Google Tools

  • TestMySite містить карту показників швидкості, в якій ви можете оцінити свою швидкість порівняно з конкурентами, має калькулятор впливу, щоб ви могли оцінити вплив швидкості на ваш бізнес, і дозволяє вам створити звіт з важливими рекомендаціями Lighthouse (у Chrome Dev Tools) – дозволяє тестувати продуктивність сторінок та програм.
  • PageSpeed ​​Insights запускає Lighthouse і надає рекомендації. На запуск Lighthouse у вашому браузері впливають багато речей, таких як ваш комп’ютер, мережа, розширення у браузері. PageSpeed ​​Insights дозволяє створити досить стабільне тестове середовище, яке навіть не використовує ресурси вашого сервера.
  • Інструменти розробника Chrome – безліч корисних функцій, що дозволяють дізнатися, що та як завантажується на сторінці.
  • Chrome User Experience Report (CrUX) – загальнодоступна база реальних даних про досвід користувача тих, хто вирішив поділитися ними в Chrome, що охоплює мільйони веб-сайтів.
  • dev – ще один інструмент тестування Google, який підтримує Lighthouse. У ньому також міститься розділ для отримання додаткової інформації про швидкість сторінок.

Інші популярні інструменти для підвищення швидкості

  • WebPageTest
  • io
  • SpeedCurve
  • Calibre
  • Rigor
  • New Relic
  • Boomerang

Аудит сайту> Продуктивність

Інструмент Ahrefs «Аудит сайту» також містить деяку інформацію про швидкість сторінки. Є звіт для TTFB і Load Time, тобто скільки часу нам знадобилося, щоб завантажити ресурс.

Рекомендації Ahrefs:
  • Pagespeed Insights – вибіркова перевірка окремих сторінок. Також добре працює їх API. Він дозволяє безкоштовно проводити 25 тисяч тестів на день та надає безліч показників, включаючи дані на рівні CrUX. Можна не зважати на загальний показник. Як ми бачили, швидкість – складна штука. Ви можете покращити деякі показники, але не покращити свій результат.
  • WebPageTest – функція блокування, відео та карта запитів. Також API для тестування блокування масштабу.
  • GTmetrix – звіт про ланцюжок запитів.
  • CrUX – дослідження регіонів, гістограми, порівняння конкурентів.
  • dev – чудова документація.

Які дані використовує Google для визначення швидкості сторінки

Як розповів аналітик Google Webmaster Trends Джон Мюллер, Google використовує теоретичну швидкість сторінки (з використанням лабораторних даних) та реальні дані користувачів, які намагалися використати ці сторінки. За його словами, це схоже на дані звіту Chrome User Experience Report.

Насправді не було жодного публічного підтвердження, яке джерело даних вони використовують. Хоча Джон не каже, що вони залучають дані PageSpeed ​​Insights і CrUX, дані з них, швидше за все, є репрезентативними для тих, хто використовує Google. Припускаємо, що як лабораторні дані вони звертаються до показників, отриманих у процесі рендерингу і, швидше за все, у них присутній внутрішній ресурс, аналогічний CrUX, який вони використовують для отримання польових даних.

Оцінка впливу змін

Найпростіший спосіб оцінити вплив – зробити статичну копію сторінки. Скопіюйте код на сервер і протестуйте сторінку, щоб отримати базову метрику. Додайте зміни до неї та знову протестуйте, щоб отримати приблизний вплив змін. За підсумками, коли ви будете вносити їх на живому сайті, стане зрозумілим приблизний вплив.

Висновок

Ви повинні зробити сайт максимально швидким для користувачів.

Виберіть показники, які відображають те, як користувач сприймає завантаження та інтерактивність ресурсу, та покращуйте їх. Насправді, немає порога поліпшення швидкості, але часто настає етап, коли вигода може коштувати часу, зусиль, витрат чи потенційних компромісів (наприклад, втрати даних із інструмента). Загалом, потрібно просто бути швидше за конкурентів.