20 лучших заблуждений про ускорение сайта

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

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

В реальности все не так радужно. Мобильные пользователи это уже более 50% аудитории в России. Несмотря на победные рекламные ролики про самый быстрый интернет, мобильный доступ все еще очень медленный (как полоса, так и задержки, что существенно для скорости сайтов). По данным Одноклассников (доклад А. Тоболя на HighLoad ++) типичные скорости мобильного интернета в России такие: полоса 1,1 Мбит, потеря пакетов 0.1%, задержка 300 мс.

Да и корпоративный интернет в России зачастую настолько дорогой, что это естественно ограничивает скорость доступа в офисе. Пожалуй, лучше всего себя чувствуют пользователи домашнего интернета, где можно за условные 500 рублей получить 100 Мбит канал. Но далеко не все покупатели ждут момента, когда придут домой к компьютеру с хорошим каналом. Сейчас принято многие вопросы решать «на лету», с телефона.

Для оценки скорости своего сайта, зайдите в Яндекс.Метрику или Google Analytics – там можно посмотреть скорость загрузки у настоящих пользователей вашего сайта в реальной жизни. Именно эти цифры стоит улучшать.

Начнем с того, что единственный профессиональный измеритель скорости сайта – WebPageTest Патрика Минана. Его до недавнего времени использовали и в Google. Патрик создал не только совершенно уникальный инструмент тестирования, но и закрепил понятие основных метрик скорости, которые позже стали использовать его последователи, в частности Speed Index, который перекочевал и в GPSI (Google PageSpeed Insights).

Возможно не стоит беспокоиться, если у вас проблема только в баллах этого вожделенного многими рейтинга. Популярное заблуждение, что баллы GPSI влияют на положение сайта в выдаче поисковиков и выигрывают у конкурентов аукционы в Google Ads. Просто почитайте справку Google Ads, там четко написано, что скорость сайта определяется данными RUM (Real User Monitoring). То есть реальной скоростью загрузки страниц сайта у пользователя. Поэтому нужно улучшать реальную скорость, а не баллы рейтинга.

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

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

Этот модуль официально не поддерживается разработчиками nginx. Правильно настроить его могут лишь некоторые, а точнее никто. В случае неправильной настройки сайт ложится. Сам Google пытался запустить на основе этого продукта Saas Google Page Speed Service – он не вышел из беты. Короче говоря, сырой продукт, на который махнул рукой сам автор. Нужен ли вам такой подарок – решайте сами. Успешных кейсов использования модуля нами не обнаружено.

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

Lazy-loading – всего лишь один из приемов, позволяющих повысить баллы оценки скорости в некоторых рейтингах скорости. Реального ускорения от отложенной загрузки ресурсов нет. Этот трюк может быть полезен в отдельных случаях, но это ни разу ни серебряная пуля.

Действительно, нетрудно найти в поиске подрядчика, который пообещает решить все ваши проблемы за символическую сумму. Ведь все мы хотим верить в сказку. Поэтому клиентов у этих «специалистов» хватает. Если говорить серьезно, то что можно сделать за 1-2 часа работы над проектом? Минимум изменений, даже если исполнитель не сливается и пытается добросовестно отработать заплаченные ему копейки. Как говорится, вы делаете вид, что платите, а он делает вид, что работает. Тут наилучший сценарий – получить частично оптимизированный контент. Много к нам обращаются после таких «оптимизаторов» – следы ускорения иногда даже видны, но далеко не всегда.

Здесь ситуация из предыдущего пункта. Рынок ускорения сайтов не сформирован, многие компании и просто «специалисты» заявляют возможность выполнить ускорение, но по факту услугу не предоставляют на должном уровне. Необходимой экспертностью в ускорении сайтов в России обладают буквально единицы. К сожалению, сейчас вместо нормальных программистов сплошные котики (да, это небольшое преувеличение, чтобы обратить внимание на колоссальную проблему). Их надо любить, кормить и ничего не требовать взамен. Они порождают ужасный программный код, и все делают вид что он хорош, надо только хостинг помощнее! Часто именно авторы тормозного кода являются лютыми противниками привлечения специалистов со стороны: «сами не смогли нормально сделать и другим не дадим»!

Проблема ожидания и реальности. Основана на том, что заказчик скорее всего не знает, как правильно измерить результат ускорения. Второй аспект связан с тем, какой вклад в успех работы коммерческого сайта вносит каждый процент ускорения сайта. Тут многие не понимают реальную ценность даже 10% ускорения. Тем временем, существует много исследований по этому поводу. Почитайте хотя бы книгу Тамми Эвертс «Время – деньги». При этом ускорение в 2-3 раза без изменения функциональности – очень хороший результат. Если нужно больше, стоит готовиться к более глубокой переработке сайта (что-то убрать, что-то поменять).

