Блог

Медленная страница, которая важна, — не главная

Когда начальник говорит, что сайт медленный, первым делом нужно решить, какую страницу ускорять.

Резюме

Когда начальник говорит, что сайт медленный, первое желание — начать сжимать изображения и извиняться за главную страницу. Более полезный шаг — решить, какую страницу на самом деле стоит ускорить в первую очередь. В этой статье рассматривается один сценарий: небольшая маркетинговая команда получила задачу «исправить скорость» для среднего B2B-сайта. В ней рассказывается, как измерять Core Web Vitals с помощью полевых данных, выбирать страницы по влиянию на бизнес и добавлять структурированные данные только после дешёвых исправлений. Результат — короткий, обоснованный план, понятный нетехническому начальнику.

Самая медленная страница на вашем сайте — не та, которую выделяет PageSpeed Insights. Это страница, которую ваш начальник никогда не открывал — та, что связана с платной кампанией, или похоронена в забытом разделе товаров, — и именно она определяет, принесёт ли бюджет этого месяца хоть что-то. Когда руководитель говорит: «сайт медленный, исправь», ему нужен не проект по ускорению сайта, а упражнение по расстановке приоритетов.

Рассмотрим сценарий, знакомый многим из нас. Вы — вся маркетинговая команда компании среднего размера, занимающейся B2B-программным обеспечением. На сайте есть главная страница, блог, справочный центр и пять посадочных страниц, привязанных к конкретным рекламным кампаниям. Ваш начальник прочитал статью о Core Web Vitals или услышал жалобу клиента. Инструкция ясна: сделайте быстрее.

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

Начните со страницы, которая приносит деньги, а не с той, которая смущает

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

Поэтому первый шаг — составить список страниц из аналитики, а не из карты сайта. Какие страницы приносят деньги в виде кликов по рекламе? Какие страницы не трогали с момента запуска? В этом сценарии самая важная посадочная страница — та, что стоит за платным поисковым объявлением, которое показывается уже два месяца, — была сделана с большими неоптимизированными скриншотами. Главная страница, для сравнения, была оптимизирована агентством год назад.

Вы не чините главную страницу в первую очередь. Вы чините страницу, которая приносит деньги. Это не технический выбор, а бизнес-решение. Если полный технический аудит кажется правильным ответом, на минуту удержитесь. Аудиты дают список; они не говорят, с чего начать. Чётко ограниченный технический SEO-аудит — это инструмент принятия решений, а не паническая реакция.

Часто оказывается, что небольшое количество страниц приносит большую часть трафика и конверсий; остальные — информационные или рудиментарные. Это не повод игнорировать медленные информационные страницы вечно. Это повод поставить их в очередь после страниц, которые напрямую влияют на выручку. Главная страница может быть самой медленной из всех, но если бизнес-цель — лиды, посещение главной — это лишь отправная точка: конверсия происходит именно на посадочной странице.

Разделите «быстро» на «измеренное» и «ощущаемое»

Второй шаг — отделить то, что говорят тесты производительности о вашей странице, от того, что испытывают реальные пользователи. Документация Google по Core Web Vitals называет три метрики, которые влияют на ранжирование в поиске: Largest Contentful Paint (загрузка), Interaction to Next Paint (отзывчивость) и Cumulative Layout Shift (визуальная стабильность). Они важны, потому что отслеживают моменты, которые влияют на то, может ли человек реально использовать страницу.

В сценарии вы открываете посадочную страницу в тестере производительности и получаете приемлемую оценку. Но когда вы сравниваете это с полевыми данными в Google Search Console — которые отражают реальный опыт посетителей, — страница оказывается часто медленной. Именно этот сигнал важен. Лабораторные тесты по-прежнему полезны после изменения, чтобы сравнить «до» и «после». Но полевые данные — это истина в последней инстанции для людей, которые перешли по вашему объявлению с разных устройств и соединений.

Вместо этогоНачните с этогоПочему
Оценка PageSpeed как одно числоПолевые данные Core Web VitalsПолевые данные получены от реальных пользователей, а не от тестового сервера
«Сайт медленный»Какие страницы поддерживают бизнес-целиБыстрые бесполезные страницы не создают лидов
Переделка CMSСжимайте изображения и очищайте скриптыНизкорисковые исправления дают большую часть выгоды

Если позже захотите более глубокий справочник, руководство по Core Web Vitals поможет разобраться с каждой метрикой. Но сейчас вам достаточно того, что нужно для составления плана. Ключ — определить, какая из трёх метрик на самом деле вызывает проблему на этой конкретной странице. Если текст появляется поздно, смотрите на изображения и ответ сервера. Если кнопки работают с задержкой, смотрите на длительные задачи JavaScript. Если макет прыгает, смотрите на места, зарезервированные под рекламу и встраиваемые элементы. Именно такая детализация отличает целевую оптимизацию от случайной.

