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

2022-07-08 09:20:24 Ворчанье деда

Нас больше 1000. Спасибо вам!

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

Почему все острее стоит проблема быстродействия сайтов и веб-приложений? Потому что все меньше внимания уделяется этому вопросу. Быстрый интернет и быстрые процессоры позволяют совсем расслабиться. Но проблема ещё и в самих разработчиках: уже изначально, при входе в профессию, учат не языки, а фреймворки: react, vue, angular. Это крутые инструменты, против них ничего не имею, но если человек не знает как работает JavaScript, то и использовать фреймворки он будет так же.

Я много общаюсь и знаю, что многие разработчики понимают важность быстродействия, но часто проблема системная, и в одиночку с ней не справиться. Например, маркетологи ставят задачу ускорить сайт и одновременно подключить 4 сторонних сервиса для "увеличения конверсии", которые наглухо блокируют основной поток на 4-6 секунд.

Непонимание языка или лень?

Библиотека для вычисления разницы между двумя датами. Серьезно? Это одна функция с совсем простой математикой. Зачем подключать библиотеку на 200 кб? Просто потому что торопился. Да, эта библиотека решает необходимую задачу, и еще 400 других, которые не нужны. Отсюда мы и получаем предупреждение Lighthouse о неиспользуемом коде. Хорошо еще, если используется система сборки и импорт происходит не всей библиотеки, а только необходимой части. Но это скорее исключение из правил. Ведь в Examples этой библиотеки был пример только с полным импортом, так ведь?

Непонимание проблемы производительности.

"8 мегабайт картинка? Ну, у меня за секунду загрузилась на моем гигабитном интернете по проводу, если у вас медленно, значит проблема на вашей стороне." Нет. Картинку можно и нужно сжимать, готовить к публикации. Если с сайтом работают неподготовленные люди, то это должно происходить без их вмешательства. Тоже касается и 8 мб js на странице. Четыре разных слайдера на разных библиотеках, только потому что в примерах один свайпится тачем, а второй по таймеру. Так и хочется процитировать классика "Астанавитесь!". Не у всех такой компьютер как у разработчика. У большинства пользователей будут устройства медленнее чем у разработчика. Это нормально. И даже рост вычислительной мощности процессоров не должен позволять забывать об оптимизации. Даже если это временное решение, то техдолг растёт и со временем становится неуправляемым.

Сложность алгоритмов.

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

Важно: Я НЕ призываю отказываться от готовых библиотек - это нерационально писать велосипеды. Я призываю вдумчиво анализировать что подключается и используется на сайте.

У меня все. Пишите, что думаете по этому поводу в комменты. Открыть/Комментировать

2022-07-07 09:31:20 Я продолжаю каждый день сталкиваться с сайтами, где стандартный функционал браузера реализуют на JavaScript. Наверное можно даже рубрику #nojs сделать. Сегодня рассмотрим возможность закрепления блоков при скролле на чистом css.

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

В CSS уже достаточно давно появилось свойство position: sticky. Указываете его для элемента и позиционируете при помощи inset (top right bottom left) для закрепления. Закреплять можно сверху, снизу, слева и справа. Можно даже по двум осям.

Если вы сомневаетесь, можно ли использовать это решение - смотрите поддержку. На момент написания 96,58%.

Пример на Codepen

Знали вы о таком свойстве? Используете в работе? Пишите в комментарии. Открыть/Комментировать

2022-07-06 09:20:17 Как вы уже знаете, установка соединения очень ресурсоемкая операция. Но что делать, если есть внешний скрипт, который по тем или иным причинам нельзя отложить по времени или первому действию. Например очень часто таким скриптом становится яндекс-метрика. Я постоянно пишу в аудитах и говорю в прямых эфирах, что критичные внешние скрипты можно проксировать через свой домен, но до этого момента никогда не приводил пример такого проксирования. Пора исправить эту ошибку.

Проксирование метрики через свой домен позволяет снизить число установленных соединений, и как следствие ускорить инициализацию при первом запуске проекта. Для корректной работы nginx дожен быть собран с поддержкой sub_filter. В коде метрики нужно заменить https://mc.yandex.ru/ на /proxy-yandex/

