Ускоряем работу сайта на этапе разработки и обгоняем конкурентов в поиске
Приветствую!
В этой статье хочется обсудить такой важный параметр, как оптимизация скорости работы сайта на этапе разработки.
Поисковые системы потихоньку начинают давать всё больше значимости тому, как быстро работает сайт на смартфонах и ПК у пользователей.
В основном идею качества и здоровья сайта продвигает в массы Google.
Web Vitals — это именно его инициатива. Подробно в WV я углубляться не буду, есть куча статей на эту тему, кому интересно позалипать на технические термины — добро пожаловать на web.dev.
Яндекс по-прежнему отдаёт наибольший приоритет поведению пользователей, и именно оно зачастую решает нахождения сайта в топе результатов поиска.
Хотя в последнее время в Яндекс.Вебмастере появился блок с информацией о скорости сайта.
Как его вычисляет Яндекс, участвует ли это значение в формуле расчета ИКСа, и почему там именно 5 пунктов, никто пока не в курсе.
Факт остаётся фактом.
Если у вашего сайта и сайта вашего конкурента примерно одинаковая внутренняя оптимизация, примерно одинаковые закупки внешнего трафика, брендового трафика, ссылочный профиль, номенклатура, количество страниц, поведение, и множество других параметров, но у конкурента сайт работает быстрее, чем ваш, то конкурент будет ранжироваться в результатах поиска выше.
Готовь сани летом
На этапе разработки сайта мало кто вообще о чём-то задумывается, кроме того, как побыстрее сдать сайт заказчику и получить акты выполненных работ.
На моём опыте распределение примерно следующее: 1 из 50 заказчиков думает о скорости работы будущего сайта и полной внутренней оптимизации до запуска проекта и, как следствие, ставит нужные задачи программистам.
Даже не то что думает, а вообще подозревает, что такой параметр как скорость может играть какую-то роль.
Ну, как говорится, успех не для всех. Так что ловите несложную инструкцию и как можно скорее внедряйте это в свой сайт.
Ускоряем работу сайта самостоятельно
- Включаем сжатие статических объектов.
Уверен, что малый процент читателей запускает или будет запускать свой сайт на выделенном сервере с самописной CMS, админкой и логикой.
Это далеко не дешёвое занятие, требующее определенных технических знаний, поэтому большинство разворачивает сайты на виртуальном сервере с платной или бесплатной CMS.
Обычно в ISP менеджере хостинг провайдера есть специальный раздел с настройками домена, где можно включить следующие опции.
Это самый простой и быстрый вариант требующий 0 знаний в области разработки. Кстати, рекомендую ставить уровень сжатия 6, чтобы сильно не нагружать CPU вашего сервера.
Включаем сжатие через файл. htaccess.
Тут возможно два варианта, если сервер поддерживает mod_deflate, то код будет такой:
А если не поддерживает, то будем использовать mod_gzip:
Чтобы проверить работает ли gzip-сжатие на вашем сайте, зайдите сюда www.giftofspeed.com/gzip-test/ и запустите тест.
- Устранение CSS и JS, блокирующих отрисовку.
Многие думают, что залог зелёной зоны в PageSpeed Insights — это просто вес страницы. Типа, весит страница на сайте 50 мегабайт — плохо, весит 50 байт — жизнь удалась.
На самом деле всё не так. Общий вес документа напрямую не влияет на 100 баллов в тесте скорости. Вопрос в том, как быстро для пользователя будет отображен первый экран контента.
Поисковые системы хотят, чтобы пользователь как можно быстрее увидел контент сайта. Даже если там будут картинки по 20 мегабайт, это не играет никакой роли.
Так вот, некоторые CSS и JS могут серьёзно растягивать время до отображения контента страницы.
Тут возможны два варианта, в общем-то оба рабочие.
Оптимизации CSS и JS вручную на этапе разработки.
Все стили сайта размещаем сразу в теге Head без подключения через статические файлы.
Не используем внешние шрифты, типа Google Fonts. Всё это тормозит скорость отрисовки контента у конечных пользователей.
Если без каких-то внешних скриптов ваш сайт работать вообще не может, то все скрипты грузим асинхронно, пример:
Исключение: некоторые скрипты счетчиков аналитики, пиксели социальных сетей, GTM, скрипты внешних товарных каталогов, и прочие. При их изменении или доработке могут быть серьёзные искажения в аналитике и работе сайта в целом.
Все скрипты, которые работают корректно, объединяем и помещаем как можно ниже в коде сайта.
Подумайте, какие стили и скрипты можно загрузить позже, и реализуйте это.
Тут нам понадобятся атрибуты defer, async, тег script, и несколько часов работы.
Ускорить производительность сайта можно с помощью тега preload. Этот тег указывает, какие ресурсы понадобятся страницам сайта в ближайшие несколько секунд, и загружает их заранее, пример:
Не запихивайте в предзагрузку всё подряд, это только замедлит скорость работы сайта. Подумайте, какие скрипты и стили нужны пользователю, чтобы как можно быстрее увидеть первый экран страницы сайта.
Приоритеты загрузки в Google Chrome можете посмотреть в этой таблице docs.google.com/document/d/1bCDuq9H1ih9iNjgzyAL0gpwNFiEP4TZS-YLRp_RuMlc/
Для фоновой загрузки файлов с низким приоритетом, которые могут потребоваться на других страницах сайта, используйте тег prefetch, пример:
Если нужно заранее установить соединение с внешним сервисом, например Google Fonts, то используйте тег preconnect, пример:
Не нужно злоупотреблять этим тегом, браузер пользователя может его проигнорировать, если уже установлено много соединений или недостаточно памяти на устройстве. Оптимально использовать предварительное подключение до 6 внешних ресурсов. Чем меньше, тем лучше.
Для ускорения резолвинга DNS и экономии до 120 мс используйте тег dns-prefetch, пример:
Этот тег ускоряет начальное соединение с внешним сайтом и работает с старыми браузерами.
Обязательно добавляйте параметр display swap, даже если шрифты загружаются из внешнего источника, пример:
Лучше всего скачать шрифты и подгружать их с своего сервера, всё это увеличивает скорость работы вашего сайта.
- Минифицируйте CSS, JS и HTML.
Если вы заказчик, то тут многое зависит от прямоты рук разработчиков, их уровня пофигизма, и конкретики в техническом задании.
Вообще, неплохо сначала выяснить, сколько кода и в каких файлах вообще не используется, но кешируется и загружается у пользователей, тормозя процесс отрисовки первого экрана.
Проверить это очень просто. Нам понадобится браузер Google Chrome.
Давайте проверим, какой объём кода не используется на сайте vc.ru, но его загружает ваш браузер.
Кликаем правой кнопкой мыши на произвольное место страницы, нажимаем «Посмотреть код». Далее выбираем вкладку «Console», чуть ниже около слова «Console» видим три точки столбиком и нажимаем на них, в выпадающем меню нажимаем «Coverage».
В этой таблице нас интересуют файлы, у которых значение «Unused bytes» (Неиспользованные байты) просто зашкаливающее.
У некоторых файлов «Unused bytes» = 100%.
Берём конкретные файлы и разбираемся, как их можно урезать и сократить или вообще отказаться от их использования, возможно ли это, какие последствия, что может поломаться.
Более подробно про инструмент Coverage можно прочитать тут developers.google.com/web/tools/chrome-devtools/coverage
Минифицируем CSS и JS вручную.
Заходим сюда minifier.org, загружаем CSS или JS файлы, жмём кнопку, всё готово.
Обязательно проверяйте работоспособность нового кода с отключенным кешированием на ПК и смартфоне, а лучше всего на копии сайта на служебном домене.
Минифицируем и объединяем CSS и JS через плагины.
Есть множество плагинов для популярных CMS и их вполне можно использовать. Работают сносно. Мусор в коде особо не генерируют и выполняют свои задачи.
Если плагин рушит работу всего сайта, то просто попробуйте другой. Такое бывает.
Годные плагины для Wordpress: WP Super Cache, W3 Total Cache, WP Fastest Cache, Hummingbird, LiteSpeed Cache, WP Rocket, Autoptimize.
Настройки для Битрикс: большинству будет достаточно штатного функционала из коробки, включите кеширование, композитный сайт, и в настройках главного модуля отметьте нужные пункты.
- Подключите CDN.
CDN — content delivery network или сеть доставки контента. Если простыми словами, то это сетка серверов по всему миру с специальным ПО, задача которого отдавать статический контент вашего сайта с самого ближайшего к пользователю сервера.
Пример: хостинг вашего сайта физически расположен в Москве, но сайтом пользуется множество пользователей, от Калининграда до Владивостока.
Соответственно, при подключенном провайдере CDN сайт будет молниеносно загружаться у пользователей из Питера с сервера в Питере, а у пользователей из Новосибирска с сервера в Новосибирске, а не с Москвы.
При отключенном CDN контент сайта всегда будет загружаться с сервера в Москве, что замедляет скорость загрузки у пользователей, которые живут за МКАДом.
Для зарубежных проектов лучше всего использовать Amazon CloudFront, Cloud CDN от Google, Windows Azure CDN и конечно же CloudFlare. Это одни из топовых поставщиков CDN.
Для проектов, которые ориентированы только на рунет, лучше всего использовать локальных поставщиков CDN, например G Core Labs, CDN Video, Akamai, Selectel, Leaseweb.
Немного дополнительных плюсов CDN.
- Устойчивость к DDoS за счет распределённой архитектуры и высокой мощности серверов.
- Уменьшение нагрузки на сервер хостинг-провайдера, на котором расположен сайт.
- При кратковременной недоступности сервера хостинг-провайдера сайт будет доступен, так как копия страниц сайта расположена на CDN серверах.
- Значительное улучшение SEO-метрик сайта в отдалённых регионах.
Стоимость CDN сервисов обычно зависит от объёмов трафика. Чем больше трафика собирает сайт, тем дороже будет стоить CDN.
Фиксированные тарифы как правило отсутствуют. Более подробный список провайдеров под свои задачи можно найти тут cdnfinder.com.
- Настройте Lazy loading и сожмите все изображения.
Lazy loading — это асинхронная загрузка контента до того момента, когда это необходимо.
Пример: при заходе пользователя на сайт для его загрузится только та часть контента, которую он видит. Если пользователь начинает прокручивать страницу вниз, то начинает подгружаться остальной контент сайта. В этом случае ускоряется отдача первого контента пользователю и повышается скорость загрузки сайта. Не нужно ждать, пока весь документ будет загружен.
В некоторых CMS Lazy loading настроен по умолчанию, например в последнем обновлении Wordpress. Можно настроить плагинами, проблем не возникает. Если CMS самописная — всё индивидуально, нужно ставить задачу разработчику.
Используйте современный формат изображений webp.
Это формат сжатия изображений от Google. Разработан в 2010 году. Дело в том, что изображения в формате webp весят в несколько раз меньше, чем изображения других форматов. Иногда в несколько сотен раз меньше.
Всё это влияет на загрузку сайта и скорость работы. Этот формат поддерживается браузерами Google Chrome с версии 9, Opera с версии 11.10, Firefox с версии 65, Microsoft Edge.
Смартфоны на Android спокойно читают формат webp с версии 4.0. Поддержка webp в Safari на Mac и iOS будет доступна с версии 14, выход которой намечен на сентябрь 2020 года.
На данный момент поддержки webp в Safari нет и пользователям этих устройств нужно отдавать jpg или png изображения, а всем остальным webp.
Чтобы подружить большинство популярных браузеров с форматом webp нужно подключать библиотеки libwebpjs/libwebpas на JS и AS соответственно.
Внедрив webp в свой сайт на этапе разработки вы получите большое конкурентное преимущество. В рунете почти никто кроме гигантов этим не заморачивается.
Если вы категорически не можете использовать формат webp в своём проекте, то максимально сожмите изображения без изменения формата.
Делать это можно своим софтом, готовыми плагинами, или вообще вручную.
Годные плагины как правило стоят денег, да ещё и по подписке. Для малых объемов будет достаточно этого сервиса compressor.io.
- Настройте длительное время кеширования.
mod_expires — специальный модуль сервера Apache, позволяющий задать время, на которое будут кешироваться статические ресурсы в браузере пользователя.
Кэшируем всё, CSS, JS, шрифты, изображения, пример кода для файла. htaccess:
Кешировать счетчики аналитики и пиксели соц. сетей не получится.
Некоторые умельцы научились это делать с Google Analytcis на стороне пользователей, но я вам этого не рекомендую.
access plus 1 year — означает, что элемент будет кеширован на стороне пользователя сроком на 1 год после первого посещения сайта. При повторном посещении сайт откроется мгновенно, так как большинство ресурсов уже будет в кеше браузера пользователя.
- Заблокируйте доступ к сайту для роботов и парсеров.
Существует огромное количество сервисов для SEO/PPC аналитики и не только.
Например, Semrush, Ahrefs, web.archive.org, pr-cy.ru, WebSpy и множество других.
Они парсят и агрегируют огромное количество сайтов и ежедневно создают нагрузку на ваш сайт. Это большая проблема в интернет-магазинах на сотни тысяч и миллионы SKU, может возникать повышенная нагрузка на БД.
Для отсечения самых популярных ботов на уровне сервера можно настроить специальные правила.
mod_setenvif — модуль сервера Apache, с помощью которого мы можем настроить полный запрет доступа к сайту для любых роботов и парсеров.
Пример кода для. htaccess:
Что будет, если робот "AhrefsBot" попробует зайти на сайт? Он получит в ответ ошибку 403 — доступ запрещён, и не сможет загрузить никакой контент сайта.
Важная особенность. При блокировке доступа роботам от популярных сервисов вы и ваши конкуренты не смогут получить никакой аналитики по вашему сайту, у систем просто не будет никаких данных.
Если ваша работа завязана на аналитику в Semrush, Ahrefs, Similarweb, и прочих сервисах, то настройку подобной блокировки нужно делать внимательно.
Чрезмерная нагрузка бывает редко. Обычно такие жесткие блокировки используют опытные веб-мастера, которые хотят скрыть сетки своих сайтов и не хотят палить рабочие фишки и актуальные схемы в SEO.
Вместо заключения
Даже если вы внедрите хоть что-нибудь из текста выше — ваш сайт начнёт работать быстрее.
Думайте о скорости работы сайта на этапе разработки. Это влияет на SEO и конверсии, а в конечном итоге на деньги.
Полезные сервисы и плагины для оценки скорости работы сайта:
- developers.google.com/speed/pagespeed/insights/
- gtmetrix.com
- googlechrome.github.io/lighthouse/viewer/
- web.dev/measure/
- chrome.google.com/webstore/detail/web-vitals/ahfhijdlegdabablpippeagghigmibma
Часть 2 тут - https://vc.ru/dev/158627-uskoryaem-rabotu-sayta-na-etape-razrabotki-i-obgonyaem-konkurentov-v-poiske-chast-2
Перед минификацией CSS ещё можно прогнать его через Critical, чтобы разделить файл на две части: то, что нужно для отображения верхней части сайта обязательно, и всё остальное. Первый файл кинуть в HEAD, а второй уже в самом низу.
Спасибо, годная статья. Однозначно в закладки.
😢 когда у тебя сайт на tilda
Конструктор для лендинга ок. Для полноценного сайта не годится, какой бы там функционал не был. Это мое мнение.
Обидно, когда гугловская рекапча 3 не даёт пройти гугловский тест Core web vitals в гугловской PageSpeed.
Статья прикольная, жаль никто никогда не рассказывает как на практике решить проблему внешних скриптов, как правильно сделать criticalpath и как грамотно настраивать wp super cache.