Посібник з WPO для оптимізації швидкості вашого сайту

Що таке WPO?

Web Performance Optimization, що ми називаємо WPO, — це просто оптимізація різних процесів, що впливають на те, як завантажується сайт.

Як виміряти швидкість завантаження сайту?

Існує безліч інструментів для вимірювання швидкості завантаження. Найпопулярніші такі:

• ›

  Google Page Speed

• ›

  Lighthouse

• ›

  GTMetrix

Перш ніж розпочати аудит, важливо тримати в голові, що швидкість завантаження варіюється для кожного користувача. Різні змінні можуть впливати на те, як швидкість відчуває користувач у Куенці порівняно з користувачем в Оттаві.

Саме тому, замість роботи над часами завантаження в секундах, рекомендуємо зосередитися на оптимізації:

• ›

  Ваги сайту (МБ)

• ›

  Запитів

• ›

  Часу відгуку сервера

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

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

Інструменти розробника Google

Перш ніж почати, я хочу пояснити деякі опції, які Google пропонує через свої інструменти розробника. Цей інструмент — один з найважливіших для аналізу того, як працює сайт. Клацніть правою кнопкою миші на сторінку, яку відкрив браузер, і з'явиться панель з різними опціями. Підемо до Inspect (Ctrl + Shift + I).

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

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

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

• ›

  Name: ім'я ресурсу.

• ›

  Status: код відгуку ресурсу (200, 301, 404...)

• ›

  Type: тип ресурсу (script, font, png, jpg, stylesheet...)

• ›

  Initiator: який ресурс ініціює запит.

• ›

  Time: скільки часу зайняв запит.

• ›

  Waterfall: графічне представлення часів завантаження ресурсу.

Якщо клацнемо правою кнопкою вгорі, можемо додавати і видаляти стовпці з цією інформацією.

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

Є один аспект, що, хоч дуже цікавий, я лише злегка торкнусь, аби тримати в голові. Швидкість з'єднання, особливо на мобільному, — ключовий елемент того, як завантажується сайт. З цього інструмента ми можемо симулювати повільніші швидкості, як-от 3G на мобільному.

Як знати вагу URL і як її зменшити?

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

Наступні дані надходять від інструмента, згаданого вище, GTMETRIX, і відповідають сайту, який я ось-ось почну оптимізувати.

Ми зосередимось на даних у правому стовпці, що стосується (Page Details), зокрема Total Page Size.

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

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

Якщо подивитися внизу, як 7,5 МБ, так і 215 запитів дуже близькі до цифр, повідомлених GTMETRIX. Важливо для вас знати, звідки GTMETRIX отримує свою інформацію, на випадок, якщо колись захочете використати інший інструмент.

Тепер погляньмо, що так багато важить і як ми можемо це виправити.

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

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

Немає формальної специфікації для максимальної ваги, яку повинно мати зображення, але ми рекомендуємо не більше 100 КБ і, якщо у вас є опція (якщо використовуєте Photoshop, у вас вона є), налаштовувати зображення на завантаження поступово як JPG і уникати PNG, коли вам не потрібен Alpha-канал (прозорість).

Зменшуючи вагу зображень, ми значно покращимо завантаження сайту, і є кілька інструментів, якими можна скористатися. Я особисто оптимізую з Photoshop, але є цікаві онлайн-варіанти:

• ›

  https://imagecompressor.io/compress

• ›

  https://kraken.io/web-interface

Як GTMetrix, так і інструмент Google дозволяють нам переглядати ресурси за типом, тобто лише зображення, скрипти, CSS...

Це корисно для ширшої перспективи того, де працювати. На цьому URL зображення складають 4 МБ з 7,2 МБ, тож велика частина проблеми ваги там. І все ж, є інші ресурси, що виділяються як надзвичайно важкі для свого типу, як-от CSS-файл понад 700 КБ і Script понад 300 КБ.

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

У цьому випадку ми бачимо дуже великий CSS-файл. Якщо дизайнер створив CSS понад 700 КБ, оптимізувати цей конкретний файл буде складно.

Що ми можемо зробити, аби зменшити вагу цих файлів?

Мініфікація (CSS, JS і HTML)

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

Інструменти для мініфікації файлів

• ›

  HTML Minifier http://kangax.github.io/html-minifier/

• ›

  CSS Nano https://cssnano.co/

• ›

  Uglify http://lisperator.net/uglifyjs/

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

