Почему медицинскому сайту сложно пройти Core Web Vitals: кейс WordPress-клиники

Медицинскому сайту недостаточно поставить кеш-плагин, чтобы пройти Core Web Vitals. Разбираем на примере WordPress-клиники, почему LCP, INP и CLS ломаются из-за врачей, форм записи, карт, отзывов, юридических блоков и сторонних скриптов — и что с этим делать без потери доверия и конверсии.

Core Web Vitals часто воспринимают как задачу из серии «поставить кеш-плагин, сжать картинки и получить зелёную зону». На обычном блоге или небольшом лендинге это иногда работает. На сайте медицинской клиники — почти никогда.

Причина не в том, что WordPress «медленный». Причина в архитектуре медицинского сайта: много шаблонов, карточки врачей, цены, формы записи, карты, отзывы, лицензии, виджеты мессенджеров, сложные меню, изображения до/после, юридические блоки и трекинг. Всё это нужно бизнесу, юристам, маркетологам и пациентам. Но всё это же бьёт по LCP, INP и CLS.

Google сейчас оценивает Core Web Vitals через три ключевые метрики: LCP — скорость появления главного контента, INP — отзывчивость интерфейса, CLS — визуальная стабильность. Хорошие ориентиры: LCP до 2,5 секунды, INP менее 200 мс, CLS менее 0,1. Google также прямо рекомендует владельцам сайтов добиваться хороших Core Web Vitals для поиска и пользовательского опыта.

Разберём на обезличенном кейсе WordPress-клиники, почему медицинскому сайту сложнее пройти Core Web Vitals, какие ошибки встречаются чаще всего и что действительно даёт эффект.

Кейс: WordPress-сайт стоматологической клиники

Для разбора использовался типовой WordPress-сайт стоматологической клиники: https://medalye-stom.ru/. На таких проектах одновременно важны SEO-структура, блоки доверия, формы записи, юридические элементы, скорость загрузки и корректный рендер для поисковых систем.
Исходные вводные:

WordPress;
кастомная тема;
100+ страниц услуг;
карточки врачей;
прайс-лист;
блог;
отзывы;
формы записи;
карта;
онлайн-чат;
WhatsApp/Telegram-кнопки;
SEO-плагины;
кеш и минификация;
CRM-скрипты;
аналитика;
пиксели рекламы.
Сайт выглядит хорошо: много доверительных блоков, реальные врачи, лицензия, цены, портфолио, FAQ, формы записи. Но PageSpeed Insights показывает нестабильную картину: на десктопе всё терпимо, на мобильных — красная или жёлтая зона.

Типовая диагностика:

Метрика
Было
Целевое значение
Основная причина

LCP
 4,2–6,0 с
≤ 2,5 с
тяжёлый первый экран, фоновые изображения, CSS/JS

INP
280–600 мс
< 200 мс
меню, формы, виджеты, тяжёлый JS

CLS
0,12–0,30
< 0,1
баннеры, шрифты, lazyload, изображения без размеров

TTFB
0,12–0,30
чем ниже, тем лучше
PHP, база, кеш, хостинг, плагины

Важно: эти цифры — не публичный отчёт конкретной клиники, а типовой профиль проблемы для WordPress-сайта медицинской тематики.

Почему медицинский сайт сложнее обычного лендинга

У медицинского сайта конфликт целей.

Маркетинг хочет больше блоков доверия. Юристы хотят дисклеймеры и согласия. Врачи хотят точность и подробность. SEO хочет семантические страницы. Разработчики хотят не трогать старую тему. Пользователь хочет, чтобы всё открылось быстро.

В итоге страница услуги превращается в комбайн:

1. первый экран с большим изображением;
2. меню на 50–100 ссылок;
3. блок цен;
4. карточка врача;
5. форма записи;
6. квиз;
7. отзывы;
8. портфолио;
9. FAQ;
10. лицензия;
11. карта;
12. мессенджеры;
13. аналитика;
14. рекламные пиксели.
15. Каждый блок сам по себе оправдан. В сумме они создают нагрузку.