Для того, чтобы все заработало, добавляем содержимое файла в секцию server в конфиге nginx нужного хоста. В конфиг внесено два хоста mc.yandex.ru и mc.yandex.com, однако в разных странах подключение может производиться с региональных доменов, например mc.yandex.md, поэтому проверяйте и вносите необходимые домены в конфиг по такому же шаблону. Например: sub_filter 'mc.yandex.md' "$host/proxy-yandex";

Конфиг nginx

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

Если есть вопросы или идеи по улучшению - пишите в комментарии. Открыть/Комментировать

2022-07-05 09:20:34 А что если отложить весь JS?

Привет . В прошлой статье я писал о том, как отложить внешние скрипты. И кто-то мог задаться вопросом: а что если отложить вообще весь JS? Да, мы встречали такие проекты при работе. Сразу скажу, что от проекта к проекту отличались методы отложенной загрузки и выполнения скриптов. Однако мы немного подумали, и вообще сделали конфиг для nginx, который откладывает выполнение всех js на странице в автоматическом режиме. Что-то похожее делает Rocket-loader у Cloudflare, но грузятся и выполняются скрипты только при первом действии пользователя.

Как это работает, nginx на своей стороне дописывает к скриптам type="text/psscript" и скрипт перестает выполняться браузером. Далее при помощи JS создаются новые элементы script, которые загружаются в нужном порядке, и загрузка начинается после срабатывания события.

Важно: для того, чтобы скрипт работал правильно, нужно сделать так, чтобы первый экран отображался одинаково как с включенным так и с выключенным JS. Особенно это касается слайдеров, попапов и тд. И этот может существенно испортить другие показатели по Core Web Vitals, а относительно полезно только для синтетических тестов. Однако кому-то может помочь решить "нерешаемую" задачу.

Конфиг nginx
JS-файл

Как заставить это работать: Конфиг в секцию server, js в корень сайта с тем же именем.

Пишите ваши мнения в комментариях Открыть/Комментировать

2022-07-04 09:31:02 Я много раз писал, что самая ресурсоемкая операция - это установка нового соединения. Сегодня мы обсудим отложенную загрузку внешних скриптов. В отличии от отложенной загрузки изображений, внешние скрипты откладывают по первому действию пользователя, например движению мыши, клику, ресайзу, скроллу, и тд. Это повышает оценку Google PageSpeed Insights. Получаем значительное улучшения показателей, но давайте рассмотрим, что же произойдет, когда пользователь пошевелит мышкой или сделает клик.

Обычная реализация: задается функция, которая создает элемент

2022-07-01 09:20:29 Вот и заключительный день нашей недели Core Web Vitals. Напомню, мы рассмотрели LCP, FID, и CLS. Даже в рамках двух постов в день получилось очень поверхностно, потому что когда писали статью, она не влезала даже в 3 поста Telegram.

Давайте кратко пробежимся по оставшимся трем, которые собирает Google и выводит в Google Pagespeed Insights. Это FCP, INP и TTFB. На самом деле это большая тема, и про улучшения каждого из показателей мы сделаем еще не один пост, так как и методы меняются и поведения браузеров и новые метрики также появляются.

FCP - отрисовка первого контента, это время между событием TTFB и началом отрисовки контента на странице.

до 1.8 секунд
от 1.8 до 3 секунд
более 3 секунд

Для улучшения показателя нужно снижать блокировку отрисовки. Стили делим на Critical и обычные, и inline грузим только критические, остальные подключаем асинхронно, js откладываем при помощи defer или другими методами.

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

до 200 мс
от 200 до 300 мс
более 500 мс

Для улучшения показателя добавляем стильные скелетоны при клике на кнопку без ожидания ответа сервера. И оптимизируем сам Javscript. Разбиваем задачи на более мелкие и упрощаем. Отказываемся от поддержки устаревших браузеров.

TTFB - Время до получения первого байта от сервера. Зависит от времени выполнения скриптов, сети и нагрузки магистралей. Больше всего зависимость от времени выполнения скриптов на сервере. Чем проще задачи - тем быстрее.

до 500 мс
от 500 до 1000 мс
более 1000 мс

Для улучшения нет универсальных средств, самое простое - переехать на более быстрый хостинг, или купить сервер помощнее. Про кэширование мы писали ранее, и скоро вернемся к серии публикаций про TTFB.

На следующей неделе рассмотрим несколько практических методов для улучшения показателей производительности. Хороших выходных!

Пишите, была ли вам полезна информация этой недели? Открыть/Комментировать