Почти каждый второй заказчик уверенно диагностирует на своем сайте «тормозящую» СУБД. Без изучения нагрузки на сервер. Л – логика. Пустой сайт не тормозил. Наполненный товарами магазин встает на колени при небольшом (несколько тысяч) числе товарных позиций. Зачастую предположение оказывается ошибочным. Однако структуры БД, которые приходится встречать в работе не перестают удивлять: отсутствие нормализации, неправильные типы данных, индексы раскинутые рандомно по таблицам…Хотя основные проблемы можно обнаружить в SQL-запросах. Там творится адовый ад. Судя по коду, единственный критерий качества написания запросов – чтобы он вообще работал.

К сожалению, не так все просто в этом деле ускорения сайтов… Оптимизация изображений – важный этап ускорения сайта, но сам по себе не спасёт типичный тормозной сайт. Только в том редчайшем случае, когда все на сайте оптимизировано, кроме картинок. Это практически фантастика. Типичный случай – проект, хромающий на обе ноги, требующий доработок по многим направлениям.

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

В действительности, MySQL и ее форки любят максимальную производительность на одно ядро процессора, что свойственно скорее десктопным решениям. То же относится и к программному коду, который исполняется в одном потоке. Серверные процессоры сегодня соревнуются в количестве ядер (потоков), а тактовая частота ядра у них второстепенна. Ну а любители облаков часто вообще не в курсе за что платят (на каком железе все работает). Это приводит к интересным результатам: апгрейд хостинга может даже замедлить ваш сайт, например, когда оперативной памяти хватало и ранее, а процессор на новом сервере какой-нибудь Xeon Silver, Gold или Platinum c «50 ядрами» с частотой чуть за 2 Ггц вместо «старого медленного» 4-ядерного на 4+ Ггц.

Данное утверждение справедливо, когда аудитория вашего сайта та самая Европа или США. Хостинг должен быть географически максимально приближен к посетителю сайта. Тогда задержки при передаче данных будут минимальны и вы, при прочих равных, добьетесь максимальной производительности. Но грустно и смешно, когда сайты с ЦА Москва и область кидают на американский хостинг. Мы любим грабли, мы по ним ходим регулярно!

В нашей практике, к нам приходят в работу сайты после топовых SEO-агенcтв (разбор одного такого случая есть у нас на youtube-канале). Деньги всем нужны, продвиженцы постоянно расширяют набор услуг, тем более что основная последнее время, мягко говоря, сильно буксует. Это понятно. Но мы за экспертность. Каждый должен заниматься своим делом, если не хочет показаться дилетантом. Беда бедовая, когда «пироги начнет печи сапожник….»

Тем более, что «ускорять» они будут число баллов рейтинга GPSI, а не реальное ускорение сайта в секундах у конечного пользователя, а это не одно и то же.

Слухи о реактивных сайтах на Bitrix сильно преувеличены маркетологами, впрочем как и на других CMS, которые вкрутили в систему кеш плюс непонятный CDN и преподносят это как спасение. Однако численность адептов секты Битрикса весьма велика в России и она успешно поддерживает миф про «как пуля резкий» CMS. Ну а в жизни – каждый второй клиент у нас с сайтом на Битрикс...

Парадокс в том, что простой контент отдается веб-сервером без особых проблем и так, без кеша. А вот динамический контент (ИМ, ЛК, фильтры, поиск и т. д.), как правило, дает максимальное время генерации страниц. Но его закешировать нельзя, надо бороться с долгой генерацией страниц на сервере, оптимизировать код.

Тут можно помочь настройками, когда у вас код сайта хорошего качества, а админ по каким-то причинам не справился с управлением сервером. Тогда действительно, исправив огрехи настройки, можно поднять производительность. Такой случай бывает один на миллион. Но нет никаких волшебных настроек, которые ускоряют плохой код в разы. Надо оптимизировать SQL-запросы, профилировать код сайта, устранять другие узкие места (bottle necks), ну и конечно не забываем про клиентскую оптимизацию.

Ну да, решили. Проблему как бесплатно взять контент вашего сайта и показать свою рекламу. Схема гениальна. В чем ваша выгода как владельца сайта? Аргументы представителей поисковых машин звучат неубедительно. Они заработают на вас денег, а вам за это ничего не будет. Успешный успех!