Оптимизируете сайт? Осторожно с ленивой загрузкой!

Несколько недель назад меня спросили, может ли Accesto помочь оптимизировать популярный интернет-магазин, продающий натуральную косметику. Конечно, мы можем! подумал я. Это то, чем мы зарабатываем на жизнь, мы улучшаем существующие веб-приложения, такие как SaaS, торговые площадки или сайты электронной коммерции. Поэтому я думал, что это будет такая же оптимизация, как и все остальные. Но это было не так.

Быстрые победы для скорости работы сайта

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

Высочайшей производительности, которая будет удерживать экспоненциальный рост пользователей, невозможно достичь в одночасье. Но если ваш сайт замедляется, а вы еще не приложили много усилий для его оптимизации, есть большая вероятность, что это можно исправить за вполне приемлемое время. Как в одной из наших недавних историй, где нам удалось сократить время загрузки сайта на 97% всего за 4 часа работы.

Первые результаты PageSpeed для интернет-магазина, продающего натуральную косметику

Случай с интернет-магазином натуральной косметики выглядел примерно так же. Владелец магазина прислал мне письмо в пятницу утром с отчетом Google PageSpeed Insights. В нем оценивалась общая производительность сайта на 61/100 для настольных компьютеров и 42/100 для мобильных устройств. Не трагедия, но действительно много возможностей для улучшения. Отлично! Мы применим несколько быстрых настроек, которые ускорят работу сайта, и у меня будут хорошие новости для клиента еще до выходных!

Давайте начнем с аудита сайта и проверим Core Web Vitals.