Особисто я люблю використовувати один повністю безоплатний, Autoptimize, і один платний, WP Rocket.

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

Мініфікація з WP Rocket

Ця частина не складна. Ми просто переходимо до вкладки оптимізації файлів і ставимо галочку minify HTML. У WP Rocket ця опція повторюється нижче для CSS- і JS-файлів. І все ж, я рекомендую увімкнути цей блок і протестувати. Повторіть цю опцію по одній, оскільки якщо щось не так, легше визначити проблему.

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

Як очистити кеш браузера?

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

Ще один спосіб — через браузер, як тільки увімкнено Google Developer Tools (Ctrl + Shift + I).

Клацніть правою кнопкою на стрілку «reload page» і оберіть «empty cache and hard reload».

Мініфікація з Autoptimize

З Autoptimize дія optimize — це те, що виконує мініфікацію, з особливістю пропонування опції зберегти HTML-коментарі. Ці коментарі зазвичай додаються розробниками, аби зберегти інформацію, що може бути корисною в майбутньому.

Аби перевірити, чи ця оптимізація набула чинності, ми б перейшли до вихідного коду URL і повинні побачити щось таке:

Код стає нечитабельним, але його функціональність та сама.

Ці опції повторюються тим самим способом у WP Rocket і Autoptimize для CSS- і JS-файлів. Як я згадав раніше, я не рекомендую оптимізовувати все одразу, а 1 за 1. Ці плагіни зберігають копії мініфікованих файлів, тож повернення до оригіналу можливе через зняття галочки відповідного блоку.

Аби продовжувати зменшувати вагу сторінки, у нас є ще 2 опції:

• ›

  Видалити чи зменшити плагіни, що додають CSS чи JS до завантаження.

• ›

  Видалити чи скоротити невикористаний код з CSS-файлу.

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

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

Час завантаження проти часу відгуку

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

Але робімо це крок за кроком.

Що таке запит?

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

Запити можуть бути або HTTP, або HTTPS. Якщо подивимося на структуру запиту, ми можемо проаналізувати, де відбувається затримка в часі.

Аналіз часу HTTP-запиту

Розберемо те, що ми бачимо на цій діаграмі тривалостей.

• ›

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

• ›

  DNS Lookup: браузер розв'язує IP-адресу запиту.

• ›

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

• ›

  Sending: запит ресурсу надіслано.

• ›

  Waiting: це час, що сервер потребує, аби розв'язати запит і надіслати відгук; якщо він довгий, на сервері є проблема.

• ›

  Receiving: отримання ресурсу.

HTTPS-запит додає ще один крок, показаний тут.

Ці два скріни належать двом різним сайтам, одному неоптимізованому (HTTP Request) і іншому оптимізованому (HTTPS Request).

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

Запити до сервера: як ми можемо їх зменшити?

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

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

Об'єднання CSS і JS

Ще одна популярна дія при оптимізації вебсторінки — це об'єднання CSS- і JS-ресурсів, але що це означає?

Мета об'єднання — зменшити запити коштом збільшення ваги файлу. Об'єднання означає уніфікацію різних CSS- чи JS-ресурсів в єдиний.

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

Ідеально — об'єднувати, маючи хороший сервер, аби ми вигравали з обох сторін.

Об'єднання ресурсів з WP Rocket і Autoptimize

Операція об'єднання з цими плагінами така ж проста, як і раніше. Ми просто ставимо галочку на відповідному блоці.

У WP Rocket опції для об'єднання CSS і JS однакові; панелі практично ідентичні. Як ми бачимо на зображенні, є блок для додавання шляху файлів, які ми не хочемо об'єднувати.

Нижче галочки ми також бачимо примітку про невикористання опції об'єднання, якщо ми використовуємо HTTP/2. У цій статті більше пояснюється про HTTP/2.

Autoptimize пропонує більше опцій для роботи з CSS і зменшення запитів. В опції, яку я виділяю, він об'єднує і дає вам попередження про ефект, який це може мати, але врешті це завжди відносно.

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

Налаштування кешу

Без сумніву, оптимізація кешу — одна з дій, де ми помітимо найбільші покращення в тому, як завантажується сайт. У цій статті про SEO для WordPress я пояснив, як працює кеш. Заохочую вас поглянути, аби зрозуміти, як він працює.

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

Як ви бачите, WP Rocket дозволяє вам працювати над 4 речами:

• ›

  Увімкнути кешування для мобільних пристроїв.

