Как сократить время загрузки мобильной версии в 2 раза

Работал над проектом для дизайн-агентства, где основной контент —  графический. Вариант уменьшения скорости загрузки сайта за счет сжатия изображений в ущерб их качеству вообще не рассматривался.

Страницы значить могут быть от 2 до 8 мегабайт, а грузиться они должны одинаково быстро, особенно, на телефонах... Вот незадача.

Как решали задачу и как удалось сократить скорость загрузки сайта на мобильных устройствах в 2 раза, а вес страницы в 3, читайте далее.

Скорость загрузки страниц сайта важный фактор, как в SEO, так и в конверсии.
В этом материале рассмотрим:

• Проблему;
• Варианты решения;
• Опыт применения на реальном проекте;
• Недостатки.

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

Если высокую скорость загрузки сайта добиться на ПК не составляет особых проблем, то с телефонами дело обстоит иначе. Согласно последнему отчету Google, доля мобильных пользователей достигла отметки в 63%!

Основная проблема не так в телефоне, как в мобильном интернете, который работает не всегда хорошо и стабильно.

Для более быстрой загрузки сайта на мобильных, нужно максимально уменьшить вес страницы сайта, а какой тип данных имеет самый большой объем?
Правильно — изображения! О них и пойдет речь.

В чем проблема?

Уменьшение качества изображений до среднего — возможно. Но есть ниши, где весь упор идет на графический контент и он должен быть, как минимум, в максимально допустимом разрешении.

Если на стабильном интернет-соединении картинка весом 1.1 Мб и размером 1200х1200px не проблема, то при использовании мобильного интернета, местами, может быть полной катастрофой и скорость загрузки страницы достигнет 20-30 секунд.

Как эту проблему решают?

Все просто: для десктопа загружать полноразмерные изображения, допустим 1200х1200px, для планшетов 800x800px, а для телефонов 480х480px.
Существует несколько вариантов это сделать:

На стороне сервера (PHP):

С помощью сервера отдавать для разных устройств, разные файлы.
Использование этого метода встречал реже всего, ведь он обладает рядом недостатков, создает лишнюю нагрузку на сервер и на больших проектах внедрение этого метода может быть довольно трудоемким процессом. Для корректной работы нужно выполнить скрипт (JS) на стороне клиента. Проще использовать следующий вариант.

На стороне клиента (JS):

С помощью javascript указывать пути к файлам в зависимости от ширины экрана. Ранее этот вариант часто использовался для оптимизации сайта под retina-дисплеи.

На стороне клиента (CSS):

При всей простоте использования CSS, есть один огромный недостаток:
Сначала загружаются все изображения 1200х1200 и 480х480px, а потом отображаются подходящие. Лучше совсем такую оптимизацию не использовать — только навредит.

На стороне клиента (HTML):

В спецификации HTML5 eсть замечательный тег <picture>, о нем расскажу подробнее.

Адаптивные изображения и тег <picture>

Тут все просто, используя эту конструкцию:

<picture>
    <source media="(max-width: 480px)" srcset="image-480.jpg">
    <img src="image-1200.jpg">
</picture>

Вот и все:) никакой лишней нагрузки на сервер и скриптов!

Кратко разберем, что все это значит простым языком:

• source — содержит условия;
• media — отображать данный файл при ширине экрана ДО 480px;
• srcset — путь к отображаемому файлу;
• img — отображать при любых других условиях.

Применяем на реальном проекте

После всех стандартных оптимизаций, мы получаем такие цифры для ПК:

• Количество запросов 26;
• Вес страницы 4.5 Мб;
• Скорость загрузки страницы 1.54 сек.

Вроде бы и так замечательно, но это не придел и можно сделать в разы лучше:)

4.5 мб при среднем качестве мобильного интернета будет многовато для страницы.

Используя, выше описанную конструкцию, мы получаем такие результаты для мобильных устройств:

• Количество запросов 26;
• Вес страницы 1.6 Мб;
• Скорость загрузки страницы 761 мс.

Уменьшение скорости загрузки для мобильных в 2 раза и вес страницы сократился почти в 3 раза!

Для телефонов изображения отдаются в меньших размерах.

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

Так ли хорош этот способ?

Да! По крайней мере, это лучшее, что есть в данный момент из возможных вариантов.

Недостатки:

Недостатки? Конечно! Вот наивно полагать, что их нет:)
В разработке сайтов всегда идет баланс технологий и решений для определенных задач.

К счастью, они несущественные и решение почти идеально, дело больше в подготовке файлов для этого решения.

- В 2 раза больше файлов, а если делать оптимизацию под планшеты, то в 3. Прекрасная новость в том, что на большинстве нормальных CMS, есть модуль ресайза изображений и он будет нарезать их самостоятельно. Допустим, вы загружаете фото 1200x1200, а их масштабирует на стороне сервера на 800 и 480px. Для лендинга это можно сделать даже руками, хотя есть достаточно софта, который избавит от этой рутины.

- Нагрузка на сервер. Снова же, это последствия не этого решения, а автоматизации. Нагрузка производится только 1 раз, а потом изображения хранятся в кеше.
Можно самостоятельно, в графическом редакторе, их уменьшать. Да только кому нужно тратить 1-10 часов на то, что модуль может сделать автоматически за пару минут.

- Поддержка браузерами. Старые браузеры до IE 11 и Edge 12 его не поддерживают, т.е. почти все браузеры выпущенные до 2015-го года. Неудивительно, ведь скоро 2020-й и с последнего релиза прошло почти 5 лет, они в меньшинстве. Тег <picture> поддерживает 92% браузеров на момент 2019-го.

Итог

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

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

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