Сначала исправьте дешёвое, потом дорогое

Третий принцип: не позволяйте проекту по производительности превратиться в редизайн. Большинство улучшений, которые действительно влияют на пользовательский опыт, неприглядны и дёшевы.

Посмотрите на посадочную страницу и назовите очевидных виновников. Изображения — скриншоты в полном разрешении. На странице есть сторонний скрипт, который уже никто не может опознать. Веб-шрифт блокирует отображение текста. Это знакомые проблемы.

В идеальном мире вы бы потратили неделю на переписывание страницы на современном фреймворке. На практике вы начинаете с задач на полдня: сжимаете изображения, откладываете неиспользуемый скрипт, предзагружаете главное изображение. Эти изменения можно проверить за один день, и они не требуют комитета по утверждению.

Предостережение: скорость не всегда так проста. Некоторые страницы медленны из-за сервера, базы данных или сторонней зависимости, которую вы не контролируете. Но если вы не проверили дешёвые исправления, вы ещё не можете оправдать дорогое. Многие команды тратят бюджет на переработку, потому что так и не сжали скриншоты. Здесь стоит сохранить смирение: оценка производительности — это симптом, а не диагноз. Дешёвые исправления сами по себе диагностичны. После сжатия изображений вы узнаете, был ли узким местом ваш контент или инфраструктура.

Добавьте структурированные данные, раз уж вы в коде

Это тот уровень, который удивляет начальника. После дешёвых исправлений вы уже внутри страницы. Это подходящий момент, чтобы добавить то, что вовсе не связано со скоростью: структурированные данные.

Структурированные данные — это разметка, которая помогает поисковым системам понять, что содержится на странице. Это тот же HTML, который может привести к более богатым результатам поиска и лучшей видимости — и он становится всё более актуальным по мере того, как поиск смещается в сторону ответов, генерируемых ИИ. Для небольшой команды это недооценённый рычаг, потому что он не требует написания нового контента. Вы просто маркируете то, что уже существует.

В сценарии вы добавляете на посадочную страницу схему, ориентированную на услуги. Точный тип зависит от того, о чём страница: страница услуги, статья, продукт. Не нужно добавлять все типы сразу. Лучше добавить один аккуратно, чем десять наспех. Никакой результат не гарантирован; Google решает, что показывать. Но риск низок, а потенциальная выгода реальна. Если вы решите углубиться, руководство по внедрению структурированных данных описывает практические шаги.

Переводите исправления в «принесло ли это деньги?»

Сложнее всего не техническая работа, а то, как вы представляете её нетехническому начальнику.

Ваш начальник просил об одном: сделать сайт быстрее. Если вы скажете «мы улучшили LCP на посадочной странице», вы, возможно, увидите недоумённый взгляд. Вместо этого переведите работу в бизнес-последствия.

В этом сценарии посадочная страница — конечный пункт платной кампании. Каждая секунда ожидания — это секунда, в течение которой посетитель может уйти до появления призыва к действию. Поэтому вы объясняете: мы убрали очевидные препятствия на странице, где происходят денежные операции. Вы не можете обещать конкретный скачок в ранжировании — любой, кто это делает, гадает, — но вы можете привести разумные и честные аргументы. Вы также можете связать это с бюджетом, который ваш начальник уже понимает. Те же рекламные расходы покупают визит; разница в том, есть ли у этого визита шанс стать лидом.

Простой ежемесячный отчёт работает лучше, чем панель инструментов, перегруженная жаргоном. Покажите три вещи: какую страницу вы выбрали, какую метрику измерили и что изменили. Если метрика улучшилась, это подтверждение. Если нет, у вас всё равно есть чёткий эксперимент для переоценки. Не гонитесь за одним показателем месяц за месяцем; Core Web Vitals колеблются в зависимости от структуры трафика, типов устройств и даже географического региона. Сообщайте о тенденции, а не о числе.

Что делать в следующий понедельник

Урок из сценария: вы не чините «сайт». Вы чините конкретную страницу на основе данных и получаете повторяемый процесс, а не разовый проект. Когда влиятельный человек говорит «сделайте быстрее», самый полезный ответ — один уточняющий вопрос: какая страница и для кого?

Затем измеряйте полевые данные, исправляйте дешёвые проблемы, добавляйте структурированные данные, если вы уже в коде, и сообщайте о результатах простым языком. Результаты могут быть не драматичными. Но вы будете точно знать, какая страница стала быстрее, почему вы выбрали именно её и что делать дальше. Это лучший результат, чем расплывчатый проект, который начался с оценки скорости и закончился редизайном, которого никто не понял.

Sources (5)