2022-06-30 09:20:36 Открыть/Комментировать

2022-06-30 09:20:21 Давайте рассмотрим основные проблемные моменты, почему они происходят и как их устранить.

Возможно смещение контента при загрузке отложенных изображений. До момента загрузки, в src изображения находится заглушка, а после грузится изображение большего формата, и как следствие сдвигает весь контент ниже этого элемента. Для того, что исправить это, просто укажите у изображений width и height. Если изображения масштабируются уже в браузере, нужно указать ширину и высоту оригинальной картинки, для определения aspect-ratio, далее меняете размер уже через стили.

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

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

Бесконечная прокрутка - еще один частый кейс когда происходит CLS. Здесь все просто: если используете бесконечную прокрутку уберите футер, потому что до него, во-первых, никогда не доскроллят, во-вторых, он постоянно будет сдвигаться и приводить к увеличению cls. Можно показывать футер только когда пользователи доскроллят до конца. Главное сделать так, чтобы ниже подгружаемого контента ничего небыло, что могло бы смещаться.

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

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

2022-06-30 09:20:19 Сегодня говорим про CLS - продолжаем серию публикаций про Core Web Vitals.

Зеленая зона: до 0.1
Желтая зона: от 0.1 до 0.25
Красная зона: более 0.25

Cumulative Layout Shift - это ключевой показатель Core Web Vitals, который отвечает за визуальную стабильность страницы во время загрузки и использования страницы. Вот это "во время использования" вызывает у людей больше всего вопросов. Вы можете замерить показатели всех страниц в Lighthouse и везде иметь CLS равный 0, но при этом по Core Web Vitals показатель будет далеко не идеальным, а возможно и вообще в красной зоне.

Все дело в том, что это динамический показатель, и снимается за все время посещения страницы, а не разово, как например LCP, или FID. Тоесть во время загрузки смещений может не быть, но при взаимодействии со страницей могут происходить смещения, которые будут зафиксированы и повлияют на показатель CLS в Core Web Vitals. Однако стоит оговориться, что смещения должны быть неожиданными, например, если происходит добавление элементов сразу после клика на кнопку, и при этом происходит смещение, то эти оно не будет являться неожиданным, так как перед ним следовал клик пользователя. Сразу договоримся, что далее мы говорим именно о неожиданных смещениях, и устранять мы будем не все смещения, а только неожиданные. Неожиданными являются те смещения, перед которыми в течение 500 миллисекунд не происходило взаимодействие пользователя с интерфейсом сайта.

Отмечу, что CLS - это самая частая проблема по метрикам Core Web Vitals, и встречается даже у очень быстрых сайтов. Открыть/Комментировать

2022-06-29 09:10:37 Сегодня говорим про FID - продолжаем серию публикаций про Core Web Vitals.

Зеленая зона: до 100 мс
Желтая зона: от 100 до 300 мс
Красная зона: более 300 мс

FID (First Input Delay) - время между первым действием пользователя на сайте и реакцией на это действие браузера. Этот показатель в теории должен отвечать за отзывчивость сайта во время загрузку и сразу после нее. Чем показатель ниже, тем лучше. В теории должен показывать насколько отзывчив сайт, на практике практически всегда в зеленой зоне.

В первую очередь на этот показатель влияет время выполнения JavaScript кода на странице, и если показатель в желтой или тем более в красной зоне, то у сайта действительно серьезные проблемы с отзывчивостью. На мой взгляд, FID не отражает реальную отзывчивость сайта, и должен быть переработан. В этом направлении уже идут работы, потому что недавно был добавлен тестовый показатель INP (Interaction to Next Point), про который речь пойдет в другой день. INP гораздо лучше помогает оценить отзывчивость сайта, так как лишен минусов FID.

Минусы показателя:
1. Не отражает реальный пользовательский опыт, так как чаще всего пользователи ждут загрузки и только после этого взаимодействуют с сайтом.
2. Большинство сайтов имеют хороший показатель, но при этом плохую отзывчивость.
3. При первом взаимодействии проблем может и не быть, зато во время выполнения других операций будет полная блокировка потока и как следствие - плохая отзывчивость

INP при этом лишен этих минусов и более релевантен реальному пользовательскому опыту.
Однако в Core Web Vitals входит только FID, и пока стоит ориентироваться на него. Открыть/Комментировать