Мы уже знаем общую оценку этого сайта — нашу отправную точку для оптимизации. Этот показатель складывается из 6 показателей, оцениваемых PageSpeed, которые для данного сайта выглядят следующим образом:

](https://dev-to-uploads.s3.amazonaws.com/uploads/articles/50jualml4g4hqdi74z7f.jpeg)

Быстрый взгляд на метрики и мы видим, что 4 из 6 метрик выглядят хорошо (Web Vitals), но оставшиеся две: Speed Index и Largest Contentful Paint (LCP) кажутся слишком высокими. Понимание этих метрик помогает решить, с чего мы начнем оптимизацию, насколько мы должны улучшить показатели и сможем ли мы найти низко висящие плоды. Каждая из этих метрик имеет свой вес (важность). Чтобы узнать, как именно они влияют на общую оценку, вы можете воспользоваться калькулятором оценки.

Хотя PageSpeed оценил и SI, и LCP как плохие, LCP имеет больший вес (25%), поэтому его улучшение окажет наибольшее влияние на общую оценку. LCP — это одна из 3 важных метрик, введенных Google под названием Core Web Vitals. Хорошо, но что именно представляет собой этот LCP? Вкратце — это время, в течение которого окрашивается самая большая видимая часть содержимого сайта. Этим контентом может быть изображение, большой блок текста или любой другой элемент, занимающий значительную часть экрана при загрузке сайта. И чем быстрее этот элемент будет показан пользователю, тем лучше.

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

Мы использовали инструмент Lighthouse, встроенный в браузер Chrome, чтобы составить профиль сайта. Мы искали любые проблемы с производительностью, но результаты аудита оказались… на удивление хорошими! Сайт работал совсем не так уж плохо! Время отклика сервера было вполне приличным, изображения подавались в современном формате и с правильными размерами. Все активы сайта были должным образом оптимизированы и обслуживались с надлежащей политикой кэширования. Они даже использовали некоторые возможности Progressive Web App, чтобы сайт работал гладко.

Lighthouse, встроенный в Google Chrome Developer Tools, можно использовать для аудита производительности сайта.

Так, может быть, это была проблема, связанная с трафиком? Может быть, скорость сайта хороша до тех пор, пока количество пользователей, использующих его, невелико? Стоит попробовать. Это довольно распространенная ситуация, многие сайты тестируются только на небольшом количестве пользователей. Когда количество пользователей увеличивается, сайт начинает засоряться. Подробнее об этом вы можете прочитать в моей статье о том, почему новые пользователи могут убить ваше веб-приложение. Я провел несколько проверок с помощью инструмента нагрузочного тестирования сайта k6.io, но ничего, все еще приличное время отклика.

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

Профилирование производительности сайта

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

Анализ этой временной шкалы подтвердил наши предположения — элементом Largest Contentful Paint было одно из изображений продукта на главной странице. Почему это изображение отображается пользователю так поздно? Мы проверили формат и размер изображения, и все выглядело хорошо. На самом деле, само изображение загрузилось всего за 122 миллисекунды. Так почему же это изображение появилось спустя почти 6 секунд, если оно загружается всего за долю секунды?

Мы проанализировали временные параметры этого конкретного изображения, и нас удивило то, что оно начало загружаться через 5,7 секунды после запроса сайта. Но почему? Время отклика сервера было приличным, и все изображения должны начать загружаться, как только браузер получит HTML от сервера, верно? Ну…

Ленивая загрузка, выполненная неправильно

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

Ленивый загрузчик предотвращает загрузку изображений, если они не находятся в текущем окне просмотра. Это минимизирует объем передаваемых данных в ситуациях, когда пользователь видит только часть сайта (например, пользователь просматривает только верхнюю часть страницы). Обычно это хорошо и позволяет сайту загружаться заметно быстрее. Обычно…

К сожалению, у этого есть и побочный эффект, о котором знает не каждый веб-разработчик. Ленивый загрузчик — это просто код javascript, который проверяет положение изображения и вычисляет, находится ли оно в текущем окне просмотра. Но это означает, что перед тем, как изображение будет получено, браузер должен получить код Javascript и запустить его. Пользователь не увидит изображение, пока Javascript не решит, что он должен его увидеть. А это приводит к задержке.

Конечно, существует множество способов реализовать ленивый загрузчик так, чтобы минимизировать задержку. Но в нашем случае код, отвечающий за ленивую загрузку, использовал внешнюю, стороннюю библиотеку javascript, которую нужно было сначала получить. Более того, этот код был реализован в обработчике события onload, что означает, что он выполнялся только после завершения загрузки всех элементов сайта, включая стили, шрифты, скрипты и т. д. И все это заняло 5,7 с. Довольно долгое время, чтобы решить, загружать изображение или нет, не так ли?

Результаты оптимизации сайта

Есть много способов решить эту проблему. Мы могли бы избавиться от зависимости от внешней библиотеки или выполнить ленивый загрузчик раньше, чем в onload. Но быстрым решением было просто отключить ленивый загрузчик для изображений, которые всегда отображаются выше сгиба (часть веб-страницы, которая видна без прокрутки). Это простое решение заняло всего одну строку кода и сделало свою работу. Только посмотрите, как увеличилась скорость работы сайта:

Нам потребовалось несколько часов, чтобы найти причину плохой работы LCP и, наконец, добавить эту единственную строку кода. Оптимизация сайта обычно не связана с кодированием, это аналитическая работа по поиску, копанию и исследованию. Конечно, на этом оптимизация не закончилась, все еще можно улучшить. Но мы были удивлены, насколько улучшился показатель Core Web Vitals благодаря простому исправлению в ленивом загрузчике. Мне стало интересно, поэтому я проверил другие популярные сайты электронной коммерции и был удивлен. У многих из них была та же проблема! Похоже, что ленивый загрузчик рассматривается как отличное решение для оптимизации, но очень часто его добавляют небрежно. И его добавление слишком быстро (слишком лениво?) может нанести вред общей скорости сайта. Так что будьте осторожны и не добавляйте на свой сайт всякую ерунду только потому, что все так делают!

Оцените статью
Procodings.ru
Добавить комментарий