perfScan - Секреты быстрых сайтов

2022-06-29 09:10:37 Открыть/Комментировать

2022-06-29 09:10:37 Для улучшения показателя FID в первую очередь следует отложить загрузку контента, которого нет на первом экране. При использовании реактивных фреймворков можно откладывать гидрацию целых компонентов, чтобы максимально быстро отобразить контент первого экрана. Откладываем изображения при помощи кода, о котором мы писали ранее. Откладываем внешние скрипты до момента когда они будут необходимы, или до момента первого действия пользователя на странице (mousemove, click, touchstart, scroll, resize).

Далее разбиваем большие задачи в JavaScript на более мелкие. Например, если вы в большом цикле обрабатываете большое число задач, то стоит их вынести в отдельные функции и вызывать через setTimeout или requestIdleCallback для того, чтобы задачи вставали в очередь и не блокировали основной поток браузера.

Максимально уменьшаем число внешних соединений, так как установка соединения - самая ресурсоемкая операция. Минимизируйте число preconnect, dns-prefetch, prefetch и preload. Используйте их только для ресурсов которые есть на первом экране, но опять же помните, что лучше перенести или проксировать данные через свой домен.

Если у вас есть проблемы с этим показателем - пишите в комментариях. Открыть/Комментировать

2022-06-28 09:12:01 Открыть/Комментировать

2022-06-28 09:12:01 Улучшаем LCP

Если LCP-элементом является изображение, то нужно проверить, не отложено ли оно. Изображения, которые могут являться LCP-элементом ни в коем случае не откладываем. Далее максимально сжимаем это изображение. Для быстрого сжатия воспользуйтесь приложением, о котором мы писали ранее. Обязательно проверьте разрешение изображения. Часто бывает, что на первом экране изображение с зеркалки размером 6000х4000 пикселей, а то и больше, с весом 18 мб. Если его просто сжать и перевести в webp и avif, мы все равно получим 2-4 мегабайта данных, что очень много. Сжимайте изображение так, чтобы оно весило не более 100 кб. Меньше - лучше. Для повышения приоритета загрузки, если на странице много запросов, можно добавить .

Если LCP - это текстовый тег, например h1, или p, то здесь нужно проверить, что шрифты загружены, и для них используется font-display:swap. Без этого до момента загрузки шрифта будет просто белый экран. Если шрифты подключаются из Google Fonts, то перечитате наши посты (раз, два, три). Если шрифт грузится с вашего хоста, используйте формат woff2 и добавьте именно его в прелоад: .

Если же LCP-элементом является div, у которого есть фоновое изображение и текстовое содержимое, то тут возникает проблема с приоритетом загрузки, и для его отображения нужно загрузить картинку и загрузить шрифт. Лучше всего переверстать такой блок так, чтобы использовался тег img, а не фоновое изображение. Это поможет браузеру определить очередность загрузки и LCP улучшится. Далее определяем новый LCP-элемент и заново пробегаем по алгоритму.

Из неочевидных возможностей улучшения показателя LCP на сайте - смещение фокуса. Например, можно добавить на фон контейнер div c контрастной заливкой и без какого-либо содержимого подложкой под весь первый экран с абсолютным позиционированием. Самое важное при смене фокуса - проработать изменение дизайна, тогда можно будет вообще убрать фотографию с первого экрана. Открыть/Комментировать

2022-06-28 09:12:01 Сегодня все внимание на LCP - продолжаем серию публикаций про Core Web Vitals.

Зеленая зона: до 2.5 секунд
Желтая зона: от 2.5 секунд до 4 секунд
Красная зона: более 4 секунд

LCP (Largest Contentful Paint) - Скорость загрузки основного контента, который занимает большую часть первого экрана страницы и является контрастным к фону. Так как мы говорим про Core Web Vitals, то следует учитывать какой элемент страницы является LCP-элементом, так как загрузка происходит с разных устройств с разным разрешением экрана, и где-то на первый экран может попадать больше контента и естественно, что элементы могут быть разными. Кроме того, для разных страниц LCP-элемент также может быть разным. Где-то вставлено небольшое изображение и LCP-элементом может являться большой заголовок, а где-то наоборот небольшой заголовок, но большое изображение, и уже изображение является LCP-элементом.

Большой показатель может свидетельствовать о том, что у пользователя есть проблема с отображением основного контента страницы, а это создает у пользователя иллюзию медленного интернета. Да, пользователь редко когда воспринимает медленным ваш сайт, чаще он будет думать, что тормозит интернет или устройство с которого он посетил ваш сайт. Так вот, если мы понимаем, что есть проблема с LCP, нам нужно в первую очередь понять, какой элемент является LCP-элементом. Для этого можно использовать отчеты Lighthouse, или Google Pagespeed Insights, который кстати тоже работает на Lighthouse. И уже после этого принимать решение, что делать. Открыть/Комментировать