• ›

  Зберігати файли окремо для мобільних пристроїв.

• ›

  Увімкнути кешування для увійшлих користувачів.

• ›

  Вказати час очищення кешу.

Це залежить від кожного проєкту, яку опцію обрати, але з усім цим у голові моя порада така:

• ›

  Mobile cache завжди, бо хоч більшість сайтів — адаптивні, є вміст, який ви можете мати на мобільному, але не на desktop.

• ›

  Файли окремо.

• ›

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

• ›

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

Lazyload

Функція lazyload допомагає відображати ресурси (Зображення та Iframes), коли користувач їх потребує; тобто браузер не завантажує ці ресурси, поки користувач до них не прокрутить. Цю функцію впроваджено в багатьох плагінах і вона навіть постачається передналаштованою в деяких темах WordPress. З версії Chrome 76 і далі вона навіть постачається нативно в браузері.

Це означає, що додаючи атрибут loading="lazy", браузер уже інтерпретує lazy-завантаження зображення, але звичайно не кожен браузер це інтерпретуватиме, тож рекомендую продовжувати використовувати плагін. Ось відео, витягнуте з web.dev, що показує приклад того, про що йдеться у lazy-завантаженні зображень.

Оптимізація iframe

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

• ›

  Lazy-завантаження через функцію lazyload

• ›

  Або заміна iframe зображенням, поки користувач на нього не клацне.

Як перший, так і другий варіант можна увімкнути через, знову ж таки, наш улюблений плагін WP Rocket.

Autoptimize не має цієї частини, але пропонує встановлення доповнюючого плагіна, аби це зробити https://wordpress.org/plugins/wp-youtube-lyte/

Відкладене завантаження JS-файлів з Defer чи Async

JS-файли — одні з винуватців того, що аудити швидкості називають render blocking сторінки. Це відбувається, коли під час рендерингу браузер зупиняється, аби завантажити JS-файл і виконати його. Мета оптимізації WPO — якомога швидше доставити інформацію користувачу, ось чому це вважається блокуванням, бо нічого не рендериться, поки завантажений JS не виконається.

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

У цих випадках варто використовувати два атрибути, що додаються в коді виклику JS, Defer і Async. Аби ці атрибути працювали, скрипти мають бути зовнішніми.

В SEO Alive ми використовуємо плагін Pre Party Resource Hints, що дозволяє обирати, які файли і який метод завантаження ви хочете застосувати. Чудо!

Яка різниця між Defer і Async?

Хоч обидва атрибути мають подібну мету — запобігти зупинці інтерпретації DOM HTML через JS, є помітна різниця між цими двома.

З атрибутом Async ресурс завантажується без зупинки завантаження HTML, але як тільки завантажено, завантаження HTML призупиняється для виконання JS; з атрибутом defer ресурс також завантажується паралельно зі завантаженням HTML, але він запускається, коли завантаження закінчується, тож немає блокування скриптом.

У цьому плані є відмінності між WP Rocket і Autoptimize. WP Rocket робить рішення набагато простішими для вас і діє напівавтоматично, аби JS не блокував рендеринг; в Autoptimize, з іншого боку, ви можете лише перемикати опцію Async.

В Autoptimize, на вкладці extra маємо цю опцію, аби додавати JS-файли, які хочемо завантажувати з Async, але для більшої гнучкості рекомендують інший доповнюючий плагін, «Async Javascript».

З цим плагіном ми можемо працювати як з Defer, так і з Async, і він навіть пропонує опції одного кліку, аби спростити речі. Хороше у цьому плагіні те, що ми можемо працювати зі скриптами і виключати ті, що вважаємо необхідними. У WP Rocket, з іншого боку, нам доводиться довіряти тому, що робить плагін, хоч він робить це добре.

Ця опція знаходиться на тій же вкладці оптимізації файлів.

Що таке CDN і як він може нам допомогти?

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

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

Інші дії, що дадуть нам трохи більше покращення

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

Оптимізація шрифтів

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

Autoptimize має опцію для роботи зі шрифтами.

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

Як ви бачите, відразу після опцій Google Fonts маємо «Remove Emoji», що зекономить нам запит до сервера. Його функція — просто конвертувати символи, що представляють емоджі, в іконку.

WP Rocket також дозволяє нам деактивувати ці емоджі і також пропонує опцію запобігати тому, аби вміст вбудовувався на сайтах третіх сторін.

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

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