Время — деньги: ускорить сайт, не терять клиентов

Тестировали сайт перед запуском — работал быстро. Опубликовали, привлекли посетителей. И вдруг оптимизатор заявил, что Гугл раскритиковал сайт, якобы медленно открывается.

«Надоело ждать»: клиент бросает вялый сайт

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

Опрос Unbounce показал, насколько покупателям важна скорость работы интернет-магазина. 45% склонны отказаться от покупки у медлительного ритейлера, 36% вовсе не вернутся к нему.

Скорость загрузки веб-страниц оценивают Google PageSpeed Insights (PSI), Pingdom, GTmetrix, WebPageTest, Sitespeed. Разберём вопрос на примере PSI.

Сервис анализирует страницу и выдаёт отчёт со списком проблем, рекомендациями по устранению, ожидаемой экономией, то есть сколько секунд удастся выиграть, если проблему устранить. Вердикт выносит в баллах: высокая скорость — 90-100 баллов, средняя — 50-90, низкая — 0-50.

Дело не только в отчётах PSI, порой без баллов видно, что сайт ползёт как черепаха. Другая ситуация: у разработчиков открывается моментально, а у пользователей еле-еле, потому что домашние устройства и сети слабее, чем в офисе программистов.

Чтобы ускорить сайт, нужна оптимизация

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

Если программисты штатные, то кто писал код, тот его и оптимизирует. А если штатные не справились или заняты, либо сайт обслуживается через аутсорсинг, то надо кого-то искать.

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

Сориентируем, что фронтенд- и бэкенд-разработчики будут делать.

Оптимизация кода и контента

Фронтендер не тронет тексты, а сконцентрируется на оформлении. Тяжёлые шрифты заменит на лёгкие; сократит их общее количество, чтобы осталось максимум три.

Видеоролики распределит по разным страницам — чтобы не было такого, что все видео на одной. Видео из верхней части страницы переместит пониже.

Он уделит внимание изображениям: сожмёт баннеры, фоны, иконки, иллюстрации. Сконвертирует PNG в JPEG. Предложит анимацию, слайды и спецэффекты заменить на статику. Сделает ленивую загрузку: сначала показываются изображения в качестве похуже, поскольку загружаются быстро и служат временной заглушкой, пока в фоновом режиме загружаются изображения с высоким разрешением. На страницах из нескольких экранов (с прокруткой по вертикали) изображения будут загружаться по очереди — сначала те, что попали в видимую область.

Фронтендер найдёт и устранит неиспользуемый код JS и СSS. То, что останется, минифицирует (уменьшит размер), объединит. Выявит сторонний код (виджеты, скрипты, фреймы), тормозящий процесс, например: встроенные посты из соцсетей, видео, счётчики. Код, который нельзя удалить, можно хотя бы перенести вниз страницы или реализовать с помощью асинхронной или отложенной загрузки.

Рационализация мобильной версии

Имеет смысл скрыть часть функциональности и украшений, оставив только минимально необходимые.

Гугл подошёл к вопросу с размахом: обучил глубинную нейронную сеть на наборе данных об отказах и конверсиях на смартфонах. Точность предсказания — 90%. Обнаружилось, что вероятность отказа растёт, когда увеличивается время загрузки страницы: для трёх секунд повышается на 32%, для шести — на 106%, а если загрузка длится десять секунд, то вероятность отказа возрастает на 123%.

В упомянутом опросе Unbounce выявили занятный факт: пользователи Android терпеливее приверженцев iOS. Первые готовы потерпеть вплоть до 13 секунд (61% людей), вторые ждут максимум 3 секунды (64%). Так что, если у целевой аудитории iOS, то мобильная версия нуждается в пристальном внимании.

Оптимизация бэкенда

Для ускорения серверной части бэкендер:

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

Список короче, чем у фронтенда, но по факту трудоёмкость этих действий выше.

Настройка железа

Допустим, клиенты в Западной Европе, а сервер — в Америке (там аренда дешевле). Чем дальше пользователь от сервера, тем медленнее для него грузится сайт. Тогда понадобится CDN-провайдер — он будет раздавать контент каждому конкретному пользователю с того сервера, который географически ближе к нему.

Погрешность в расчётах PSI

Сто баллов — недостижимый идеал. Давайте протестируем поисковики: google.com набирает 80 баллов, yandex.ru — 71 балл.

Проверяем один и тот же URL утром, днём и вечером — оценка меняется. Это потому, что пропускная способность сетей непостоянна: например, ночью, пока все спят, сети не перегружены и работают бодрее.

Выставляя баллы, сервис сопоставляет два вида данных: лабораторные и полевые. Лабораторные замеры получают путём имитации загрузки. Полевые — это статистика настоящих пользователей, показатели берутся из отчётов браузера Chrome.

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

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