LCP: почему главный экран клиники грузится долго

LCP чаще всего ломается из-за первого экрана. На медицинских сайтах это обычно hero-блок с врачом, пациентом, кабинетом или 3D-иллюстрацией.

Типовые проблемы:

• изображение первого экрана весит 500 КБ–2 МБ;
• картинка подключена как CSS background;
• изображение lazy-loaded, хотя оно находится в первом экране;
• нет preload для LCP-ресурса;
• WebP/AVIF не настроены;
• мобильная версия получает десктопное изображение;
• критический CSS не отделён от остального;
• шрифты блокируют отрисовку;
• баннеры и попапы грузятся до основного контента.

WordPress с версии 6.3 начал автоматически добавлять fetchpriority=»high» к изображению, которое считает вероятным LCP-элементом, и это может улучшать LCP для страниц с изображениями. Но автоматическая логика не спасает, если тема выводит hero как background-image или если разработчик вручную ломает приоритеты загрузки.

Что сделали в кейсе

Первый экран был переписан так, чтобы LCP-изображение было обычным <img>, а не CSS-фоном.

Было:

<section class=»hero» style=»background-image: url(‘/uploads/doctor-big.jpg’)»>

  <h1>Имплантация зубов</h1>

</section>

Стало:

<section class=»hero»>

  <picture>

    <source srcset=»/uploads/doctor-mobile.webp» media=»(max-width: 768px)»>

    <source srcset=»/uploads/doctor-desktop.webp» media=»(min-width: 769px)»>

    <img

      src=»/uploads/doctor-desktop.webp»

      width=»960″

      height=»640″

      alt=»Врач стоматологии на консультации»

      fetchpriority=»high»

      decoding=»async»>

  </picture>

  <div class=»hero__content»>

    <h1>Имплантация зубов</h1>

    <p>Диагностика, план лечения и консультация имплантолога.</p>

  </div>

</section>

Дополнительно:

Подпишитесь на рассылку журнала!

Отвечайте на запросы журналистов на Pressfeed и получайте публикации в СМИ! В первом письме промокод на 3 дня безлимитных ответов

Даю согласие на обработку моих персональных данных в соответствии с Политикой обработки персональных данных

убрали lazyload с первого изображения;
сделали отдельные размеры для mobile/desktop;
добавили width и height;
сжали изображение;
вынесли критический CSS первого экрана;
отложили неважные скрипты.

INP: почему сайт клиники плохо реагирует на действия

INP — самая неприятная метрика для WordPress-клиники. LCP часто лечится изображениями и кешем. CLS — размерами и резервированием места. А INP требует разбираться в JavaScript.

Google описывает INP как метрику отзывчивости страницы; хороший ориентир — менее 200 мс.

На медицинском сайте интерактивности много:

• бургер-меню;
• выпадающие списки услуг;
• квизы;
• формы записи;
• маски телефона;
• календарь;
• чат;
• мессенджеры;
• аккордеоны FAQ;
• фильтры врачей;
• табы цен;
• всплывающие окна;
• карты.

Проблема не в одном скрипте. Проблема в суммарной конкуренции за main thread.

Типичный набор виновников INP
 

Источник
Как влияет

Конструктор страниц
добавляет универсальный JS на все страницы

Квиз
вешает обработчики на множество элементов

Онлайн-чат
грузит сторонний JS

Маска телефона
иногда подключается на всех страницах

Слайдеры
инициализируются даже вне viewport

Карта
блокирует main thread при загрузке

Tag Manager
подтягивает ещё 5–15 скриптов

Меню услуг
тяжёлый DOM и обработчики

Что сделали в кейсе

Разделили JavaScript по принципу «нужен сейчас / нужен потом / не нужен на этой странице».

Пример условной загрузки скрипта в WordPress:

