{"id":13456,"url":"\/distributions\/13456\/click?bit=1&hash=6bf95d5850d39a632d71d9ebb94b8a4e644bc6a23b4e4c2644b39e47003b100d","title":"80 \u0442\u044b\u0441\u044f\u0447 \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u0438\u0441\u043a\u0430\u043b\u0438 \u043f\u0430\u0440\u0443 \u0434\u044b\u0440\u044f\u0432\u043e\u043c\u0443 \u043d\u043e\u0441\u043a\u0443 \u0441\u043f\u0435\u0446\u0430\u0433\u0435\u043d\u0442\u0430","buttonText":"\u0427\u0442\u043e\u043e\u043e?","imageUuid":"a05ce1a7-0771-5520-b8cb-45c9bdd65351","isPaidAndBannersEnabled":false}

Прокачка сайта за 3 недели: подготовились к Core Web Vitals, увеличили трафик с Google и автоматизировали рутины

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

Недавно к нам на поисковое продвижение зашел новый проект — организация, оказывающая услуги по вывозу строительного мусора «Увозов» — с проблемой: трафик с органической выдачи Google сильно провисает по сравнению с Яндексом.

Ежемесячно мы проводим аудит поискового продвижения 5–12 новым компаниям и ситуации, когда с одной поисковой системы идет больше трафика, чем с другой, для нас не в новинку. Дело в том, что поисковые системы по-разному подходят к формированию топа выдачи и используют разные алгоритмы оценки качества сайтов.

Яндекс лояльно относится к новым веб-ресурсам, а при их оценке большее значение придает поведенческим факторам — он может пустить на лидирующие позиции молодой сайт, о котором еще нигде не упоминается, и посмотреть, нравится он пользователям или лучше подобрать что-то поинтереснее? У Google подход другой — для него важнее цитируемость, возраст и скорость загрузки, поэтому новичкам приблизиться к топу сложно.

Так получилось и на этом проекте: несмотря на то, что сайт новый и требует доработок, он все равно получал высокие позиции в Яндексе, а вот Google не давал ему ни единого шанса — либо задвигал страницы на 10–20 страницы поиска, либо вообще не показывал их. Например, по запросу «вывоз мусора» в Яндексе сайт был в пятерке лидеров, а в Google по этому же запросу его в выдаче не было.

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

Увеличили скорость загрузки сайта и подготовились к Core Web Vitals

Один из этапов технической оптимизации, чек-пунктами которой мы уже делились, когда рассказывали, что делать с дублями на сайте — проверка скорости загрузки страниц. Мы это делаем через PageSpeed Insights.

На этом проекте в красной зоне оказались 4 пункта проверки из 6. Особенно нас волновали значения Largest Contentful Paint (скорость загрузки основного контента) и Time to Interactive (время загрузки для взаимодействия). Это 2 из 3 показателей новых факторов ранжирования Google — Core Web Vitals, которым сайт нашего клиента не соответствовал. С запуском Core Web Vitals он потерял бы еще больше позиций в Google, а со временем — и в Яндексе.

Работу по увеличению скорости сайта мы провели в два этапа:

  1. Поменяли конструктор верстки.
  2. Переехали на новый хостинг.

Поменяли конструктор верстки

Сайт клиента развернут на WordPress. Страницы верстались с помощью конструктора Elementor — он сильно упрощает и ускоряет разработку посадочных страниц, но перегружает их лишними CSS и JS кодами.

Мы предположили, что это одна из основных причин долгой загрузки, и решили отказаться от Elementor в пользу более чистого кода — на сайте нашего клиента нет хитрых интеграций, интерактивных элементов, анимации, поэтому все возможности, которые давал конструктор, все равно не использовались.

Elementor мы заменили на блочный редактор Gutenberg — инструмент самого WordPress. Так как возможности Gutenberg пока ограничены — например, сложно работать с отступами, рамками, радиусами — мы расширили его функциональность двумя плагинами: GenerateBlocks и Gutenberg Blocks — Ultimate Addons for Gutenberg.

На выходе мы получили красивые шустрые страницы и уже на этом этапе существенно улучшили показатели скорости загрузки.

Переехали на новый хостинг

Вес страниц — не единственный показатель, который влияет на скорость загрузки сайта. Большое значение имеет хостинг, а именно:

  1. Насколько близко или далеко сервера находятся от пользователей. Если наша целевая аудитория находится в основном в Питере, а сервера — допустим, в Японии, то сигнал будет в разы дольше идти до базы данных.
  2. Есть ли возможность настроить Memcached. Memcached кеширует данные в оперативной памяти — когда очередной пользователь зайдет на сайт, хостинг не будет генерировать все заново, а отдаст копию, хранящуюся в оперативной памяти.

Сервера старого хостинга находились в Питере, где и была целевая аудитория клиента, но возможности настроить Memcached там не было. Такой вариант нас не устраивал, поэтому мы перенесли сайт на новый хостинг с более широкими возможностями, сервера которого также находились в Питере.

