❗️ Сегодня речь пойдет о так называемом Critical CSS - небольшой хитрости для ускорения первой отрисовки (#fcp, #lcp) страницы и устранению её блокировки файлами стилей. Если у вас FCP больше 1.5 сек, то определенно стоит озадачиться.
Как обычно выглядит проект в конечном виде - HTML, в котором подключаются файлы стилей. Так вот, отрисовка страницы не начнется, пока все файлы стилей не будут загружены и прочитаны. Находятся умельцы, которые файлы стилей переносят из head куда-нибудь перед
Чтобы этого избежать, стили, необходимые для отрисовки первого экрана нужно поместить в код страницы в тег
Загружать весь набор стилей проекта не нужно, для этого их разбивают по типам страниц и подгружают то, что необходимо для отрисовки конкретно этой страницы. На главной интернет магазина в critical попадет часть сетки, и весь первый экран, в основной файл - стили для отрисовки оставшейся страницы, а стили для отрисовки страницы товара вообще не загрузятся для этой страницы.
Чтобы выделить Critical-CSS, лучше выполнять верстку покомпонентно, как в современных фреймворках, и управлять вручную теми стилями, которые попадут inline, или использовать инструменты для выделения критических стилей для текущей страницы, например плагин для вебпака, и отдельные приложения для экстракции стилей с готовой верстки critical.
⚠️ Помните, что не стоит все стили выносить inline: по всем замерам они больше не будут блокировать, однако пользователю придется грузить их каждый раз, поэтому используйте кэширование.
💬 А вы используете Critical-CSS?
Как обычно выглядит проект в конечном виде - HTML, в котором подключаются файлы стилей. Так вот, отрисовка страницы не начнется, пока все файлы стилей не будут загружены и прочитаны. Находятся умельцы, которые файлы стилей переносят из head куда-нибудь перед
</body> и первая отрисовка становится почти мгновенной, но сначала мы видим страницу без стилей, а затем перерисовка и огромный CLS.Чтобы этого избежать, стили, необходимые для отрисовки первого экрана нужно поместить в код страницы в тег
<style>. Тогда прыгать контент не будет, и эти стили применятся к странице сразу же. Остальные стили при таком формате нужно подключать в <head> сайта, но чтобы они загрузились как можно быстрее и не блокировали отрисовку. Для этого отлично подходит небольшой лайфхак:<link rel="preload" as="style" href="style.css" onload="this.onload=null;this.rel='stylesheet'">Загружать весь набор стилей проекта не нужно, для этого их разбивают по типам страниц и подгружают то, что необходимо для отрисовки конкретно этой страницы. На главной интернет магазина в critical попадет часть сетки, и весь первый экран, в основной файл - стили для отрисовки оставшейся страницы, а стили для отрисовки страницы товара вообще не загрузятся для этой страницы.
Чтобы выделить Critical-CSS, лучше выполнять верстку покомпонентно, как в современных фреймворках, и управлять вручную теми стилями, которые попадут inline, или использовать инструменты для выделения критических стилей для текущей страницы, например плагин для вебпака, и отдельные приложения для экстракции стилей с готовой верстки critical.
⚠️ Помните, что не стоит все стили выносить inline: по всем замерам они больше не будут блокировать, однако пользователю придется грузить их каждый раз, поэтому используйте кэширование.
💬 А вы используете Critical-CSS?
👍24🔥4👏2😱2
❗️ При загрузке контента одна из важных метрик - это #fcp - первая отрисовка контента. Это чаще всего элементы интерфейса, или текст. Для пользователя комфортнее, если отрисовка начнется раньше.
Как оценивается показатель FCP:
🟢 Зеленая зона: до 1.8 секунды
🟡 Желтая зона: от 1.8 секунд до 3 секунд
🔴 Красная зона: более 3 секунд
Давайте разбираться, как улучшить этот показатель и какие частые ошибки можно встретить.
1. В
2. Нет критических стилей, о которых мы писали вчера. Используйте их, это хорошо для первой отрисовки.
3. Шрифты используются без
4. В
⚠️ В Lighthouse есть аудит "Старайтесь не допускать создания цепочек критических запросов". Как раз тут нужно следить, чтобы цепочка была как можно короче, и там ни в коем случае не было внешних сервисов и поддоменов. Отличный аудит - один из самых полезных при отладке FCP.
💬 А как у вас дела с первой отрисовкой?
Как оценивается показатель FCP:
🟢 Зеленая зона: до 1.8 секунды
🟡 Желтая зона: от 1.8 секунд до 3 секунд
🔴 Красная зона: более 3 секунд
Давайте разбираться, как улучшить этот показатель и какие частые ошибки можно встретить.
1. В
<head> загружается слишком много стилей или js файлов. Помните, что стили и скрипты без async и defer блокируют первую отрисовку до момент пока не будут загружены и выполнены подключаемые файлы. Оставляйте там только то, что необходимо для первой отрисовки2. Нет критических стилей, о которых мы писали вчера. Используйте их, это хорошо для первой отрисовки.
3. Шрифты используются без
font-display:swap|optional или того хуже с Google Fonts. Не используйте Google Fonts. Такую ошибку можно часто встретить там, где первый экран на белом фоне, и нет основных элементов интерфейса. Пока шрифты не загрузятся у пользователя будет просто белый экран, хотя началась отрисовка уже второго и третьего блоков.4. В
<head> подключаются стили или скрипты со сторонних доменов, что может съедать 500-600 миллисекунд на установку соединения. Если подключений больше, то задержка может стать еще больше. Если нельзя перенести стили или скрипты на свой домен, проксируйте тем же способом, как мы предлагали проксировать яндекс-метрику.⚠️ В Lighthouse есть аудит "Старайтесь не допускать создания цепочек критических запросов". Как раз тут нужно следить, чтобы цепочка была как можно короче, и там ни в коем случае не было внешних сервисов и поддоменов. Отличный аудит - один из самых полезных при отладке FCP.
💬 А как у вас дела с первой отрисовкой?
👍15🔥6👏2
❗️ Сегодня расскажу об интересной технологии, которую можно использовать вместо безвременно почивших HTTP/2 Server Push. Напомню, раньше была возможность при помощи веб-сервера вместе со страницей отправить сразу нужные ресурсы, которые подгружаются на этой странице, но Google удалил поддержку из Google Chrome. А как же хорошо они работали вместе HTTP 103 Early Hints!
HTTP 103 Early Hints - это другая и тоже интересная на мой взгляд технология. Вместо проталкивания указанных ресурсов, как это делал Push, сервер отдает два ответа. Первый моментально 103 Early Hints с HTTP заголовками, например preconnect или preload, и затем второй как обычно 200. Это позволяет начать загрузку ресурсов еще до момента, когда поступит настоящий полный ответ сервера с содержимым. В отличии от Server Push здесь не будет передачи лишних байт, если стили были закэшированы, браузер возьмет их из кэша. Во-вторых, пока происходит генерация даже какой-то тяжелой страницы, браузер может уже начать загрузку критичной статики.
🧩 Как использовать: Поддержки в ядре nginx пока нет, поэтому только собирать сторонние модули к нему. Поддержка apache2 есть, но при проксировании через nginx может не работать. Опробовать как это работает можно через CloudFlare, включив нужную галочку. Попробовать точно стоит, если ttfb больше 200 мс, ускорение может быть очень заметным. Для того, чтобы заработало, передавайте заголовки серверу из своего приложения. Браузерная поддержка есть пока только в свежем Google Chrome, но думаю, другие браузеры быстро подтянуться.
Например в php
💬 А вы слышали про 103 Early Hints?
HTTP 103 Early Hints - это другая и тоже интересная на мой взгляд технология. Вместо проталкивания указанных ресурсов, как это делал Push, сервер отдает два ответа. Первый моментально 103 Early Hints с HTTP заголовками, например preconnect или preload, и затем второй как обычно 200. Это позволяет начать загрузку ресурсов еще до момента, когда поступит настоящий полный ответ сервера с содержимым. В отличии от Server Push здесь не будет передачи лишних байт, если стили были закэшированы, браузер возьмет их из кэша. Во-вторых, пока происходит генерация даже какой-то тяжелой страницы, браузер может уже начать загрузку критичной статики.
🧩 Как использовать: Поддержки в ядре nginx пока нет, поэтому только собирать сторонние модули к нему. Поддержка apache2 есть, но при проксировании через nginx может не работать. Опробовать как это работает можно через CloudFlare, включив нужную галочку. Попробовать точно стоит, если ttfb больше 200 мс, ускорение может быть очень заметным. Для того, чтобы заработало, передавайте заголовки серверу из своего приложения. Браузерная поддержка есть пока только в свежем Google Chrome, но думаю, другие браузеры быстро подтянуться.
Например в php
<?php header('Link: </style.css>; rel=preload; as=style');?>💬 А вы слышали про 103 Early Hints?
👍9🔥5👏2👌2❤1
❗️ Необычный #lifehack позволит ускорить постраничную навигацию, например в большом интернет магазине. На странице 20 товаров. Показ следующей страницы происходит после нажатия на кнопку "показать еще". Ответ от сервера приходит за 300 миллисекунд, значит до времени показа следующей страницы будет задержка не меньше этой цифры. Показатель INP на этой странице вырастет, и сайт станет менее отзывчивым.
Давайте для начала поймем, что мы хотим получить? Ускорить ответ сервера, используя кэш? А зачем? Нам нужно только показать следующую страницу быстрее. Давайте разбираться, какие еще есть варианты.
Можно загрузить следующую страницу в фоне, когда пользователь проскроллит например 50% от всех вариантов, и скрыть их до момента нажатия кнопки "показать еще". После нажатия кнопки показываем скрытые элементы и выполняем следующий запрос. После нажатия мгновенно отображается следующая страница, пока изучаем варианты грузится следующая. Быстрее приложение по факту не стало, но мы отдаем результат с точки зрения пользователей мгновенно. Задача решена.
Такой подход можно назвать визуальным ускорением, и иногда он идет вразрез с реальной скоростью приложения, но решает задачи бизнеса, и пользователи на такой странице чувствуют себя более свободно, так как реакция на их действие происходит мгновенно.
💬 Что вы думаете о таком подходе? Использовали когда-то подобные фишки? Пишите свои варианты подобных механик.
Давайте для начала поймем, что мы хотим получить? Ускорить ответ сервера, используя кэш? А зачем? Нам нужно только показать следующую страницу быстрее. Давайте разбираться, какие еще есть варианты.
Можно загрузить следующую страницу в фоне, когда пользователь проскроллит например 50% от всех вариантов, и скрыть их до момента нажатия кнопки "показать еще". После нажатия кнопки показываем скрытые элементы и выполняем следующий запрос. После нажатия мгновенно отображается следующая страница, пока изучаем варианты грузится следующая. Быстрее приложение по факту не стало, но мы отдаем результат с точки зрения пользователей мгновенно. Задача решена.
Такой подход можно назвать визуальным ускорением, и иногда он идет вразрез с реальной скоростью приложения, но решает задачи бизнеса, и пользователи на такой странице чувствуют себя более свободно, так как реакция на их действие происходит мгновенно.
💬 Что вы думаете о таком подходе? Использовали когда-то подобные фишки? Пишите свои варианты подобных механик.
👍33🔥6❤🔥2👏2🕊2
❗️ Мало кто знает, что существует интересное свойство
Как этим пользоваться: указываете для типовых блоков
Пользоваться свойством нужно осторожно, так как его использование может вызывать CLS. Чтобы этого не происходило, указываете
Крайне эффективно работает для повторяющихся элементов с большим числом потомков. А если у вас на странице есть бесконечная прокрутка, то свойство просто must have. Начинать использовать можно уже сейчас, потому что самое страшное что может случиться, оно просто не сработает в неподдерживаемых браузерах.
⚠️ Помните, однако, что content-visibility может странно повлиять на position: fixed внутри элементов. Как-то раз очень долго не мог отловить ошибку, когда внутри content-visibility в попапе ехала верстка. Решилось вынесением из элемента попапа выше по DOM.
💬 А вы используете
content-visibility. Появилось оно в 85-ом хроме и создано для ускорения первой отрисовки контента. На момент написания поста, поддержка не очень большая. Суть свойства в том, что он не отрисовывает и не применяет стили для блоков которые находятся вне viewport. В некоторых случаях позволяет улучшить отрисовку в разы, а как следствие и #fcp.Как этим пользоваться: указываете для типовых блоков
content-visibility: auto, в листинге и блоков которых много за пределами первого экрана, и браузер сам решает когда его отрисовать, чтобы отрисовка стала быстрее и нагрузка на процессор не выросла.Пользоваться свойством нужно осторожно, так как его использование может вызывать CLS. Чтобы этого не происходило, указываете
contain-intrinsic-size в размер элемента. Это как отложенная загрузка изображений, только стилизация целых блоков. Крайне эффективно работает для повторяющихся элементов с большим числом потомков. А если у вас на странице есть бесконечная прокрутка, то свойство просто must have. Начинать использовать можно уже сейчас, потому что самое страшное что может случиться, оно просто не сработает в неподдерживаемых браузерах.
⚠️ Помните, однако, что content-visibility может странно повлиять на position: fixed внутри элементов. Как-то раз очень долго не мог отловить ошибку, когда внутри content-visibility в попапе ехала верстка. Решилось вынесением из элемента попапа выше по DOM.
💬 А вы используете
content-visibility?👍21🔥4👏2❤1
❗️ Совсем недавно я писал #lifehack про пагинацию, сегодня расскажу про другой функционал который можно оптимизировать таким же образом. Кнопка "добавить в корзину", или "добавить в избранное" - любые интерактивные элементы, которые не зависят от ответа сервера.
Рассмотрим для примера как реализуют корзину. Запрос на сервер, в ответ приходит количество товаров в корзине, возможно их список и их суммарная стоимость, затем вывод этих данных где-то рядом с кнопкой корзины. Большинство CMS действительно необходимо привязать объект к сессии, для того, чтобы вывести добавленный товар на специальной странице и добавить на этот товар резерв. Но зачем пользователю об этом знать и ждать этого ответа?
Мы уже знаем что выведено на frontend, просто суммируем к содержимому корзины стоимость добавленного товара и увеличиваем количество. Сам запрос может выполняться в фоне, а все данные для пользователя можно показать мгновенно. После обновления всех переменных в интерфейсе мы отправляем запрос в корзину и когда приходит ответ, если возвращаемые значения отличаются от текущих, меняем их в интерфейсе. Если используются современные фреймворки, типа vue, react, angular, svelte, то все еще проще, все запросы станут фоновыми, и добавится динамический компонент ошибки, который отображается только в случае этой ошибки.
Но как быть, если у пользователя пропал интернет, и на самом деле товары не добавляются? Да просто же! В случае ошибки XHR-запроса выводим об этом информацию для пользователя (проблемы с интернетом, товар закончился) и отнимаем последние измененные значения от того, что у нас получилось, или просто отменяем последние действия, предварительно сохраняя в памяти старые значения.
⚠️ Кажется, что это много действий, которые не нужны, однако отзывчивость станет просто мгновенной. Показ загрузки пользователю даже на пару секунд - это время для сомнения. Давайте уберем это время.
💬 А какие хитрости используете вы, чтобы пользователь меньше ждал?
Рассмотрим для примера как реализуют корзину. Запрос на сервер, в ответ приходит количество товаров в корзине, возможно их список и их суммарная стоимость, затем вывод этих данных где-то рядом с кнопкой корзины. Большинство CMS действительно необходимо привязать объект к сессии, для того, чтобы вывести добавленный товар на специальной странице и добавить на этот товар резерв. Но зачем пользователю об этом знать и ждать этого ответа?
Мы уже знаем что выведено на frontend, просто суммируем к содержимому корзины стоимость добавленного товара и увеличиваем количество. Сам запрос может выполняться в фоне, а все данные для пользователя можно показать мгновенно. После обновления всех переменных в интерфейсе мы отправляем запрос в корзину и когда приходит ответ, если возвращаемые значения отличаются от текущих, меняем их в интерфейсе. Если используются современные фреймворки, типа vue, react, angular, svelte, то все еще проще, все запросы станут фоновыми, и добавится динамический компонент ошибки, который отображается только в случае этой ошибки.
Но как быть, если у пользователя пропал интернет, и на самом деле товары не добавляются? Да просто же! В случае ошибки XHR-запроса выводим об этом информацию для пользователя (проблемы с интернетом, товар закончился) и отнимаем последние измененные значения от того, что у нас получилось, или просто отменяем последние действия, предварительно сохраняя в памяти старые значения.
⚠️ Кажется, что это много действий, которые не нужны, однако отзывчивость станет просто мгновенной. Показ загрузки пользователю даже на пару секунд - это время для сомнения. Давайте уберем это время.
💬 А какие хитрости используете вы, чтобы пользователь меньше ждал?
👍13🔥7👏2
❗️ Часто встречается ситуация, когда в JS нужно выполнить много тяжелых операций, и показатель #TBT от этого будет расти. Современный JS позволяет начать выполнение следующей операции только когда предыдущая завершена и основной поток свободен для новых задач.
Знакомьтесь - requestIdleCallback метод, который позволяет выполнять операции во время простоя браузера, только когда основной поток свободен и новая задача минимально повлияет на быстродействие. Метод достаточно старый, но поддержка браузерами, не очень большая, на момент написания поста 78.33%. Но не переживайте полифилл очень простой и его можно просто включать в ваш код.
Если браузер не поддерживает requestIdleCallback, то функция просто выполнится по таймауту.
Как пользоваться этим методом.
timeout - время в миллисекундах через которое функция будет выполнена безусловно, даже если основной поток загружен и выполнение приведет к падению быстродействия. Если не указывать, то метод всегда будет ждать свободного времени для выполнения.
⚠️ Помните, это не волшебная кнопка и если просто обернуть в этот метод весь ваш js код, то разницы в быстродействии не будет, нужно логически разбивать код на блоки, выполнение которых не зависит друг от друга, тогда будет видна разница в быстродействии. И интерфейсные вещи первого экрана (события на кнопки и тд) лучше не откладывать, чтобы не понижать отзывчивость вашего сайта.
💬 А вы используете этот метод в своей работе?
Знакомьтесь - requestIdleCallback метод, который позволяет выполнять операции во время простоя браузера, только когда основной поток свободен и новая задача минимально повлияет на быстродействие. Метод достаточно старый, но поддержка браузерами, не очень большая, на момент написания поста 78.33%. Но не переживайте полифилл очень простой и его можно просто включать в ваш код.
if (!window.requestIdleCallback) {
window.requestIdleCallback = (func, options) => { options = options || {};
setTimeout(func, options.timeout || 1);
}
}Если браузер не поддерживает requestIdleCallback, то функция просто выполнится по таймауту.
Как пользоваться этим методом.
requestIdleCallback(() => {
// Ваш код
}, {timeout: 1000});timeout - время в миллисекундах через которое функция будет выполнена безусловно, даже если основной поток загружен и выполнение приведет к падению быстродействия. Если не указывать, то метод всегда будет ждать свободного времени для выполнения.
⚠️ Помните, это не волшебная кнопка и если просто обернуть в этот метод весь ваш js код, то разницы в быстродействии не будет, нужно логически разбивать код на блоки, выполнение которых не зависит друг от друга, тогда будет видна разница в быстродействии. И интерфейсные вещи первого экрана (события на кнопки и тд) лучше не откладывать, чтобы не понижать отзывчивость вашего сайта.
💬 А вы используете этот метод в своей работе?
👍14👏2❤1🔥1🤯1
⁉️ В чем отличия preload, prefetch, preconnect, dns-prefetch, prerender и как они работают? Если мы говорим про скорость сайтов, то нельзя не упомянуть об этих техниках. Бывают случаи, когда просто удаление нескольких прелоадов или преконнектов из кода страницы уже дает прирост скорости. Давайте разбираться, почему. Для начала коротко о каждом.
Этим тегом мы говорим браузеру, что уже прямо сейчас нам понадобится стиль style.css, и нужно немедленно их загрузить, не дожидаясь события load всей страницы с наивысшим приоритетом. Часто это снимает блокировку отрисовки, так как стили оказываются уже загружены, когда парсинг html-документа завершен.
⛔️ Частая ошибка: загружать огромное число ресурсов, что в итоге замедляет загрузку всей страницы. Не рекомендуется использовать со сторонними доменами, так как придется устанавливать соединение, а как вы уже знаете, это самая ресурсоемкая операция и можно потерять до 500мс на каждый коннект. Еще одна ошибка - выполняется загрузка ресурсов, которых нет на странице. Тут очевидно, лишний трафик с повышенным приоритетом замедлит отображение.
Благодаря ему браузер как и в случае с preload может установить соединение еще до окончания парсинга документа, что ускоряет первое обращение к ресурсу с этого домена. Для чего использовать: У вас есть отдельный домен с api, или статикой, которые невозможно перенести на основной домен даже проксированием, например из-за сложной архитектуры проекта. В этом случае использовать preconnect можно и нужно.
⛔️ Частая ошибка: использовать для всех внешних ресурсов на странице, включая яндекс-метрику, пиксели ретаргетинга, вернее домены, где лежат их скрипты. В особенных случаях можно найти все внешние подключения и даже больше внутри этих тегов. Еще одна ошибка - устанавливать соединение с доменами, которые не понадобятся на этой странице вообще, или понадобятся далеко не сразу.
Текущую страницу он не ускоряет, но позволяет в фоне, после окончания всех операций в основном потоке или между ними загрузить ресурс и сохранить его в кэше. Например человеку при заходе на листинг товаров можно выполнить prefetch стилей для карточки товаров, потому что вероятность того, что он туда перейдет высокая. Если использовать ресурсы текущей страницы, то скорее всего ничего не изменится, если только они не вызываются по клику на кнопку при помощи js, тогда использование тега обосновано.
⛔️ Частая ошибка: использовать этот тег вместо preload. Загрузка не ускорится и приоритет не повысится, а значит текущая страница не ускорится.
⬇️⬇️⬇️ продолжение
<link rel="preload" as="style" href="style.css">Этим тегом мы говорим браузеру, что уже прямо сейчас нам понадобится стиль style.css, и нужно немедленно их загрузить, не дожидаясь события load всей страницы с наивысшим приоритетом. Часто это снимает блокировку отрисовки, так как стили оказываются уже загружены, когда парсинг html-документа завершен.
⛔️ Частая ошибка: загружать огромное число ресурсов, что в итоге замедляет загрузку всей страницы. Не рекомендуется использовать со сторонними доменами, так как придется устанавливать соединение, а как вы уже знаете, это самая ресурсоемкая операция и можно потерять до 500мс на каждый коннект. Еще одна ошибка - выполняется загрузка ресурсов, которых нет на странице. Тут очевидно, лишний трафик с повышенным приоритетом замедлит отображение.
<link rel="preconnect" href="https://perfscan.ru">Благодаря ему браузер как и в случае с preload может установить соединение еще до окончания парсинга документа, что ускоряет первое обращение к ресурсу с этого домена. Для чего использовать: У вас есть отдельный домен с api, или статикой, которые невозможно перенести на основной домен даже проксированием, например из-за сложной архитектуры проекта. В этом случае использовать preconnect можно и нужно.
⛔️ Частая ошибка: использовать для всех внешних ресурсов на странице, включая яндекс-метрику, пиксели ретаргетинга, вернее домены, где лежат их скрипты. В особенных случаях можно найти все внешние подключения и даже больше внутри этих тегов. Еще одна ошибка - устанавливать соединение с доменами, которые не понадобятся на этой странице вообще, или понадобятся далеко не сразу.
<link rel="prefetch" as="image" href="image.jpg">Текущую страницу он не ускоряет, но позволяет в фоне, после окончания всех операций в основном потоке или между ними загрузить ресурс и сохранить его в кэше. Например человеку при заходе на листинг товаров можно выполнить prefetch стилей для карточки товаров, потому что вероятность того, что он туда перейдет высокая. Если использовать ресурсы текущей страницы, то скорее всего ничего не изменится, если только они не вызываются по клику на кнопку при помощи js, тогда использование тега обосновано.
⛔️ Частая ошибка: использовать этот тег вместо preload. Загрузка не ускорится и приоритет не повысится, а значит текущая страница не ускорится.
⬇️⬇️⬇️ продолжение
👍16🔥2👏2
⬆️⬆️⬆️ начало поста
Как и preconnect, только как такового соединения не происходит, исключительно резолвинг dns. Если не используете preconnect, то dns-prefetch может ускорить установку этого соединения. Используется если неизвестно, понадобится ли соединение, но если понадобится, то мы точно знаем что dns-запрос уже выполнен.
⛔️ Частая ошибка: как и в preconnect - большое число запросов к днс снизит общую производительность вашего сайта.
Говорит браузеру открыть невидимую вкладку и загрузить страницу, выполнить все скрипты, и загрузить все ресурсы. Очень интересное свойство, которое позволяет значительно ускорить переход между страницами. Поддержка этого свойства оставляет желать лучшего всего 75.36% на момент написания поста. Однако в Google Chrome следующую страницу можно показать почти моментально. Очень перспективно, но нельзя полагаться на него из-за низкой поддержки. Добавлять тег можно только если вы точно знаете, какая будет следующая страница у человека. Грузить первую из ссылок не эффективно, а грузить все ссылки опасно для быстродействия.
⛔️ Частая ошибка: Делать prerender нескольких старниц, так как в фоне будет запущена вся страница. Еще одна ошибка - думать что ты лучше пользователя знаешь куда он перейдет. Может и никуда, но мы ему уже выполнили что-то там в фоне без его ведома.
💬 Напишите, не повторяете ли вы ошибки, которые описаны выше?
update: Почему-то нет комментариев у последнего поста. Можете писать и задавать вопросы в предыдущем.
<link rel="dns-prefetch" href="https://perfscan.ru">Как и preconnect, только как такового соединения не происходит, исключительно резолвинг dns. Если не используете preconnect, то dns-prefetch может ускорить установку этого соединения. Используется если неизвестно, понадобится ли соединение, но если понадобится, то мы точно знаем что dns-запрос уже выполнен.
⛔️ Частая ошибка: как и в preconnect - большое число запросов к днс снизит общую производительность вашего сайта.
<link rel="prerender" href="https://perfscan.ru/static/gallery/">Говорит браузеру открыть невидимую вкладку и загрузить страницу, выполнить все скрипты, и загрузить все ресурсы. Очень интересное свойство, которое позволяет значительно ускорить переход между страницами. Поддержка этого свойства оставляет желать лучшего всего 75.36% на момент написания поста. Однако в Google Chrome следующую страницу можно показать почти моментально. Очень перспективно, но нельзя полагаться на него из-за низкой поддержки. Добавлять тег можно только если вы точно знаете, какая будет следующая страница у человека. Грузить первую из ссылок не эффективно, а грузить все ссылки опасно для быстродействия.
⛔️ Частая ошибка: Делать prerender нескольких старниц, так как в фоне будет запущена вся страница. Еще одна ошибка - думать что ты лучше пользователя знаешь куда он перейдет. Может и никуда, но мы ему уже выполнили что-то там в фоне без его ведома.
💬 Напишите, не повторяете ли вы ошибки, которые описаны выше?
update: Почему-то нет комментариев у последнего поста. Можете писать и задавать вопросы в предыдущем.
👍14🔥5👏2
🔆 Помните, когда-то давно были WAP-сайты, которые мы открывали с мобилок с черно-белым экраном и качали картинки с рингтонами? Интересно, довелось ли кому-то из моих подписчиков их разрабатывать? У меня был такой опыт. Почему вспомнил - недавно работал над скоростью AMP-сайта, и это что-то среднее между современным html и WAP-версткой. Чуть больше свободы, но скрипты свои уже не напишешь, теги которых нет в стандарте также не используешь, и все что мы можем сделать - это оптимизировать изображение и уменьшить влияние стороннего кода.
💬 Сегодня пятница, а значит давайте подискутируем, почему получается так, что технология, созданная для ускорения загрузки сайтов по факту грузится дольше, чем оригинальный оптимизированный сайт? Что вы думаете вообще про технологии AMP/Турбо/Instant Article? Это будущее, или очередной тупик, как и WAP?
💬 Сегодня пятница, а значит давайте подискутируем, почему получается так, что технология, созданная для ускорения загрузки сайтов по факту грузится дольше, чем оригинальный оптимизированный сайт? Что вы думаете вообще про технологии AMP/Турбо/Instant Article? Это будущее, или очередной тупик, как и WAP?
👍7🔥3👏2
❗️ Сегодня расскажу про CDN: нужно ли подключать, как выбрать, и как подключать правильно. CDN - Content Delivery Network (сеть доставки контента), это когда контент доставляется пользователю с ближайшего к нему сервера, что снижает пинг и RTT, и как следствие ускоряет загрузку.
❓ А нужен ли сайту CDN? Чтобы понять это, достаточно ответить на три вопроса:
1. Мои клиенты из разных городов/стран?
2. Есть ли посещаемость за пределами одного города?
3. Много ли приносят денег посетители из других регионов.
⚠️ Если на 1 вопрос ответ "нет", то достаточно разместить сайт на хостинге в пределах вашего региона, чтобы посетители получили ускорение загрузки. Если же ответ "да" на все три вопроса, то можно попробовать подключить CDN в режиме тестирования и проверить, как изменится конверсия и скорость загрузки сайта из других регионов.
⬇️⬇️⬇️ продолжение
❓ А нужен ли сайту CDN? Чтобы понять это, достаточно ответить на три вопроса:
1. Мои клиенты из разных городов/стран?
2. Есть ли посещаемость за пределами одного города?
3. Много ли приносят денег посетители из других регионов.
⚠️ Если на 1 вопрос ответ "нет", то достаточно разместить сайт на хостинге в пределах вашего региона, чтобы посетители получили ускорение загрузки. Если же ответ "да" на все три вопроса, то можно попробовать подключить CDN в режиме тестирования и проверить, как изменится конверсия и скорость загрузки сайта из других регионов.
⬇️⬇️⬇️ продолжение
👍8🔥4👏2
⬆️⬆️⬆️ начало поста
❗️ При выборе CDN обязательно проверяйте регионы присутствия, если вы подключите CloudFlare или любой другой иностранный сервис к сайту, у которого посетители только из одной страны, то прироста за счет сети не будет, так как в каждой стране присутствует максимум 1-2 сервера, и разницы будет не видно. Если конечно вы не планируете использовать автоматическую оптимизацию от сервиса. Про это поговорим в отдельном посте. Выбирайте CDN с максимальным присутствие в вашей стране, чтобы было покрыто максимальное число городов и регионов, где находятся ваши клиенты. Если информации о покрытии нет на сайте, то ее следует запросить перед покупкой.
Основные ошибки при подключении CDN - использовать отдельный домен для статики. Я почти в каждом посте повторяю, что установка соединения - самая ресурсоемкая операция, поэтому проксировать нужно весь домен. Если не выполнить это правило, то сайт может не просто не ускориться, а даже замедлиться.
У всех CDN есть правила настройки кэширования, тогда вы сможете управлять какой контент стоит кэшировать и на сколько. Управлять кэшем CDN проще всего через HTTP-заголовки, которые передает ваш сервер и указывать для динамики запрет кэширования, а для статики полный кэш навсегда. Если есть возможность настройки в самом кабинете CDN, то смотрите, какие оптимизации делает CDN, и для начала не включайте никакие - замерьте скорость. Возможно, внутренние оптимизации CDN помогут еще ускорить ваш сайт и отказаться от рутины в ускорении.
Например сервис W.tools (внимание, реф-ссылка) может выполнять базовые оптимизации, сжимать изображения, конвертировать в webp, использовать 0-RTT и другие современные фишки, которые можно настроить на стороне сервера.
⚠️ Не стоит сразу бежать и платить, именно за этот или любой другой сервис вам он может не подойти, обязательно все взвешивайте и просчитывайте, и кроме этого общайтесь с поддержкой. У многих сервисов есть тестовый период, если нет, то никто не мешает спросить в поддержке, многие сервисы очень часто идут на встречу.
💬 Был ли у вас опыт использования CDN? Расскажите, какой сервис используете, и каких результатов добились?
update: Снова какая-то проблема с комментариями. Можете писать и задавать вопросы в предыдущем посте.
❗️ При выборе CDN обязательно проверяйте регионы присутствия, если вы подключите CloudFlare или любой другой иностранный сервис к сайту, у которого посетители только из одной страны, то прироста за счет сети не будет, так как в каждой стране присутствует максимум 1-2 сервера, и разницы будет не видно. Если конечно вы не планируете использовать автоматическую оптимизацию от сервиса. Про это поговорим в отдельном посте. Выбирайте CDN с максимальным присутствие в вашей стране, чтобы было покрыто максимальное число городов и регионов, где находятся ваши клиенты. Если информации о покрытии нет на сайте, то ее следует запросить перед покупкой.
Основные ошибки при подключении CDN - использовать отдельный домен для статики. Я почти в каждом посте повторяю, что установка соединения - самая ресурсоемкая операция, поэтому проксировать нужно весь домен. Если не выполнить это правило, то сайт может не просто не ускориться, а даже замедлиться.
У всех CDN есть правила настройки кэширования, тогда вы сможете управлять какой контент стоит кэшировать и на сколько. Управлять кэшем CDN проще всего через HTTP-заголовки, которые передает ваш сервер и указывать для динамики запрет кэширования, а для статики полный кэш навсегда. Если есть возможность настройки в самом кабинете CDN, то смотрите, какие оптимизации делает CDN, и для начала не включайте никакие - замерьте скорость. Возможно, внутренние оптимизации CDN помогут еще ускорить ваш сайт и отказаться от рутины в ускорении.
Например сервис W.tools (внимание, реф-ссылка) может выполнять базовые оптимизации, сжимать изображения, конвертировать в webp, использовать 0-RTT и другие современные фишки, которые можно настроить на стороне сервера.
⚠️ Не стоит сразу бежать и платить, именно за этот или любой другой сервис вам он может не подойти, обязательно все взвешивайте и просчитывайте, и кроме этого общайтесь с поддержкой. У многих сервисов есть тестовый период, если нет, то никто не мешает спросить в поддержке, многие сервисы очень часто идут на встречу.
💬 Был ли у вас опыт использования CDN? Расскажите, какой сервис используете, и каких результатов добились?
update: Снова какая-то проблема с комментариями. Можете писать и задавать вопросы в предыдущем посте.
👍9🔥4👏2🤔1
❗️ На прошлой неделе делал технический аудит сайту, который очень долго загружался. Знаете в чем оказалась причина? В пикселе ретарегета, заблокированного на территории РФ. Просто убрали подключение сервиса, которым кстати никто не пользовался сразу после блокировки, но с сайта конечно не убрали.
Проблема оказалась в том, что на сайта стояла заглушка при загрузке (про них, кстати, будет отдельный пост - то еще зло для производительности), которая пропадала на событие load у window. Никогда так не делайте. Особенно, если подключается сторонний синхронный код, работоспособность которого вы не можете гарантировать.
Некоторые провайдеры не режут соединение и событие error не срабатывает, а ресурсы с заблокированных доменов грузятся бесконечно, пока не сработает timeout в браузере. Здесь мы также бессильны, если только не писать свой worker для того, чтобы разрывать соединение, или возвращать заглушку, если загрузка не произошла за первые секунды.
Проверьте прямо сейчас консоль вашего сайта, возможно там куча ошибок о безопасном соединении, которые возникают, если провайдер просто рвет соединение с заблокированным хостом. Если есть - задумайтесь нужны ли вам эти сервисы и если нужны, подключайте их в зависимости от географии пользователя.
⚠️ Еще одна причина проверить сторонний код - это сторонние сервисы, которыми вы не пользуетесь, и которые могут быть заброшенными, а как следствие после истечения домена злоумышленник может перекупить его и загрузить на ваш сайт по старой ссылке вредоносный код. Поверьте, это происходит регулярно.
💬 А вы убираете код с сайта после блокировки его домена в вашей стране?
Проблема оказалась в том, что на сайта стояла заглушка при загрузке (про них, кстати, будет отдельный пост - то еще зло для производительности), которая пропадала на событие load у window. Никогда так не делайте. Особенно, если подключается сторонний синхронный код, работоспособность которого вы не можете гарантировать.
Некоторые провайдеры не режут соединение и событие error не срабатывает, а ресурсы с заблокированных доменов грузятся бесконечно, пока не сработает timeout в браузере. Здесь мы также бессильны, если только не писать свой worker для того, чтобы разрывать соединение, или возвращать заглушку, если загрузка не произошла за первые секунды.
Проверьте прямо сейчас консоль вашего сайта, возможно там куча ошибок о безопасном соединении, которые возникают, если провайдер просто рвет соединение с заблокированным хостом. Если есть - задумайтесь нужны ли вам эти сервисы и если нужны, подключайте их в зависимости от географии пользователя.
⚠️ Еще одна причина проверить сторонний код - это сторонние сервисы, которыми вы не пользуетесь, и которые могут быть заброшенными, а как следствие после истечения домена злоумышленник может перекупить его и загрузить на ваш сайт по старой ссылке вредоносный код. Поверьте, это происходит регулярно.
💬 А вы убираете код с сайта после блокировки его домена в вашей стране?
👍15🔥3👏2🤯1
❗️ В прошлом посте я обещал рассказать, почему не стоит использовать заглушки до события onload. Все просто, первая отрисовка будет быстрее, а вот LCP-элемент появится гораздо медленнее.
Допустим, LCP-элементом является картинка на первом экране, и кроме нее грузятся еще и javascript файлы, и другие изображения и шрифты. LCP-элемент по факту грузится под такой заглушкой, и даже если он загрузится быстро, то пользователь его не увидит до момента, пока заглушка не исчезнет. Хуже может быть только если скрытие этой заглушки происходит с анимацией, допустим 500 миллисекунд. Таким образом, вы отложите появление LCP-элемента еще и на время анимации.
Чаще всего за такой заглушкой скрывают подгрузку стилей или SPA-приложения, но нужно не скрывать, а работать над визуальной стабильностью, лучше выделить critical-css, чтобы картинка не прыгала во время подгрузки, и необходимость в заглушке отпадет.
Но как же быть в SPA-приложении? Там вместо стандартной заглушки с крутилкой и надписью "подождите", лучше использовать skeleton loader, когда заглушка имитирует контент, который появится на странице уже после окончательной подгрузки. Проблему #LCP это не решит, но решит проблему смещения.
⚠️ Правила:
1. Никогда не используйте заглушку контента.
2. Не используйте анимацию, если решили, что первое правило не для вас.
3. Никогда не нарушайте первое правило.
💬 А вы используете заглушки при загрузке?
Допустим, LCP-элементом является картинка на первом экране, и кроме нее грузятся еще и javascript файлы, и другие изображения и шрифты. LCP-элемент по факту грузится под такой заглушкой, и даже если он загрузится быстро, то пользователь его не увидит до момента, пока заглушка не исчезнет. Хуже может быть только если скрытие этой заглушки происходит с анимацией, допустим 500 миллисекунд. Таким образом, вы отложите появление LCP-элемента еще и на время анимации.
Чаще всего за такой заглушкой скрывают подгрузку стилей или SPA-приложения, но нужно не скрывать, а работать над визуальной стабильностью, лучше выделить critical-css, чтобы картинка не прыгала во время подгрузки, и необходимость в заглушке отпадет.
Но как же быть в SPA-приложении? Там вместо стандартной заглушки с крутилкой и надписью "подождите", лучше использовать skeleton loader, когда заглушка имитирует контент, который появится на странице уже после окончательной подгрузки. Проблему #LCP это не решит, но решит проблему смещения.
⚠️ Правила:
1. Никогда не используйте заглушку контента.
2. Не используйте анимацию, если решили, что первое правило не для вас.
3. Никогда не нарушайте первое правило.
💬 А вы используете заглушки при загрузке?
👍15🔥3👏2
❗️ Сегодня я расскажу в чем проблема библиотек слайдеров на 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, чтобы поделиться с вами.
💬 Пишите коммент, и ставьте лайк, если нужен пример хорошего слайдера, или присылайте свое решение.
1. Стилизация слайдера происходит через классы, которые добавляются только при инициализации. В связи с этим до инициализации страница выглядит совсем по другому, или часть элементов вообще скрыта, зависит от библиотеки и настроек. Это влияет на LCP, если слайдер скрыт, и на CLS, если не заданы размеры. Слайдер изначально развернут, и потом схлопывается до конечных размеров.
2. Слайдер при инициализации вносит изменения в DOM, добавляя классы и элементы, меняя родительские и дочерние элементы. Происходит буквально переверстка страницы, а как следствие ее перерисовка. Это влияет в первую очередь на TBT.
3. При карусели с бесконечной прокруткой, слайдер добавляет клоны предыдущих и следующих элементов, чтобы обеспечить анимацию. Это вызывает лишние перерисовки и раздувает DOM, если внутри содержится сложная верстка.
⚠️ Как сделать свой слайдер без всех этих ошибок? Используйте CSS. Делайте так, чтобы даже с выключенным JS слайдер можно было скроллить при помощи встроенного скролла и свойства scroll-snap-type. Все элементы слайдера формируйте в верстке или на backend, и в js прописывайте только взаимодействие. Например, клики по стрелкам или точкам под слайдером. JS не должен менять структуру DOM без явного взаимодействия с пользователем. Только после клика или свайпа можно добавлять класс, или следующий элемент для плавных анимаций. Внешний вид слайдера не должен отличаться при выключении JS.
Когда-нибудь я напишу пример на чистом JS, чтобы поделиться с вами.
💬 Пишите коммент, и ставьте лайк, если нужен пример хорошего слайдера, или присылайте свое решение.
👍62🔥15👏2🤔1
🎉 Друзья, спасибо вам, нас уже больше 2000 человек, кто интересуется темой производительности сайтов и web-приложений. Всего полтора месяца назад я открыл этот канал для публичного доступа, и вот нас уже больше двух тысяч. Но это только начало, впереди куча идей и постов, которые будут также полезны, или даже полезнее, чем то, что уже опубликовано.
📹 Хочу сделать видео-разбор ваших проектов в прямом эфире, вы бы отправили свой проект на разбор? Или NDA, все дела?
💬 И очень хочу обратной связи по темам постов, про что вы хотите публикации, а может быть и целую новую рубрику?
📹 Хочу сделать видео-разбор ваших проектов в прямом эфире, вы бы отправили свой проект на разбор? Или NDA, все дела?
💬 И очень хочу обратной связи по темам постов, про что вы хотите публикации, а может быть и целую новую рубрику?
🎉25🔥15👏6🥰2
❗️ Все, кто столкнулся с проблемой производительности и начал ее изучать рано или поздно сталкивается с тем, что число прослушивателей событий влияет на быстродействие всего приложения, особенно это касается scroll. Браузер и так его оптимизирует, не отрисовывая контент за пределами экрана, поэтому дополнительные операции и вычисления на это событие очень заметны на медленных устройствах. Все наверное сталкивались, когда скроллишь контент, а там белый экран и спустя время, которое может доходить до 3-5 секунд контент отрисовывается.
В контентных проектах последнее время очень распространен индикатор скролла, чтобы пользователь визуально мог видеть сколько прочитано и сколько осталось прочитать, чтобы оценить свое время. Очень удобно. Но для того, чтобы сделать такой индикатор обычно используют javascript и каждое событие scroll производятся вычисления положения и некоторые математические операции.
Сегодня я предлагаю #nojs способ для реализации подобного функционала. Способ придумал не я, а нашел у пользователя chokcoco. Я адаптировал, протестировал быстродействие и могу 100% рекомендовать данное решение для приложений, так как все вычисления делает браузер, перерисовки не происходит, все работает на нативном свойстве background.
✅ Ссылка на Codepen
💬 Пишите свое мнение по поводу этого решения. И накидайте реакций для поднятия настроения ☺️
В контентных проектах последнее время очень распространен индикатор скролла, чтобы пользователь визуально мог видеть сколько прочитано и сколько осталось прочитать, чтобы оценить свое время. Очень удобно. Но для того, чтобы сделать такой индикатор обычно используют javascript и каждое событие scroll производятся вычисления положения и некоторые математические операции.
Сегодня я предлагаю #nojs способ для реализации подобного функционала. Способ придумал не я, а нашел у пользователя chokcoco. Я адаптировал, протестировал быстродействие и могу 100% рекомендовать данное решение для приложений, так как все вычисления делает браузер, перерисовки не происходит, все работает на нативном свойстве background.
✅ Ссылка на Codepen
💬 Пишите свое мнение по поводу этого решения. И накидайте реакций для поднятия настроения ☺️
🔥28👍11👏2❤🔥1🤯1🤩1
❗️ Немного философии. Знаете ли вы, что весь интернет в среднем ускорится, если со всех сайтов убрать поддержку старых браузеров?
Если отказаться от такой поддежки, то объемы кода сократятся, стандарты начнут развиваться быстрее, вся сфера станет лучше. Даже сборку c ES6 на ES5 можно не делать, так как современные браузеры вполне это поддерживают. Очевидно, что поддерживать браузеры в рамках 2-3 лет нужно, но не более. До сих пор люди заботятся о поддержке интернет эксплорера, хотя даже сам Miсrosoft открестился от него.
Отправка устаревшего кода в браузер означает, что эффективную операцию, которую может выполнить современный браузер, и под выполнение которой он оптимизирован на уровне ядра, переписывают старым кодом, что чаще всего увеличивает сложность алгоритмов. Кроме того, что кода становится гораздо больше, он становится менее эффективным, не всегда, но чаще всего это именно так.
Кроме всего вышеперечисленного, поддержка старых браузеров тормозит переход пользователей на современные версии браузеров, и как следствие хуже весь фронтенд, нет стимула отказываться от поддержки IE11, значит есть посетители с него, которых нужно поддерживать, что отнимает время силы, и деньги у бизнеса.
⚠️ Если вас просят поддерживать сильно старые браузеры, лучше убедить клиента не делать этого, указав на стоимость, и возможности современных браузеров. Максимум можно поставить заглушку со ссылкой на современные версии браузеров. Заказчик может часто ссылаться на то, что в статистике много пользователей с IE11, но чаще всего это оказываются просто боты, которые так представляются.
💬 Напишите свои истории про поддержку старых браузеров, и накидайте реакций, если согласны с тезисом поста.
Если отказаться от такой поддежки, то объемы кода сократятся, стандарты начнут развиваться быстрее, вся сфера станет лучше. Даже сборку c ES6 на ES5 можно не делать, так как современные браузеры вполне это поддерживают. Очевидно, что поддерживать браузеры в рамках 2-3 лет нужно, но не более. До сих пор люди заботятся о поддержке интернет эксплорера, хотя даже сам Miсrosoft открестился от него.
Отправка устаревшего кода в браузер означает, что эффективную операцию, которую может выполнить современный браузер, и под выполнение которой он оптимизирован на уровне ядра, переписывают старым кодом, что чаще всего увеличивает сложность алгоритмов. Кроме того, что кода становится гораздо больше, он становится менее эффективным, не всегда, но чаще всего это именно так.
Кроме всего вышеперечисленного, поддержка старых браузеров тормозит переход пользователей на современные версии браузеров, и как следствие хуже весь фронтенд, нет стимула отказываться от поддержки IE11, значит есть посетители с него, которых нужно поддерживать, что отнимает время силы, и деньги у бизнеса.
⚠️ Если вас просят поддерживать сильно старые браузеры, лучше убедить клиента не делать этого, указав на стоимость, и возможности современных браузеров. Максимум можно поставить заглушку со ссылкой на современные версии браузеров. Заказчик может часто ссылаться на то, что в статистике много пользователей с IE11, но чаще всего это оказываются просто боты, которые так представляются.
💬 Напишите свои истории про поддержку старых браузеров, и накидайте реакций, если согласны с тезисом поста.
👍27🔥8👏2❤1
❗️ Как думаете, какой пейджспид будет у сайта, если его показатель #ttfb равен 5 секунд? Сегодня мы постараемся ответить и экспериментально подтвердить, какое влияние на общий PageSpeed Score оказывает время ответа сервера.
Для начала есть сайт fe-nix.ru который имеет зеленую зону в PageSpeed. Это статика, сделанная 10 лет назад, поэтому с ответом сервера все в порядке. Вот замеры этой страницы. Теперь сделаем полную копию этой страницы, но отроем его через php, с задержкой в 5 секунд. По адресу fe-nix.ru/delay/5/ находится версия этого сайта с задержкой ответа сервера. Вот замеры этой страницы. Как видите, разница небольшая, и отличаются два замера только значением показателя #SpeedIndex, который отличается примерно на время задержки в ответе сервера + погрешность замера.
Теперь переходим в калькулятор значения PageSpeed, и смотрим какое влияние оказывает показатель Speed Index на общую оценку - видим всего лишь 10%. Значит если у нас будет максимальный ответ сервера, мы потеряем всего 10 баллов, но пользоваться сайтом при этом будет почти невозможно. Попробуйте походить по ссылкам.
Специалисты, которые занимаются ускорением сайтов, на ttfb обращают очень мало внимания, из-за небольшого веса этого показателя в оценке PageSpeed. Попробуйте походить по медленному сайту, и скажите, комфортно ли вам пользоваться таким сайтов? Мне - нет, поэтому над ttfb нужно также работать, как и над фронтендом.
💬 А вы обращаете внимание на показатель ttfb? Дайте огня, если считаете, что ttfb важен.
Для начала есть сайт fe-nix.ru который имеет зеленую зону в PageSpeed. Это статика, сделанная 10 лет назад, поэтому с ответом сервера все в порядке. Вот замеры этой страницы. Теперь сделаем полную копию этой страницы, но отроем его через php, с задержкой в 5 секунд. По адресу fe-nix.ru/delay/5/ находится версия этого сайта с задержкой ответа сервера. Вот замеры этой страницы. Как видите, разница небольшая, и отличаются два замера только значением показателя #SpeedIndex, который отличается примерно на время задержки в ответе сервера + погрешность замера.
Теперь переходим в калькулятор значения PageSpeed, и смотрим какое влияние оказывает показатель Speed Index на общую оценку - видим всего лишь 10%. Значит если у нас будет максимальный ответ сервера, мы потеряем всего 10 баллов, но пользоваться сайтом при этом будет почти невозможно. Попробуйте походить по ссылкам.
Специалисты, которые занимаются ускорением сайтов, на ttfb обращают очень мало внимания, из-за небольшого веса этого показателя в оценке PageSpeed. Попробуйте походить по медленному сайту, и скажите, комфортно ли вам пользоваться таким сайтов? Мне - нет, поэтому над ttfb нужно также работать, как и над фронтендом.
💬 А вы обращаете внимание на показатель ttfb? Дайте огня, если считаете, что ttfb важен.
🔥24👍12👏3
❗️ Сегодня короткий пост, но достаточно важный в теме быстродействия. Если ваш сайт не работает без JS, значит его точно можно сделать быстрее: как минимум улучшить #INP и #TBT. Помните, когда я писал про слайдеры я советовал проверять работу сайта без JS. Так вот, это касается всего сайта.
Частая ошибка - это переназначение стандартных элементов. Когда кнопка выполняет функции ссылки, а ссылка кнопки, или обычный div работает как кнопка, или ссылка. JavaScript позволяет это делать с любым элементом: отменить стандартное поведение при помощи preventDefault, и назначить свое. Не все понимают, в чем проблема, пока не отключат JavaScript и не попробуют выполнить какое-то действие на сайте.
⚠️ Я не призываю отказываться от JavaScript на сайте, просто не нужно менять поведение стандартных элементов, если у них есть аналоги. Если хотите перейти на другую страницу, не нужно писать свою реализацию перехода по ссылка на javascript, хотя это и выглядит элементарно. Если нужна ссылка - используйте ссылку. Если нужно отправить данные при клике на кнопку - не нужно писать огромный обработчик, это можно сделать на обычной форме с минимальным написанием кода на JS. Если проектируете свои компоненты, поддержки которых в браузере нет, то сделайте это на наиболее подходящих элементах.
💬 Я знаю, есть примеры, когда без переопределения не обойтись, можете написать о таких в комментарии. Но в большинстве случаев, стоит использовать элементы по прямому назначению.
Частая ошибка - это переназначение стандартных элементов. Когда кнопка выполняет функции ссылки, а ссылка кнопки, или обычный div работает как кнопка, или ссылка. JavaScript позволяет это делать с любым элементом: отменить стандартное поведение при помощи preventDefault, и назначить свое. Не все понимают, в чем проблема, пока не отключат JavaScript и не попробуют выполнить какое-то действие на сайте.
⚠️ Я не призываю отказываться от JavaScript на сайте, просто не нужно менять поведение стандартных элементов, если у них есть аналоги. Если хотите перейти на другую страницу, не нужно писать свою реализацию перехода по ссылка на javascript, хотя это и выглядит элементарно. Если нужна ссылка - используйте ссылку. Если нужно отправить данные при клике на кнопку - не нужно писать огромный обработчик, это можно сделать на обычной форме с минимальным написанием кода на JS. Если проектируете свои компоненты, поддержки которых в браузере нет, то сделайте это на наиболее подходящих элементах.
💬 Я знаю, есть примеры, когда без переопределения не обойтись, можете написать о таких в комментарии. Но в большинстве случаев, стоит использовать элементы по прямому назначению.
👍20🔥8👏2
❗️ Очень часто поступают вопросы про jQuery - можно ли использовать, и как эта библиотека влияет на скорость. Действительно, если вопрос производительности стоит остро, то нужно максимально оптимизировать все, что можно на сайте, в том числе понять, как влияет jQuery, и нужен ли он вообще. Давайте для начала поищем тесты быстродействия jQuery в сравнении с обычным JS.
В 2013 году на хабре вышла статья со сравнением производительности JS-библиотек. По всем результатам jQuery оказался самым медленным. Но это уже старая статья, с того времени вышла куча обновлений. Можно провести тестирование прямо в своем браузере. Переходим по ссылке, нажимаем RUN и ждем результат. Native JS окажется всегда быстрее, и в некоторых случаях разница доходит до 1000 процентов.
Еще одним аргументом в пользу jQuery может стать простота написания кода на нем, но это уже далеко не так. Если не поддерживать старые браузеры, как я советовал ранее, то получится совсем немного больше кода, чем на jQuery, однако если учитывать 89кб - вес самой библиотеки, то разница всегда будет в пользу чистого JS.
⚠️ Если стоит выбор подключать ли jQuery, чтобы сделать ajax запрос, или выполнить простые операции с DOM, то ответом должен быть НЕТ, так как обычный fetch может заменить его даже с бОльшим комфортом, а операции с DOM c появлением querySelector стали много проще, чем раньше.
💬 А вы используете jQuery в своих проектах?
В 2013 году на хабре вышла статья со сравнением производительности JS-библиотек. По всем результатам jQuery оказался самым медленным. Но это уже старая статья, с того времени вышла куча обновлений. Можно провести тестирование прямо в своем браузере. Переходим по ссылке, нажимаем RUN и ждем результат. Native JS окажется всегда быстрее, и в некоторых случаях разница доходит до 1000 процентов.
Еще одним аргументом в пользу jQuery может стать простота написания кода на нем, но это уже далеко не так. Если не поддерживать старые браузеры, как я советовал ранее, то получится совсем немного больше кода, чем на jQuery, однако если учитывать 89кб - вес самой библиотеки, то разница всегда будет в пользу чистого JS.
⚠️ Если стоит выбор подключать ли jQuery, чтобы сделать ajax запрос, или выполнить простые операции с DOM, то ответом должен быть НЕТ, так как обычный fetch может заменить его даже с бОльшим комфортом, а операции с DOM c появлением querySelector стали много проще, чем раньше.
💬 А вы используете jQuery в своих проектах?
👍20🔥6👏2😢1