2022-06-27 09:15:19 Начинаем сегодня и в течение недели будем публиковать методы улучшения показателей Core Web Vitals.

Google анонсировал Web Vitals в 2019 году, а уже в 2021 году показатели Core Web Vitals стали влиять на выдачу в Google. Основные метрики Core Web Vitals - это LCP, FID и CLS, именно про них гугл выдает предупреждения в Google Webmaster Console.

Данные Web Vitals - это живые данные, которые получены и агрегированы на серверах Google от браузеров реальных пользователей. Google Chrome в фоновом режиме передает в Google данные о скорости посещенных сайтов. Показатели метрик, адреса страниц, данные об устройстве и взаимодействии со страницей. Данные усредняются и выводятся по 75-ому процентилю (не путать с квантилем). Это когда вычисляется значение так, чтобы 75% общих данных находились ниже этого предела.

Все данные можно получить через коннектор Chrome UX Report. Переходим, вводим сайт (с www и https) и нажимаем связать. Далее давим создать отчет и получаем графический отчет с историей изменения всех показателей (если данных достаточно).

Кроме основных показателей, которые описаны выше, мы увидим еще и другие данные, некоторые из них могут быть вам знакомы по отчетам Lighthouse, а некоторые совсем непонятные, которые собирает гугл, а это FCP, INP, TTFB, FP, Notification Permissions, DCL, OL и параметры распределения устройств и скорости соединениям: Device Distribution и Connect Distribution. Подробно их все обязательно разберем в течение этой недели.

Данные в отчете Chrome UX Report обновляются раз в месяц, тоесть данные всегда с отставанием, примерно в один месяц. Более точные данные за последние 28 дней (что тоже не моментально) можно найти в Google Pagespeed Insights, и в Chrome UX Report API. Быстро данные из этого API можно увидеть на сайте webvitals.ru.

Завтра разберем LCP, как основной показатель, отвечающий за скорость загрузки.

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

2022-06-24 09:33:01 Открыть/Комментировать

2022-06-24 09:33:01 Мы готовим большой гайд по метрикам Core Web Vitals.

Выходит целых 8 сообщений на канал.
Нужна ли подробная информация с примерами про каждый из показателей?
Хотите ли вы получать информацию сразу или порционно по посту в день? Открыть/Комментировать

2022-06-23 11:22:59 Откладываем Youtube

При вставке кода Youtube или любого другого плеера, будь то Rutube, VK или Vimeo на свой сайт, мы получаем загрузку самого плеера, кодов отслеживания сервиса, аналитику сервиса, огромные бандлы JavaScript, а в некоторых случаях и часть видео, даже если человек его не запускает.

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

HTML: 64 килобайта
CSS: 346 килобайт
Изображения: примерно 150 килобайт (в зависимости от видео и его превью)
Шрифты: 17 килобайт
JavaScript: 2.47 мегабайта
XHR-запросы: примерно 100 килобайт

Итого: примерно 3,5 мегабайта

Но что самое страшное: 10 новых соединений

Мы только подключили одно видео через код YouTube, а пользователь скачал 3,5 мегабайта и установил 10 соединений. Ужас!

Давайте решать эту проблему.

Можно использовать свойство тега iframe под названием srcdoc (обязательно смотрите поддержку). Внутри этого свойства просто задаем разметку со ссылкой на плеер ютуба с параметром автоплей. Никакого JS (#nojs), только стандартный функционал браузера.

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

Да, кстати, по такой же технологии можно откладывать до клика любой сторонний код который подключается при помощи iframe, в том числе и карты.

Код на CodePen Открыть/Комментировать

2022-06-22 09:05:13 Отложенная загрузка изображений

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

1. Индексация изображений поисковиками должна проходить быстро и без проблем.
2. Загрузка должна проходить в момент появления элемента на экране, но без больших математических вычислений.
3. Необходима возможность очень гибко управлять этим механизмом.
4. Не должно быть зависимостей от других библиотек.

Нативная отложенная загрузка loading="lazy" для тега img не поддается гибкому управлению, нельзя выделить сколько пикселей ниже следующего экрана прогружать изображение, и в итоге они все равно загрузятся все, но с меньшим приоритетом, однако кроме гибкости решения, этот механизм подходит во всем.

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

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

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

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

Код на Codepen Открыть/Комментировать