Это решение помогло нам добиться максимально хороших показателей скорости загрузки: Largest Contentful Paint снизили с 3,7 до 0,9 секунды, а Time to Interactive — с 5,7 до 1,4 секунды.

Автоматизировали создание ускоренных AMP-страниц

Сайт нашего клиента фактически имеет 4 версии:

  1. Основную, доступную по домену.
  2. Адаптивную под мобильные устройства.
  3. Ускоренную версию под мобильную выдачу Яндекса — турбо-страницы.
  4. Ускоренную версию под мобильную выдачу Google — AMP-страницы.

Под каждую версию страницы нужно было верстать отдельно — на это не всегда хватало времени специалистов, поэтому от верстки AMP-страниц часто отказывались.

Благодаря переходу на Gutenberg, у нас появилась возможность использовать другой плагин для ускоренных страниц Google, который создает их автоматически.

Мы заменили AMP for WP на AMP — проект с открытым исходным кодом, в развитии которого принимает участие сам Google.

Использовать его ранее мы не могли. Дело в том, что он ограничивает для каждой страницы бюджет на использование CSS — не более 75 килобайт. Если страница укладывается в выделенный бюджет, она рендерится с сохранением основных стилей, но стоит ей выйти за ограничение — она «ломается» и ей становится невозможно пользоваться. Сделать отдельный шаблон в этом плагине нельзя.

Страницы, созданные в Elementor, в этот лимит не укладывались — в среднем они весили от 100 килобайт. Поэтому приходилось работать с AMP for WP, где есть возможность задать уникальную вёрстку для каждой страницы.

С Gutenberg страницы весили почти в два раза меньше — самая «нагруженная» различными элементами страница расходовала не более 70 килобайт.

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

Использовали плагин PWA for WP, чтобы пользователи еще быстрее взаимодействовали с сайтом

В ходе разработки нового сайта мы наткнулись на плагин PWA for WP, который в несколько кликов превращает сайт в прогрессивное веб-приложение (PWA).

Теперь, когда пользователь переходит на сайт со смартфона, внизу появляется баннер с предложением установить приложение. Если он соглашается, на экране создается ярлык, кликая на который пользователь будет попадать на наш сайт и взаимодействовать с ним, даже без доступа к интернету.

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

В результате

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

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

В блоге Кинетики мы рассказываем о своих процессах, делимся опытом, инсайтами и шаблонами внутренних инструментов

0
10 комментариев
Написать комментарий...
Аккаунт заморожен

Комментарий недоступен

Ответить
Развернуть ветку
В А

Облажались)

Ответить
Развернуть ветку
Артем Первухин KINETICA
Автор

Сергей, здравствуйте. Это вы проверили старую версию сайта, на которой скорость была, действительно, не ахти http://joxi.ru/Vm6YRBjfRKwBXr

А сейчас дела обстоят так: http://joxi.ru/EA4YZB0fv0gdOr 

Ответить
Развернуть ветку
Аккаунт заморожен

Комментарий недоступен

Ответить
Развернуть ветку
Nataliya Sicora

Очень интересно узнать, как memcached повлиял на Largest Contentful Paint . Не вижу связи почему-то...

Ответить
Развернуть ветку
Дмитрий Лаговчин

В общем случае кэширование влияет на время время ответа сервера и на Largest Contentful Paint в частности. 
Чем быстрее браузер получает контент с сервера, тем быстрее загрузка страницы и тем лучше показатель LCP.
Как-то так.
А memcached лишь одна из множества технологий кэширования.

Ответить
Развернуть ветку
Алексей Чижов

Полезный материал, благодарю!

Ответить
Развернуть ветку
В А

Я посмотрел исходный код сайта, результаты скорости. Могу сказать, что вы сделали только половину и то установив один плагин поверх другого. Да и тут есть недоработки. По коду вообще ничего не сделано для оптимизации. Потому у вас такой посредственный результат.

Ответить
Развернуть ветку
Дмитрий Лаговчин

Очень порадовал осознанный отказ от elementor в пользу нативного gutenberg. С elementor, с точки зренияния оптимизации, куча проблем.
Они все решаемы, например, webp и css. Но требуют определенных компетенций и телодвижений.
Вам осталось поработать над мобильной версией - там много не решенных метрик по гуглу.
Удачи и быстрых сайтов!

Ответить
Развернуть ветку
Алексей из LOADING.express

Страница про кукис одна из самых быстрых, это правильно.
В целом сайт отзывчивый, но есть разные проблемы с внутренними страницами. И ответ сервера и неоптимальные скрипты со стилями и прочее.

Скриншоты в статье приведены для десктоп, не делайте так никогда, ПК никто не измеряет, всех интересует мобильный замер. Вы таким образом себя сразу подставляете, потому что выгораживаете красную зону на мобильном. Ведь Гугл показывает именно её в первую очередь.

Ответить
Развернуть ветку
Читать все 10 комментариев
null