Делимся секретами как создавать быстрые сайты и ускорять существующие. По вопросам сотрудничества: @fenixru При использовании материалов канала обязательна прямая заметная и без редиректов ссылка на него и указание авторства: Антон Белогородцев.
Оценить канал perfscan и оставить отзыв — могут только зарегестрированные пользователи. Все отзывы проходят модерацию.
5 звезд
2
4 звезд
0
3 звезд
1
2 звезд
0
1 звезд
0
Последние сообщения 2
2022-07-29 16:19:01
Друзья, спасибо вам, нас уже больше 2000 человек, кто интересуется темой производительности сайтов и web-приложений. Всего полтора месяца назад я открыл этот канал для публичного доступа, и вот нас уже больше двух тысяч. Но это только начало, впереди куча идей и постов, которые будут также полезны, или даже полезнее, чем то, что уже опубликовано.
Хочу сделать видео-разбор ваших проектов в прямом эфире, вы бы отправили свой проект на разбор? Или NDA, все дела?
И очень хочу обратной связи по темам постов, про что вы хотите публикации, а может быть и целую новую рубрику?
Сегодня я расскажу в чем проблема библиотек слайдеров на javascript. В целом я не против слайдеров и каруселей - их можно сделать так, чтобы они минимально влияли на быстродействие сайта. Однако готовые библиотеки, например slick и owl, сильно влияют на #LCP, #CLS и #TBT. Сегодня я расскажу в чем основная ошибка этих библиотек, и как избежать этих ошибок, разрабатывая свое решение.
1. Стилизация слайдера происходит через классы, которые добавляются только при инициализации. В связи с этим до инициализации страница выглядит совсем по другому, или часть элементов вообще скрыта, зависит от библиотеки и настроек. Это влияет на LCP, если слайдер скрыт, и на CLS, если не заданы размеры. Слайдер изначально развернут, и потом схлопывается до конечных размеров.
2. Слайдер при инициализации вносит изменения в DOM, добавляя классы и элементы, меняя родительские и дочерние элементы. Происходит буквально переверстка страницы, а как следствие ее перерисовка. Это влияет в первую очередь на TBT.
3. При карусели с бесконечной прокруткой, слайдер добавляет клоны предыдущих и следующих элементов, чтобы обеспечить анимацию. Это вызывает лишние перерисовки и раздувает DOM, если внутри содержится сложная верстка.
Как сделать свой слайдер без всех этих ошибок? Используйте CSS. Делайте так, чтобы даже с выключенным JS слайдер можно было скроллить при помощи встроенного скролла и свойства scroll-snap-type. Все элементы слайдера формируйте в верстке или на backend, и в js прописывайте только взаимодействие. Например, клики по стрелкам или точкам под слайдером. JS не должен менять структуру DOM без явного взаимодействия с пользователем. Только после клика или свайпа можно добавлять класс, или следующий элемент для плавных анимаций. Внешний вид слайдера не должен отличаться при выключении JS.
Когда-нибудь я напишу пример на чистом JS, чтобы поделиться с вами.
Пишите коммент, и ставьте лайк, если нужен пример хорошего слайдера, или присылайте свое решение.
В прошлом посте я обещал рассказать, почему не стоит использовать заглушки до события onload. Все просто, первая отрисовка будет быстрее, а вот LCP-элемент появится гораздо медленнее.
Допустим, LCP-элементом является картинка на первом экране, и кроме нее грузятся еще и javascript файлы, и другие изображения и шрифты. LCP-элемент по факту грузится под такой заглушкой, и даже если он загрузится быстро, то пользователь его не увидит до момента, пока заглушка не исчезнет. Хуже может быть только если скрытие этой заглушки происходит с анимацией, допустим 500 миллисекунд. Таким образом, вы отложите появление LCP-элемента еще и на время анимации.
Чаще всего за такой заглушкой скрывают подгрузку стилей или SPA-приложения, но нужно не скрывать, а работать над визуальной стабильностью, лучше выделить critical-css, чтобы картинка не прыгала во время подгрузки, и необходимость в заглушке отпадет.
Но как же быть в SPA-приложении? Там вместо стандартной заглушки с крутилкой и надписью "подождите", лучше использовать skeleton loader, когда заглушка имитирует контент, который появится на странице уже после окончательной подгрузки. Проблему #LCP это не решит, но решит проблему смещения.
Правила: 1. Никогда не используйте заглушку контента. 2. Не используйте анимацию, если решили, что первое правило не для вас. 3. Никогда не нарушайте первое правило.
На прошлой неделе делал технический аудит сайту, который очень долго загружался. Знаете в чем оказалась причина? В пикселе ретарегета, заблокированного на территории РФ. Просто убрали подключение сервиса, которым кстати никто не пользовался сразу после блокировки, но с сайта конечно не убрали.
Проблема оказалась в том, что на сайта стояла заглушка при загрузке (про них, кстати, будет отдельный пост - то еще зло для производительности), которая пропадала на событие load у window. Никогда так не делайте. Особенно, если подключается сторонний синхронный код, работоспособность которого вы не можете гарантировать.
Некоторые провайдеры не режут соединение и событие error не срабатывает, а ресурсы с заблокированных доменов грузятся бесконечно, пока не сработает timeout в браузере. Здесь мы также бессильны, если только не писать свой worker для того, чтобы разрывать соединение, или возвращать заглушку, если загрузка не произошла за первые секунды.
Проверьте прямо сейчас консоль вашего сайта, возможно там куча ошибок о безопасном соединении, которые возникают, если провайдер просто рвет соединение с заблокированным хостом. Если есть - задумайтесь нужны ли вам эти сервисы и если нужны, подключайте их в зависимости от географии пользователя.
Еще одна причина проверить сторонний код - это сторонние сервисы, которыми вы не пользуетесь, и которые могут быть заброшенными, а как следствие после истечения домена злоумышленник может перекупить его и загрузить на ваш сайт по старой ссылке вредоносный код. Поверьте, это происходит регулярно.
А вы убираете код с сайта после блокировки его домена в вашей стране?
При выборе CDN обязательно проверяйте регионы присутствия, если вы подключите CloudFlare или любой другой иностранный сервис к сайту, у которого посетители только из одной страны, то прироста за счет сети не будет, так как в каждой стране присутствует максимум 1-2 сервера, и разницы будет не видно. Если конечно вы не планируете использовать автоматическую оптимизацию от сервиса. Про это поговорим в отдельном посте. Выбирайте CDN с максимальным присутствие в вашей стране, чтобы было покрыто максимальное число городов и регионов, где находятся ваши клиенты. Если информации о покрытии нет на сайте, то ее следует запросить перед покупкой.
Основные ошибки при подключении CDN - использовать отдельный домен для статики. Я почти в каждом посте повторяю, что установка соединения - самая ресурсоемкая операция, поэтому проксировать нужно весь домен. Если не выполнить это правило, то сайт может не просто не ускориться, а даже замедлиться.
У всех CDN есть правила настройки кэширования, тогда вы сможете управлять какой контент стоит кэшировать и на сколько. Управлять кэшем CDN проще всего через HTTP-заголовки, которые передает ваш сервер и указывать для динамики запрет кэширования, а для статики полный кэш навсегда. Если есть возможность настройки в самом кабинете CDN, то смотрите, какие оптимизации делает CDN, и для начала не включайте никакие - замерьте скорость. Возможно, внутренние оптимизации CDN помогут еще ускорить ваш сайт и отказаться от рутины в ускорении.
Например сервис W.tools (внимание, реф-ссылка) может выполнять базовые оптимизации, сжимать изображения, конвертировать в webp, использовать 0-RTT и другие современные фишки, которые можно настроить на стороне сервера.
Не стоит сразу бежать и платить, именно за этот или любой другой сервис вам он может не подойти, обязательно все взвешивайте и просчитывайте, и кроме этого общайтесь с поддержкой. У многих сервисов есть тестовый период, если нет, то никто не мешает спросить в поддержке, многие сервисы очень часто идут на встречу.
Был ли у вас опыт использования CDN? Расскажите, какой сервис используете, и каких результатов добились?
update: Снова какая-то проблема с комментариями. Можете писать и задавать вопросы в предыдущем посте.
2022-07-25 15:32:51
Сегодня расскажу про CDN: нужно ли подключать, как выбрать, и как подключать правильно. CDN - Content Delivery Network (сеть доставки контента), это когда контент доставляется пользователю с ближайшего к нему сервера, что снижает пинг и RTT, и как следствие ускоряет загрузку.
А нужен ли сайту CDN? Чтобы понять это, достаточно ответить на три вопроса:
1. Мои клиенты из разных городов/стран? 2. Есть ли посещаемость за пределами одного города? 3. Много ли приносят денег посетители из других регионов.
Если на 1 вопрос ответ "нет", то достаточно разместить сайт на хостинге в пределах вашего региона, чтобы посетители получили ускорение загрузки. Если же ответ "да" на все три вопроса, то можно попробовать подключить CDN в режиме тестирования и проверить, как изменится конверсия и скорость загрузки сайта из других регионов.
Помните, когда-то давно были WAP-сайты, которые мы открывали с мобилок с черно-белым экраном и качали картинки с рингтонами? Интересно, довелось ли кому-то из моих подписчиков их разрабатывать? У меня был такой опыт. Почему вспомнил - недавно работал над скоростью AMP-сайта, и это что-то среднее между современным html и WAP-версткой. Чуть больше свободы, но скрипты свои уже не напишешь, теги которых нет в стандарте также не используешь, и все что мы можем сделать - это оптимизировать изображение и уменьшить влияние стороннего кода.
Сегодня пятница, а значит давайте подискутируем, почему получается так, что технология, созданная для ускорения загрузки сайтов по факту грузится дольше, чем оригинальный оптимизированный сайт? Что вы думаете вообще про технологии AMP/Турбо/Instant Article? Это будущее, или очередной тупик, как и WAP?
Как и preconnect, только как такового соединения не происходит, исключительно резолвинг dns. Если не используете preconnect, то dns-prefetch может ускорить установку этого соединения. Используется если неизвестно, понадобится ли соединение, но если понадобится, то мы точно знаем что dns-запрос уже выполнен.
Частая ошибка: как и в preconnect - большое число запросов к днс снизит общую производительность вашего сайта.
Говорит браузеру открыть невидимую вкладку и загрузить страницу, выполнить все скрипты, и загрузить все ресурсы. Очень интересное свойство, которое позволяет значительно ускорить переход между страницами. Поддержка этого свойства оставляет желать лучшего всего 75.36% на момент написания поста. Однако в Google Chrome следующую страницу можно показать почти моментально. Очень перспективно, но нельзя полагаться на него из-за низкой поддержки. Добавлять тег можно только если вы точно знаете, какая будет следующая страница у человека. Грузить первую из ссылок не эффективно, а грузить все ссылки опасно для быстродействия.
Частая ошибка: Делать prerender нескольких старниц, так как в фоне будет запущена вся страница. Еще одна ошибка - думать что ты лучше пользователя знаешь куда он перейдет. Может и никуда, но мы ему уже выполнили что-то там в фоне без его ведома.
Напишите, не повторяете ли вы ошибки, которые описаны выше?
update: Почему-то нет комментариев у последнего поста. Можете писать и задавать вопросы в предыдущем.
2022-07-21 12:19:33
В чем отличия preload, prefetch, preconnect, dns-prefetch, prerender и как они работают? Если мы говорим про скорость сайтов, то нельзя не упомянуть об этих техниках. Бывают случаи, когда просто удаление нескольких прелоадов или преконнектов из кода страницы уже дает прирост скорости. Давайте разбираться, почему. Для начала коротко о каждом.
Этим тегом мы говорим браузеру, что уже прямо сейчас нам понадобится стиль style.css, и нужно немедленно их загрузить, не дожидаясь события load всей страницы с наивысшим приоритетом. Часто это снимает блокировку отрисовки, так как стили оказываются уже загружены, когда парсинг html-документа завершен.
Частая ошибка: загружать огромное число ресурсов, что в итоге замедляет загрузку всей страницы. Не рекомендуется использовать со сторонними доменами, так как придется устанавливать соединение, а как вы уже знаете, это самая ресурсоемкая операция и можно потерять до 500мс на каждый коннект. Еще одна ошибка - выполняется загрузка ресурсов, которых нет на странице. Тут очевидно, лишний трафик с повышенным приоритетом замедлит отображение.
Благодаря ему браузер как и в случае с preload может установить соединение еще до окончания парсинга документа, что ускоряет первое обращение к ресурсу с этого домена. Для чего использовать: У вас есть отдельный домен с api, или статикой, которые невозможно перенести на основной домен даже проксированием, например из-за сложной архитектуры проекта. В этом случае использовать preconnect можно и нужно.
Частая ошибка: использовать для всех внешних ресурсов на странице, включая яндекс-метрику, пиксели ретаргетинга, вернее домены, где лежат их скрипты. В особенных случаях можно найти все внешние подключения и даже больше внутри этих тегов. Еще одна ошибка - устанавливать соединение с доменами, которые не понадобятся на этой странице вообще, или понадобятся далеко не сразу.
Текущую страницу он не ускоряет, но позволяет в фоне, после окончания всех операций в основном потоке или между ними загрузить ресурс и сохранить его в кэше. Например человеку при заходе на листинг товаров можно выполнить prefetch стилей для карточки товаров, потому что вероятность того, что он туда перейдет высокая. Если использовать ресурсы текущей страницы, то скорее всего ничего не изменится, если только они не вызываются по клику на кнопку при помощи js, тогда использование тега обосновано.
Частая ошибка: использовать этот тег вместо preload. Загрузка не ускорится и приоритет не повысится, а значит текущая страница не ускорится.
Часто встречается ситуация, когда в JS нужно выполнить много тяжелых операций, и показатель #TBT от этого будет расти. Современный JS позволяет начать выполнение следующей операции только когда предыдущая завершена и основной поток свободен для новых задач.
Знакомьтесь - requestIdleCallback метод, который позволяет выполнять операции во время простоя браузера, только когда основной поток свободен и новая задача минимально повлияет на быстродействие. Метод достаточно старый, но поддержка браузерами, не очень большая, на момент написания поста 78.33%. Но не переживайте полифилл очень простой и его можно просто включать в ваш код.
Если браузер не поддерживает requestIdleCallback, то функция просто выполнится по таймауту.
Как пользоваться этим методом.
requestIdleCallback(() => { // Ваш код }, {timeout: 1000});
timeout - время в миллисекундах через которое функция будет выполнена безусловно, даже если основной поток загружен и выполнение приведет к падению быстродействия. Если не указывать, то метод всегда будет ждать свободного времени для выполнения.
Помните, это не волшебная кнопка и если просто обернуть в этот метод весь ваш js код, то разницы в быстродействии не будет, нужно логически разбивать код на блоки, выполнение которых не зависит друг от друга, тогда будет видна разница в быстродействии. И интерфейсные вещи первого экрана (события на кнопки и тд) лучше не откладывать, чтобы не понижать отзывчивость вашего сайта.
P
