Как ускорить загрузку интернет-магазина: анализ и внедрение

Привет! Меня зовут Жанна Трофимова и я директор по развитию e-commerce агентства Intensa. В июне на Ecom Expo я рассказывала про важность скорости загрузки интернет-магазинов.

Над скоростью загрузки стоит работать и она важна для пользователей, конверсий и прибыли. Об этом рассказала в первой статье про скорость загрузки интернет-магазинов.

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

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

— DNS. Время, потраченное на отработку запросов к DNS-серверу при загрузке страницы. На этот параметр влияет скорость работы DNS-серверов, обслуживающих запросы к домену сайта. У серверов, с которых нам грузятся сайты, нет доменов, у них есть IP адреса. Когда мы вводим какой-то домен, браузер подключается к DNS-серверу, который сообщает нам, что у такого-то домена такой-то IP-адрес. И дальше подключение к серверу идет именно по IP-адресу. На этот этап загрузки сайта можно влиять, используя как можно меньше разных доменов: например, вынос статики или картинок на поддомены — это дополнительные 50-100 мс времени на подключение к каждому.

— Редиректы. Это время, которое нужно на HTTP-переадресацию при загрузке страницы. Каждый редирект может занимать 200-300 мс, поэтому за этим показателем надо следить. Бывает такое: основной адрес сайта, например, https://www.vasya.ru. Переходим на vasya.ru, и нас встречают 2 редиректа — сначала на https, а потом на www. Лишние редиректы стоит убрать.

— Подключение к серверу. Время, в течение которого браузер ожидал подключения к HTTP-серверу, а также время на установку шифрования. На этот параметр влияют задержки в интернет-каналах между посетителем и сайтом, а также то, насколько сайт загружен входящими запросами. Если наступила «Черная пятница» и ваш проект не был готов к такому наплыву посетителей, то ситуация будет аналогична очереди в «Пятерочке». Только у веб-сервера кнопки с вызовом второго кассира нет, поэтому пользователи уйдут. Чтобы этого избежать, нужно проводить нагрузочное тестирование. Оно дает понимание, сколько пользователей одновременно может выдержать ваш проект.

— Генерация ответа сервера. Время, за которое сервер отправляет браузеру ответ с содержимым страницы. От чего оно зависит? От количества динамических данных, производительности кода на бэкенде, количества и качества запросов к базе данных, от того, как настроено кэширование на сервере. Генерация ответа сервера — это первый показатель, на который нужно смотреть. В 90% случаев мы видим белый экран из-за того, что сервер долго генерирует ответ. Когда ответ сервера мгновенный, 0,5 секунд или меньше, то визуально сайт грузится быстро.

— Загрузка страницы и рендеринг. Время, за которое браузер обрабатывает содержимое страницы после того, как она загрузилась с сервера. Затем браузер отрисовывает ее. На этот параметр влияет размер и сложность страницы, количество и вложенность тегов, размер контента, количество CSS-стилей и JavaScript кода.

В PageSpeed Insight первые четыре параметра определяются показателем «Первая отрисовка контента», а «Рендеринг» — показателем «Время до интерактивности».

Рассмотрим основные метрики загрузки страниц, основываясь на показателях Google — они используются в сервисе PageSpeed и заложены в Core Web Vitals.

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

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

Этот показатель измеряется в миллисекундах. Чтобы его посчитать, надо сложить все периоды загрузки сайта — от первой отрисовки контента до загрузки сайта для взаимодействия, когда скорость выполнения задач превышала 50 мс. В основном на этот показатель влияют неиспользуемый код и неэффективные JavaScript-инструкции.

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

Индекс скорости измеряет, насколько быстро контент отображается визуально во время загрузки страницы.

На показатель влияет количество и качество Javascript кода, время его выполнения, объем и сложность самой верстки, то есть количество DOM-узлов, глубина вложенности, расчет и применение CSS-стилей.

LCP измеряет время до момента, когда на экран выводится самый большой элемент контента в области просмотра.

Сейчас определять первый элемент для загрузки можно с ограничениями. Недавно появился атрибут fetch priority, который позволит картинкам, элементам и блокам указывать приоритет загрузки. Не все браузеры его поддерживают, но мы как минимум можем влиять на текст. Для этого нужно указывать свойство в CSS, чтобы использовались системные шрифты, пока не загружены внешние.

Остановимся на подключении шрифта со стороннего сервера, например, Google Fonts. Для разработчика это сделать просто — одной строкой. Вот происходит с момента загрузки: мы проходим весь цикл от DNS до подключения к серверу Google, получаем CSS-файл, в котором есть информация о том, где находятся файлы шрифтов, и снова проходим весь цикл, но уже с двумя доменами.

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

Это работает так — вы начинаете читать статью, а потом текст смещается из-за загрузки верхнего баннера, или, еще хуже, в момент клика на кнопку, как в этом примере:

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

Этот параметр не учитывается в версии v.10 PageSpeed Insight. Он имел вес в 15% в сравнении с другими параметрами в версиях v.8, v.9.

Это время, за которое страница полностью готова к взаимодействию с пользователем.

Как правило, мы смотрим на одну цифру — оценку PageSpeed, и не понимаем, какой вес имеет каждый показатель. Итоговая оценка — это средневзвешенная оценка каждого показателя с учетом его веса. Какой вес у каждого показателя? Эта информация открыта и выглядит так:

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

1. Сервис PageSpeed. Дает конкретные рекомендации, что делать. Но может быть не до конца понятно, куда в первую очередь приложить усилия — см. следующий пункт.

2. Калькулятор. Он поможет рассчитать, каким должен быть каждый показатель, чтобы получить ожидаемую производительность:

3. Сам инструмент, который лежит в основе сервиса PageSpeed, называется Lighthouse. Помимо сервиса Pagespeed его можно использовать:

а. В консоли любого браузера.

b. В расширении браузера.

c. В командной строке. Для этого надо установить калькулятор на компьютер или сервер.

d. В качестве модуля NodeJS. Можно встроить в процесс непрерывной интеграции и доставки. Как это будет работать: вы настраиваете, чтобы оценка производительности была не ниже 60. При слиянии веток и сборке проекта будет проходить автоматизированный тест, который не позволит сделать деплой.

4. В консоли в стадии беты появился инструмент Perfomance Insights — он позволяет видеть по шагам весь процесс рендеринга страницы. Будет полезен в первую очередь разработчикам для анализа и быстрой отладки.

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

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

Ответить на эти вопросы помогут системы аналитики Яндекс.Метрика и Google Analytics.

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

Полезно обратить внимание на отклонение загрузки страницы от среднего времени в срезе по популярным страницам:

Все эти инструменты можно использовать в такой комбинации:

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

1. Оптимизация изображений.

— Элементы интерфейса и статичные изображения в статьях оптимизировать через Image Compressor.
— Для динамического контента вроде фотографий товаров в интернет-магазине использовать готовые библиотеки, например, flyimg.
— По возможности использовать современный формат Webp.
— Загружать изображения в области экрана (lazy load).

2. Слияние и минификация стилей/скриптов.

— Объединяем в один файл.
— Убираем пробелы, переводы строк.

3. Приоритизация загрузки стилей/скриптов.

— Неважное на первом экране убираем вниз.
— Используем атрибуты async и defer.

4. Кэширование статического контента.

5. Сжатие на сервере (gzip).

6. Переход на HTTP/2 — разница здесь.