Ускорение сайта mlpark.com

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

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

Задача

Заказчиком поставлена цель ускорить сайт http://mlpark.com/. Со слов клиента, сайт разработан фрилансером и, по мнению автора, ускорить сайт без потери «красоты» невозможно.

Диагностика проблемы

Проводим экспресс-анализ сайта с помощью WebPageTest и Google PageSpeed Insights. Параллельно смотрим на сайт в браузере.

Автоматизированные инструменты (WPT и GPSI) дают довольно низкие оценки (типичный набор проблем для WordPress-сайтов). При этом видно, что предпринимались робкие попытки ускорения, но проблемы всё равно остались. Хорошо, с этим понятно, что делать.

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

Первое предположение – низкая скорость генерации HTML-кода, то есть недостаточные ресурсы веб-сервера (хостинга). Открываем закладку Network, ставим фильтр на документы (Doc) Средств разработчика в Chrome и проверяем. Ходим по страницам – запросов нет. Оказывается, сайт является Single Page Applicaton (SPA) и контент меняется посредством AJAX. Смотрим закладку XHR и видим загрузку контента страниц. Да, не быстро: до 500 мс на запрос. Но задержки между переходами по страницам составляют примерно 5-6 секунд! Откуда берётся такое время? Скорее всего, в этом виноват тяжёлый код JavaScript.

Проверяем: запускаем запись событий в Timeline и ходим по страницам. В сводной диаграмме видно, что большую часть времени браузер ничего не делает. Интересно, что же это? Очевидно, что проблема в клиентской части, но что это конкретно – неизвестно.

Процесс оптимизации

Начинаем работу с главного: найти причину медленных переходов между страницами сайта. Проблема повторяется на быстром соединении, с прогретым кешем, значит не зависит от размера ресурсов. Изучение Timeline показало, что тяжелого JS-кода, который долго выполняется, нет. Поэтому ищем механизм переключения между страницами.

Нужный нам код находится в script.js, который состоит из большого количества вызовов jQuery API. Среди обширных обработчиков замечаем, что многие из них обёрнуты в функцию setTimeout,которая выполняет код с задержкой. Эта задержка задаётся в милисекундах, а мы видим в коде 20, 30, 500, 1000, 2000 и даже 4000! Значит, код тормозит сам себя на 4 секунды!

Решение: сокращаем все задержки в 10 раз и смотрим на результат. Главная проблема решена: переход между страницами в рамках 1 секунды и быстрее.

Для завершённости эффекта оптимизируем стандартные места для WordPress: обновляем версии JS-библиотек, объединяем и минифицируем файлы, оптимизируем шрифты и картинки.

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

Запускаем оптимизированную версию, завершаем проект (начинается срок 30-дневной гарантии).

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

Результаты

Основным параметром для нас стало время перехода между страницами, которое составляло 5-6 секунд. В результате переход занимает менее одной секунды и практически не заметен для пользователя (как и должно быть в SPA). Время начала рендеринга (появления реального контента) снизилось с 7 секунд до 2 при использовании соединения 5 Мбит/сек.

Попутно была решена проблема некорректного подключения шрифта (без кириллицы). Кроме того, теперь сайт не зависит от работы внешних сервисов (например, Google Fonts).

Сайтом приятно пользоваться и не хочется уйти на этапе рассматривания индикатора загрузки (progress bar). По статистике, большинство пользователей покидают сайт при загрузке более 3 секунд до первой отрисовки страницы, поэтому шансы на конверсию для сайта резко возросли.

Перейти на сайт