Як пришвидшити довгі сторінки Elementor через content-visibility

Що таке content-visibility і яку проблему вона вирішує

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

Значення content-visibility: auto повідомляє браузеру, що вміст конкретного елемента можна тимчасово не обробляти повністю, якщо він далеко за межами viewport. Коли користувач прокручує сторінку ближче до цього елемента, браузер готує його до відображення.

Властивість працює на рівні CSS і не видаляє контент зі сторінки. Текст, зображення та розмітка залишаються доступними в HTML, тому це не те саме, що приховування через display: none. Водночас ефект залежить від браузера, структури сторінки та кількості роботи, яку виконує кожна секція.

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

Як додати клас до секцій Elementor

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

Відкрийте потрібну секцію або контейнер у редакторі Elementor і знайдіть поле для CSS-класів у розширених налаштуваннях. Додайте клас lazy-section без крапки на початку. Крапка потрібна лише в CSS-селекторі, а не в самому полі Elementor.

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

• Не додавайте клас до Header, головного меню, hero-блоку та першого видимого екрана.
• Обережно працюйте із секціями, у яких містяться якорі, навігаційні цілі або елементи, що мають бути доступними відразу.
• Якщо сторінка побудована на контейнерах, призначайте клас зовнішньому контейнеру, який охоплює завершений блок.
• Після збереження очистьте кеш Elementor, кеш плагіна та CDN, якщо вони використовуються.

CSS для відкладеного рендерингу

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

.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 600px;
}

Навіщо потрібен contain-intrinsic-size

Коли браузер тимчасово не обробляє вміст секції, він має оцінити, скільки місця ця секція займає на сторінці. contain-intrinsic-size задає приблизний резервний розмір. У прикладі 600px — це не обов’язкова норма, а стартове значення, яке потрібно адаптувати до реальної висоти блоків.

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

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

Безпечний варіант із запасним правилом

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

.lazy-section {
  content-visibility: auto;
  contain-intrinsic-size: 600px;
}

/* Інші стилі секції залишаються звичайними */

До яких блоків не слід застосовувати правило

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

Не застосовуйте правило до hero-секції, логотипа, хедера, меню, основного заголовка, важливого заклику до дії та іншого контенту у першому екрані. Відкладене опрацювання таких елементів може ускладнити вимірювання Largest Contentful Paint або вплинути на сприйняття швидкості.

Обережність потрібна також для віджетів, які виконують JavaScript одразу після завантаження: слайдерів, карт, форм із залежними полями, вкладок, аккордеонів та інтерактивних фільтрів. Після приховування секції браузером скрипт може неправильно визначити її розміри або ініціалізувати компонент із затримкою.

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

Як перевірити результат після впровадження

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

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

Після цього порівняйте сторінку до і після змін у Lighthouse або PageSpeed Insights. Дивіться не тільки на загальний бал, а й на час завантаження, LCP, Cumulative Layout Shift, взаємодію зі сторінкою та довгі завдання JavaScript. Якщо покращення непомітне, причина може бути не в промальовуванні секцій, а у важких скриптах, зображеннях або шрифтах.

• Перевірте мобільну версію окремо: на ній обмеження ресурсів зазвичай відчутніші.
• Порівнюйте однакові умови тестування та кілька запусків, а не один випадковий результат.
• Переконайтеся, що CSS завантажується на опублікованій сторінці, а не лише в редакторі.
• Перевірте консоль браузера на JavaScript-помилки після додавання правила.
• Якщо з’явилися стрибки, збільште contain-intrinsic-size, розбийте великі секції або приберіть клас із проблемного блока.

Типові помилки та межі методу

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

Друга проблема — очікування, що content-visibility зменшить розмір усіх завантажених ресурсів. CSS не стискає зображення, не прибирає невикористаний JavaScript і не замінює lazy loading медіа. Якщо нижні блоки містять важкі зображення, оптимізуйте їх окремо: використовуйте відповідні розміри, сучасні формати та коректне відкладене завантаження.

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

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