Швидкість сайту — це не просто "приємний бонус", а реальний фактор, який впливає і на користувацький досвід, і на конверсію. На одному з проєктів я отримав типовий запит: сайт на WordPress був візуально нормальним, але завантажувався повільно, особливо на мобільних пристроях. Показник LCP тримався на рівні 4.2 секунди, а це вже відчутно б'є по сприйняттю сторінки.
Найцікавіше, що я свідомо не пішов шляхом "встановимо ще 5 плагінів оптимізації". Замість цього я вирішив спочатку знайти реальні причини повільної роботи. Аналіз показав кілька типових проблем: занадто великі зображення, блокуючі CSS та JavaScript-файли, непотрібні сторонні скрипти і завеликий DOM на головній сторінці.
Перший крок був очевидним — оптимізація медіа. Я перевів зображення у сучасні формати, зменшив їхній фактичний розмір і прибрав випадки, де браузер завантажував картинку у 2000 px для блоку, який фізично займав лише 400–500 px. Також я додав коректні width і height, щоб уникнути стрибків макета під час завантаження.
Другий крок — критичний CSS. Замість того щоб завантажувати весь стильовий пакет одразу, я виніс базові стилі для першого екрана в head, а решту підключив відкладено. Це зменшило час до першого візуального відображення й дало браузеру швидше показати користувачу основний контент.
Третій блок змін стосувався JavaScript. Я переглянув усі підключення теми та прибрав код, який взагалі не використовувався на конкретній сторінці. Частину скриптів перевів на defer, а деякі функції ініціалізував тільки після взаємодії користувача. Наприклад, елементи, які не впливали на перший екран, перестали блокувати рендеринг.
Окремо я звернув увагу на шрифти. Часто саме вони непомітно створюють затримку, особливо якщо підключено кілька накреслень і зовнішній CDN. Я скоротив кількість варіантів, локально підключив потрібні файли і налаштував font-display: swap, щоб текст не зникав під час завантаження шрифтів.
Ще один важливий момент — сторонні сервіси. Аналітика, чати, віджети, кнопки соцмереж — усе це здається дрібницями, поки не подивишся waterfall у DevTools. Я залишив тільки те, що справді давало цінність бізнесу, а зайві інтеграції прибрав або відклав до моменту взаємодії.
У результаті LCP вдалося знизити з 4.2 секунди до 1.4 секунди. І головне — це було досягнуто без WP Rocket, без Autoptimize і без "магічної кнопки оптимізації". Висновок простий: перш ніж ставити плагіни, варто розібратися, що саме гальмує сайт. Часто найбільший приріст дає не автоматизація, а точкові технічні рішення.
Site speed isn't just a nice-to-have — it's a real factor that directly impacts user experience and conversion. On one of my projects, I got a typical request: the WordPress site looked fine, but loaded slowly, especially on mobile. LCP sat at 4.2 seconds, which is noticeably painful.
What's interesting — I consciously avoided the "install 5 more optimization plugins" route. Instead I decided to find the actual causes of the slowness first. Analysis showed typical issues: oversized images, blocking CSS and JavaScript files, unnecessary third-party scripts, and a too-heavy DOM on the landing.
First step was obvious — media optimization. I converted images to modern formats, reduced their actual size, and eliminated cases where the browser was loading a 2000px image for a block that only occupied 400–500px. I also added proper width and height attributes to prevent layout shift.
Second step — critical CSS. Instead of loading the entire stylesheet upfront, I extracted base styles for the first screen into the head and loaded the rest deferred. This reduced time-to-first-paint and let the browser render primary content faster.
Third block of changes targeted JavaScript. I reviewed all theme scripts and removed code that wasn't actually used on the specific page. Some scripts moved to defer, and certain functions were initialized only after user interaction. Elements that didn't affect the first screen stopped blocking rendering.
I also paid special attention to fonts. They often quietly create delay, especially when multiple weights are loaded from an external CDN. I reduced weight variants, self-hosted the necessary files and set font-display: swap so text wouldn't disappear during font load.
Another important point — third-party services. Analytics, chats, widgets, social buttons — it all feels like small stuff until you see the waterfall in DevTools. I kept only what genuinely delivered business value and removed or deferred the rest until user interaction.
The result — LCP dropped from 4.2s to 1.4s. And the key thing: this was achieved without WP Rocket, without Autoptimize, without any "magic optimization button". The conclusion is simple: before installing plugins, figure out what's actually slowing the site down. Often the biggest gain comes not from automation, but from targeted technical decisions.