add_action(‘wp_enqueue_scripts’, function () {

    if (is_page_template(‘templates/service.php’)) {

        wp_enqueue_script(

            ‘service-page’,

            get_template_directory_uri() . ‘/assets/js/service-page.js’,

            [],

            ‘1.0.0’,

            true

        );

    }

    if (is_page(‘contacts’)) {

        wp_enqueue_script(

            ‘map’,

            get_template_directory_uri() . ‘/assets/js/map.js’,

            [],

            ‘1.0.0’,

            true

        );

    }

});

Что убрали с большинства страниц:

• карту;
• слайдеры, которые не используются;
• скрипты старых форм;
• лишние библиотеки анимаций;
• JS виджетов, которые видны только после клика;
• квиз с верхней части страницы.

Для чата и мессенджеров сделали delayed loading: сначала статичная кнопка, затем загрузка виджета по клику.

document.querySelector(‘.js-open-chat’).addEventListener(‘click’, () => {

  import(‘./chat-widget.js’).then(module => {

    module.initChat();

  });

});

Это не магия. Просто пользователь не должен платить INP за виджет, которым он ещё не воспользовался.

CLS: почему страница «прыгает»

CLS особенно часто встречается на медицинских сайтах из-за визуальных блоков:

• баннеры акций;
• sticky header;
• изображения врачей;
• lazyload-картинки;
• блоки отзывов;
• карты;
• формы записи;
• шрифты;
• всплывающие предупреждения;
• плашка согласия cookie.

Google считает CLS метрикой визуальной стабильности, а хорошим значением указывает менее 0,1.

Типовые причины CLS в WordPress-клинике

1. У изображений нет width и height.
2. Карточки врачей грузят фото с разными пропорциями.
3. Блок отзывов получает высоту после загрузки JS.
4. Cookie-баннер вставляется сверху и двигает страницу.
5. Шрифты меняют размеры текста после загрузки.
6. Рекламный или CTA-блок появляется без зарезервированного места.
7. FAQ раскрывается с резкой перестройкой layout.

Что сделали в кейсе

Для изображений врачей зафиксировали пропорции:

.doctor-card__photo {

  aspect-ratio: 3 / 4;

  width: 100%;

  object-fit: cover;

}

Для карты поставили контейнер с высотой до загрузки:

.map-placeholder {

  min-height: 420px;

  background: #f2f5f7;

}

Для cookie-баннера запретили вставку сверху:

.cookie-banner {

  position: fixed;

  left: 24px;

  right: 24px;

  bottom: 24px;

  z-index: 1000;

}

Для шрифтов использовали font-display: swap и подобрали fallback-шрифт ближе по метрикам.

@font-face {

  font-family: ‘ClinicSans’;

  src: url(‘/fonts/clinic-sans.woff2’) format(‘woff2’);

  font-display: swap;

}

Почему кеш-плагин не решает всё

WordPress-документация прямо указывает, что на производительность влияют хостинг, конфигурация WordPress, версии ПО, количество изображений и размеры файлов. Там же кеширование называется важным направлением оптимизации, но не единственным.

Кеш решает TTFB и часть server-side проблем. Но он не исправит:

• тяжёлое LCP-изображение;
• блокирующий CSS;
• плохой JS;
• CLS от картинок без размеров;
• сторонние виджеты;
• большой DOM;
• лишние плагины;
• плохую архитектуру шаблонов.

Кеш — это фундамент. Но если на фундамент поставить тяжёлый интерфейс, пользователь всё равно будет ждать.

Медицинская специфика: нельзя просто удалить всё лишнее

В ecommerce можно убрать часть декоративных блоков без боли. В медицине сложнее.

Нельзя просто удалить:

• блок врача;
• лицензию;
• цены;
• дисклеймер;
• форму записи;
• FAQ;
• отзывы;
• юридические согласия;
• карту;
• контакты.

Эти блоки нужны для доверия и конверсии. Поэтому задача не «удалить», а правильно распределить приоритеты загрузки.

Как расставить приоритеты

Блок
Загружать сразу?
Комментарий

H1 и первый текст
Да
Критичный контент

Главное изображение
Да
Часто LCP

Цены
Да, если выше fold
Важный коммерческий блок

