Главная » Статьи » Поддержание производительности

Поддержание производительности

Поддержание производительности

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

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

<link rel="preload" href="/fonts/rubik.woff2"/>
<link rel="preload" href="/fonts/rubik-bold.woff2"/>
<link rel="preload" href="/fonts/domine.woff2"/>
<link rel="stylesheet" href="/css/fonts.css" media="print" onload="this.media='all'">

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

@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 замедляется из-за вашего веб-хостинга, маркетинг требует скриптов отслеживания в Google Tag Manager, они показывают, что третьи стороны имеют медленные сторонние продукты, центральные процессоры имеют серьезные уязвимости, устранение технического технических проблем приводит к задержкам, а браузеры вносят незначительные изменения в алгоритмы загрузки.

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

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

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

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

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

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

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

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

«Вы написали слишком много JavaScript»

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

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

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

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

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

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

Автоматизация некоторых процессов

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

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

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

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

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

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

Источник: https://daverupert.com

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