Как скачать шрифты Google Fonts

📌 Чтобы скачать шрифты с Google Fonts можно использовать бесплатный инструмент: https://gwfh.mranftl.com/fonts

Переходим, выбираем слева шрифт, и далее выбираем Modern Browsers, чтобы не грузить устаревшие версии файлов шрифтов.

Сервис сгенерирует фрагмент CSS для подключения шрифтов, и скачиваете архив. Используйте из архива только woff2 и woff. Более старые форматы в своей работе уже можно не использовать, убедитесь сами в поддержке: https://caniuse.com/woff2 и https://caniuse.com/woff.

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

📌 Время ответа сервера настолько большая тема, что я думаю, будет не один десяток постов.

Время ответа сервера: Кэширование

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

Отсюда и следуют все возможные оптимизации этого показателя: увеличение мощности сервера, снижение нагрузки, оптимизация ресурсоемких операций, которые выполняются во время загрузки страницы, и также подключение кэширующего CDN.

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

Используйте кэширование. Для начала включите все возможные методы кэширования в самом приложении или CMS, и уже вторым этапом - используйте полностраничный кэш nginx, это будет работать практически из коробки на любом хостинге. Однако помните, что полностраничный кэш nginx убьет всю динамику, которая есть на странице со стороны backend, все пользователи будут видеть одну страницу. Но даже если вы сделаете раздельное кэширование для разных пользователей, то динамика рандомных блоков и подобный функционал будет потерян.

Приведу в пример самую популярную CMS: Wordpress. Пример хорошей отдачи кэша без потери контроля над ним описан у них в статье на официальном сайте: https://wordpress.org/support/article/nginx/ по ссылке есть примеры сразу для нескольких плагинов кэширования.

Для кэширования динамических блоков можно использовать технологию SSI - Server Side Include, Это когда backend отдает части шаблона, а сборку делает уже nginx, собирая частично из закэшированных кусков, частично из динамических. Это хорошее решение для больших и посещаемых проектов, например сайтов СМИ.

❗️ Всегда ориентируйтесь на само приложение, не используйте универсальные советы из интернета, если не уверены на сто процентов, что они вам подходят.

Сжатие изображений на лету

⁉️ Самый частый вопрос, и в то же время, далеко не самый важный - это оптимизация изображений. Многие думают, что это чуть ли не ключевой вопрос, решив который, показатели сразу резко вырастут. Это далеко не так: может улучшиться только если изображение весило 1-2 мегабайта и при этом являлось LCP-элементом. В то же время, ожидать загрузки изображений не хочет никто, даже на медленном интернете.

Самый оптимальный, быстрый и удобный способ без лишней разработки сжать все изображения на сайте - делать это на лету при помощи специальной бесплатной open source утилиты: https://github.com/webp-sh/webp_server_go

Проще всего развернуть такую утилиту при помощи Docker, а файл Docker-Compose можно взять в подробной документации: https://docs.webp.sh/usage/docker/

Самое главное - помните, все изображения, особенно LCP-элементы должны находиться на том же хосте, что и ваш сайт, чтобы не пришлось устанавливать еще одно соединение для загрузки. Проксировать в докер можно все файлы по типам, или какую-то конкретную папку, используя секцию location в nginx. При этом поддерживаемые браузеры будет загружать WebP/AVIF, а неподдерживаемые обычный JPG, однако и он будет также предварительно оптимизирован. Быстро и удобно.

⚠️ Обратите внимание, конвертация в AVIF изначально выключена, чтобы не создавать нагрузку. Можно включить в конфиге всего одной опцией.

Отладка CLS

⚡️ CLS - это смещение контента во время загрузки и использования страницы. Lighthouse и Google PageSpeed Insites показывают смещения, которые происходят на странице в момент ее загрузки. Однако данные в Core Web Vitals попадают за все время, пока пользователь использует страницу. Не всегда понятно, какой DOM-элемент вызывает смещение других элементов на странице после ее загрузки. Для быстрой отладки таких смещений можно использовать простой скрипт, вставив его в консоль браузера:

let cls = 0;
new PerformanceObserver((entryList) => {
for (const entry of entryList.getEntries()) {
if (!entry.hadRecentInput) {
cls += entry.value;
console.log('Current CLS value:', cls, entry);
}
}
}).observe({type: 'layout-shift', buffered: true});

💬 Увидел недавно на одном сайте вот такой фрагмент кода в JS.
А раз это хоть и опосредовано, но касается Performance, то давайте обсудим.

const prefetchPage = e => {
if (e.target.tagName !== "A") {
return;
}
if (e.target.origin !== location.origin) {
return;
}
const removeUrlFragment = url => url.split("#")[0];
if (removeUrlFragment(window.location.href) === removeUrlFragment(e.target.href)) {
return;
}
let l = document.createElement("link");
l.rel = "prefetch";
l.href = e.target.href;
document.head.appendChild(l);
}
document.documentElement.addEventListener("mouseover", prefetchPage, {
capture: true, passive: true
});
document.documentElement.addEventListener("touchstart", prefetchPage, {
capture: true, passive: true
});

❓ Что вы думаете об этом?
❓ Вы бы стали использовать такое решение?

Отложенная загрузка изображений

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

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

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

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

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

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

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

✅ Код на Codepen

Откладываем 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

Мы готовим большой гайд по метрикам Core Web Vitals.

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

❗️ Начинаем сегодня и в течение недели будем публиковать методы улучшения показателей 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, как основной показатель, отвечающий за скорость загрузки.

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

⚠️ Сегодня все внимание на 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. И уже после этого принимать решение, что делать.

🧩 Улучшаем LCP

Если LCP-элементом является изображение, то нужно проверить, не отложено ли оно. Изображения, которые могут являться LCP-элементом ни в коем случае не откладываем. Далее максимально сжимаем это изображение. Для быстрого сжатия воспользуйтесь приложением, о котором мы писали ранее. Обязательно проверьте разрешение изображения. Часто бывает, что на первом экране изображение с зеркалки размером 6000х4000 пикселей, а то и больше, с весом 18 мб. Если его просто сжать и перевести в webp и avif, мы все равно получим 2-4 мегабайта данных, что очень много. Сжимайте изображение так, чтобы оно весило не более 100 кб. Меньше - лучше. Для повышения приоритета загрузки, если на странице много запросов, можно добавить <link rel="preload" as="image" href="/lcp.jpg">.

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

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

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

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

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

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

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

⚠️ Сегодня говорим про 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, и пока стоит ориентироваться на него.

⚠️ Сегодня говорим про 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, и встречается даже у очень быстрых сайтов.

🧩 Давайте рассмотрим основные проблемные моменты, почему они происходят и как их устранить.

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

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

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

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

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

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