Форма записи
Да, если в первом экране
Иначе можно отложить

Врач
Да/частично
Фото оптимизировать

Отзывы
Нет
Можно lazy-load

Карта
Нет
Только по клику или ниже

Чат
Нет
По клику

Квиз
Нет
После первого взаимодействия

FAQ
HTML сразу, JS отложить
Контент нужен SEO

Виджеты соцсетей
Нет
Часто дорогие

Технический план оптимизации

Шаг 1. Разделить данные: lab и field
PageSpeed Insights показывает и лабораторные данные, и полевые, если они доступны. Search Console группирует URL по статусу, метрике и похожим страницам; в отчёте Core Web Vitals используются данные за 28 дней и 75-й перцентиль запросов страниц.

Для клиники важно смотреть не одну страницу, а типы шаблонов:

• главная;
• услуга;
• врач;
• прайс;
• блог;
• контакты;
• категории услуг.

Если плохо только на контактах — виновата карта. Если плохо на всех услугах — виноват общий шаблон.

Шаг 2. Найти LCP-элемент
В Chrome DevTools:

1. Performance;
2. Record;
3. Reload page;
4. найти LCP marker;
5. посмотреть, что стало LCP.

Часто это:

• hero-image;
• H1;
• баннер;
• карточка акции;
• фоновое изображение.

Если LCP — картинка, работаем с картинкой. Если H1 — проблема чаще в шрифтах, CSS или TTFB.

Шаг 3. Разобрать CSS
Типовая WordPress-тема клиники тащит один общий CSS на весь сайт. Внутри стили для:

• главной;
• услуг;
• врачей;
• блога;
• квиза;
• слайдеров;
• карт;
• попапов.

Решение:

• выделить critical CSS;
• грузить шаблонный CSS условно;
• удалить стили неиспользуемых блоков;
• не использовать огромный UI-kit ради пары кнопок.
  Пример:

if (is_singular(‘service’)) {

    wp_enqueue_style(‘service-page’, get_template_directory_uri() . ‘/assets/css/service.css’);

}

if (is_singular(‘doctor’)) {

    wp_enqueue_style(‘doctor-page’, get_template_directory_uri() . ‘/assets/css/doctor.css’);

}

Шаг 4. Разобрать JS
Главное правило: интерактив ниже первого экрана не должен ухудшать первый экран.

Что можно отложить:

• карту;
• чат;
• квиз;
• отзывы;
• карусели;
• видео;
• формы внизу страницы.

Что нельзя ломать:

• навигацию;
• доступность;
• форму, если она в первом экране;
• отправку заявок;
• юридические чекбоксы.

Шаг 5. Оптимизировать изображения
Для сайта клиники изображения почти всегда главная зона роста:

• врачи;
• кабинеты;
• сертификаты;
• до/после;
• 3D-иллюстрации;
• баннеры;
• фото оборудования.

Минимальный стандарт:

<img

  src=»/uploads/implantolog.webp»

  srcset=»/uploads/implantolog-480.webp 480w,

          /uploads/implantolog-768.webp 768w,

          /uploads/implantolog-1200.webp 1200w»

  sizes=»(max-width: 768px) 100vw, 50vw»

  width=»768″

  height=»1024″

  loading=»lazy»

  decoding=»async»

  alt=»Стоматолог-имплантолог на консультации»>

Но для LCP-изображения loading=»lazy» использовать не нужно.

Что делать с robots.txt

Отдельная частая ошибка: CSS и JS закрыты в robots.txt.

В медицинском WordPress-сайте это встречается из-за правила:

