Чому WordPress повільний - і що насправді це виправляє

2 хв читанняWordPressшвидкістьCore Web Vitals

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

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

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

За чим вас насправді оцінює Google

Не за абстрактною «швидкістю», а за трьома показниками Core Web Vitals. Пороги опубліковані і однакові для всіх:

  • LCP - за скільки з'являється найбільший елемент екрана. Добре: до 2.5 секунди.
  • INP - за скільки сторінка відповідає на дію користувача. Добре: до 200 мілісекунд.
  • CLS - наскільки вміст стрибає під час завантаження. Добре: до 0.1.

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

Порядок, у якому це варто прибирати

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

Друге за віддачею - шрифти. Кожне звернення до Google Fonts це окреме з'єднання з чужим доменом перед тим, як з'явиться перша буква. Той самий файл, покладений поруч із сайтом і підвантажений заздалегідь, прибирає це очікування.

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

Кешування прискорює віддачу сторінки. Воно не робить сторінку легшою. Якщо у вас 4 МБ на головній, кеш віддасть ті самі 4 МБ, просто швидше почне.

Окрема розмова: білдери

Elementor, WPBakery та подібні вирішують реальну задачу - дати людині без розробника змінювати сторінки. Ціна цього в тому, що вони описують верстку через вкладені обгортки, і одна секція може перетворитися на десяток div-ів із інлайновими стилями. Плюс власний CSS і JS на кожній сторінці.

Альтернатива, яка зберігає редагованість, - Gutenberg із ACF Flexible Content. Клієнт так само збирає сторінку з готових блоків у адмінці, але кожен блок - це ваш власний шаблон, який віддає рівно ту розмітку, яку ви написали. Редагованість лишається, зайва вага зникає.

Коли переписувати, а коли лікувати

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

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