БлогСфера

От создателя: либо … как я уменьшил время загрузки странички на ~33 с, исправив шрифты.

Некое время вспять я сумел уменьшить время загрузки странички на ~33 секунды, установив порядок загрузки шрифтов. Умопомрачительно, я понимаю! В прошлых попытках следовать передовым практикам я допустил всераспространенную ошибку:

Смотрится нормально, правильно? Я за ранее загружаю файлы шрифтов, чтоб они показывались как можно резвее, а потом выполняю маленькое асинхронное переключение, чтоб предупредить блокировку таблицы стилей правил @font-face. Ну … я попал в ловушку. Подготовительная загрузка 3-х шрифтов означала, что остальные вещи загружались не так стремительно, и это сделалось узеньким местом, которое я не увидел из-за Service Workers либо моего резвого соединения. Потому я удалил все это и возвратился к обыкновенному CSS-шрифту font-display: swap.

CSS @font-face { font-family: «Rubik»; font-display: swap; src: url(«/fonts/rubik.woff2») format(«woff2»), url(«/fonts/rubik.woff») format(«woff»);

}

…

Свойство font-display является необычным новеньким инвентарем, который еще не существовал, когда я в крайний раз работал над своим веб-сайтом. font-display дозволяет мне указать, как и когда я желал бы, чтоб мои шрифты были использованы. Значение swap значит, что мои шрифты будут «переключаться» в вариантах, когда они готовы, не заблокируя загрузку странички, это конкретно то, что я пробовал создать при помощи этого приема отложенной загрузки CSS. Сейчас, когда мои шрифты используются отложено, мне больше не нужна была отдельная таблица стилей.

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

Это все, что необходимо сказать…

Эта история не столько о производительности веб-шрифтов, сколько о другом. Я, Дэйв Руперт, человек, который хлопочет о производительности сети, человек, который читает блоги о производительности сети, человек, который растрачивает много часов, пытаясь не отставать от передовых практик, человек, который вместе организует еженедельный подкаст о разработке веб-сайтов и гласит с специалистами веб-производительности… как-то тупо, что у меня загрузка странички занимала доп 33 СЕКУНДЫ.

Я считаю, что веб-производительность не в особенности сложна, когда вы поймете, какие рычаги можно употреблять; уменьшить количество килобайтов, уменьшить количество запросов, разблокировать рендеринг, отложить скрипты. Но поддержание производительности это совершенно иная история…

С течением времени в любом проекте, над которым я когда-либо работал, начинают появляться неуправляемые причины; TTFB замедляется из-за вашего веб-хостинга, маркетинг просит скриптов отслеживания в Гугл Tag Manager, они демонстрируют, что третьи стороны имеют неспешные посторонние продукты, центральные микропроцессоры имеют суровые уязвимости, устранение технического технических заморочек приводит к задержкам, а браузеры заносят незначимые конфигурации в методы загрузки.

«Рекомендованные практики», по моим ощущениям, изменяются любые 6 ~ 12 месяцев:

«Внедрение preload», разумеется, не масштабировалось для меня.

«Внедрение размытых изображений», может быть, сейчас можно использовать, как «внедрение loading=»lazy»с height и width», но некие люди считают, что loading=»lazy» это очень!

«Созодать {X, Y, Z} для шрифтов» — это бесконечная затея.

«Пакетирование JavaScript» в истинное время преобразуется в «пакет лишь для IE11»…

О, и сейчас вы должны писать весь код, не относящийся к пользовательскому интерфейсу, в workers…

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

Краткий обзор возможностей недавно вышедшего WordPress 5.7

По моему опыту, 99% времени при оптимизацмм веб-производительности сводится к двум дилеммам:

«Вы написали очень много JavaScript»

«У вас есть неоптимизированные изображения»

Что, отлично. Это нормально. JavaScript достаточно сложен для того, чтоб с ним стопроцентно разобраться, и большая часть компаний просто не будут этого созодать. Это плохо для их юзеров, но самооправдание от разрабов — это просто белоснежный шум для меня сейчас. Неувязка с изображениями, но, достаточно всераспространена, и существует три пути ее решения:

Заплатить какому-то сервису.

Придумать какой-либо страшный процесс сборки.

Неизменная внимательность и ручной труд для обеспечения лучшего свойства на кб.

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

Автоматизация неких действий

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

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

Я рассматриваю добавление Lighthouse CI в качестве Github Action. Таковым образом, я мог бы решить делему «неизменной внимательности» и перевести процесс с ручного мониторинга в режим подготовительных извещений о всех регрессах производительности. Также было бы здорово употреблять Lighthouse в качестве плагина Netlify Build, так как я обычно использую Netlify в качестве CI, но я не думаю, что он собирает исторические данные на данном шаге.

Как научить Google использовать ваши description

Иной путь — употреблять что-то вроде SpeedCurve либо Caliber для введения мониторинга. Хотя эти сервисы неплохи, по стоимости они больше подступают для наиболее больших (наиболее конкурентоспособных) компаний, чем мой личный веб-сайт. $ 20 ~ $ 60 за месяц для моего блога будет в 2,5–5 раз больше операционных расходов.

Я также рассматриваю внедрение Thumbor в качестве вида CDN для решения задачи неоптимизированных изображений. Я издавна грезил о том, чтоб иметь возможность без помощи других расположить собственный свой медиа-сервер, который делает всю оптимизацию без утрат и адаптивное сервис (к примеру, WebP, когда поддерживается). Это доп ~5 долл. США (Соединённые Штаты Америки — государство в Северной Америке) за месяц на расходы по обслуживанию Digital Ocean лишь для уменьшения изображений. Я также лишь что вызнал, что Netlify Large Media имеет преобразование изображений, но это просит перехода на GitLFS и, похоже, не он делает адаптивное сервис.

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

Редакция: Команда webformyself.

Источник