Disallow: /*?*

Оно закрывает все URL с параметрами. А стили и скрипты часто подключаются так:

/wp-content/cache/wpo-minify/header.css?ver=123

/wp-content/themes/theme/scripts.js?ver=456

Если CSS/JS закрыты, поисковик хуже видит страницу. Нужно оставлять параметры закрытыми, но разрешать ресурсы:

Allow: /wp-content/themes/

Allow: /wp-content/plugins/

Allow: /wp-content/cache/

Allow: /*.css

Allow: /*.css?*

Allow: /*.js

Allow: /*.js?*

Allow: /*.woff2

Allow: /*.webp

Allow: /*.svg

Это не ускоряет сайт напрямую. Но помогает поисковым системам корректно рендерить страницу.

Почему WordPress-клиника часто проигрывает INP после «оптимизации»

Парадокс: после установки плагина оптимизации сайт может стать хуже.

Почему:

• JS объединяется в один большой файл;
• критичный и некритичный код смешивается;
• deferred-скрипты ломают порядок выполнения;
• lazyload применяется к LCP-картинке;
• CSS инлайнится слишком агрессивно;
• preload ставится на всё подряд;
• старые минифицированные файлы начинают отдавать 404.

Правильная оптимизация — не «включить все галочки», а профилировать.

Плохой подход:

Включить minify, combine, defer, delay JS, lazyload, preload everything.

Хороший подход:

Найти LCP, INP и CLS-причины по шаблонам страниц и исправлять конкретные узкие места.

Наблюдения из кейса

Самые сильные эффекты дали не плагины, а архитектурные решения.

Действие
 На что повлияло
Почему сработало

Переделали hero-image
LCP
Браузер стал раньше видеть главный ресурс

Убрали lazyload с LCP
LCP
Главное изображение не откладывалось

Разделили CSS по шаблонам
LCP
Меньше render-blocking CSS

Отложили чат и карту
INP
Меньше JS на старте

Убрали лишние слайдеры
INP
 
Меньше main-thread работы

Задали размеры изображениям
CLS
Layout перестал прыгать

Зафиксировали места под блоки
CLS
Отзывы, карты и формы не сдвигали контент

Проверили robots

рендер
CSS/JS стали доступны ботам

Чек-лист для WordPress-клиники

Сервер и WordPress

• включён full-page cache;
• PHP актуальной версии;
• база не перегружена autoload-опциями;
• нет тяжёлых запросов на каждой странице;
• отключены неиспользуемые плагины;
• CDN отдаёт статику;
• gzip/brotli включены;
• кеш не создаёт битые CSS/JS.

Шаблоны

• CSS и JS подключаются по условию;
• нет одного гигантского bundle на весь сайт;
• hero-картинки не являются CSS background;
• LCP-изображение имеет высокий приоритет;
• изображения имеют размеры;
• карточки врачей имеют фиксированные пропорции;
• карта грузится ниже или по клику;
• чат грузится по клику.

Медицинские блоки

• лицензия не грузится тяжёлым PDF в первом экране;
• отзывы не инициализируют слайдер сразу;
• фото до/после оптимизированы;
• формы не тянут лишние библиотеки;
• квиз не блокирует первый экран;
• CTA не появляется с layout shift.

SEO и рендер

• CSS/JS не закрыты robots.txt;
• sitemap содержит только индексируемые URL;
• canonical корректен;
• нет noindex на важных услугах;
• нет редиректных цепочек;
• HTML содержит основной контент без ожидания JS.

Вывод
Медицинскому сайту сложно пройти Core Web Vitals не потому, что медицина особенная для браузера. А потому, что медицинский сайт перегружен бизнес-критичными элементами доверия: врачами, ценами, отзывами, лицензиями, формами, картами и юридическими блоками.

Задача разработчика — не удалить эти элементы, а правильно управлять их приоритетами.

Для WordPress-клиники оптимизация Core Web Vitals обычно требует не одного кеш-плагина, а нормальной инженерной работы:

• разнести ресурсы по шаблонам;
• выделить критический путь рендера;
• оптимизировать LCP-изображение;
• убрать лишний JS с первого экрана;
• стабилизировать layout;
• проверить рендер для поисковых роботов;
• не ломать юридические и медицинские блоки.

Core Web Vitals — это не про «зелёный кружок в PageSpeed». Это про то, может ли пациент быстро открыть страницу услуги, понять врача, цену, этапы лечения и записаться без раздражения.

Для медицинского сайта это уже не только техническая метрика. Это часть доверия.