Я дал сайту производительность хирургии

внешний интерфейс оптимизация производительности
Я дал сайту производительность хирургии

предисловие

Ветер и солнце: я смеюсь, хватаю свою крутую клавиатуру ikbc и стучу по жукам как сумасшедший.
Thunderbolt: Меня втянули в группу, и продукт сказал, что сайт, который я сделал, сильно тормозит и нуждается в оптимизации для повышения производительности.
Невероятно: я разработал его с почетным Vue3+Ts (собачья голова с ручным управлением).
Очень стойкий: по принуждению Инь Вэй я провел медицинский осмотр и операцию для веб-сайта.

медицинский осмотр

На рынке есть много видов пакетов медосмотра, но по сути все они меняют суп вместо лекарства. Что такое лекарство (стандартное)? Мы объясним это ниже. Здесь я выбираю Google Pro-Son"Маяк" (Маяк)Выполните проверку производительности.

Стандарт физического осмотра

Почему я говорю, что большинство медосмотров меняют суп вместо лекарства?Начнем с правил начисления очков маяка:

lighthouse-score-calc.png

Из приведенного выше видно, что версия Lighthouse v6/v7 оценивается по нескольким показателям производительности и разным весам, которые в основном основаны наPerformanceTimingа такжеPerformanceEntryОпределены стандарты API.Большинство пакетов медицинских осмотров на рынке также настраиваются на основе этих показателей.Далее давайте разберемся в значении этих показателей.

FCP (First Contentful Paint)

Момент времени, когда был отрендерен первый элемент (текст, изображение, холст...)

SI (Speed Index)

Время отображения первого экрана

LCP (Largest Contentful Paint)

Момент времени для отображения самого большого элемента контента в видимой области.

TTI (Time to Interactive)

Момент времени, когда ресурс страницы успешно загружен и может реагировать на действия пользователя.

TBT (Total Blocking Time)

Сумма времени, в течение которого основной поток блокируется длинной задачей (более 50 мс) между FCP и TTI.

CLS (Cumulative Layout Shift)

Совокупное значение смещения макета

FID (First Input Delay)

Первый раз, когда пользователь взаимодействует со страницей (нажав кнопку, кнопку, пользовательское событие JS) и время, когда браузер на самом деле запускает обработку этого события

Core Web Vitals

Когда дело доходит до пользовательского опыта и показателей производительности, давайте упомянем Core Web Vitals. В мае 2020 года Google запустил набор Core Web Vitals для работы с веб-сайтами, состоящий из трех показателей:

web-vitals.png

Почему бы не использовать другие показатели? Потому что этот набор стандартов в основном оценивается по следующим трем параметрам:

  • [Ситуация загрузки]: LCP
  • [Интерактивность]: FID
  • [Визуальная стабильность]: CLS

Как посмотреть показатели Core Web Vitals?

Разработчики могут использовать следующие инструменты для мониторинга Core Web Vitals:Core-Web-Vitals.webp

Поскольку FID требует взаимодействия с реальным пользователем, его нельзя проверить на экспериментальных данных.Для проверки FID на экспериментальных данных обычно используется TBT (общее время блокировки).Хотя то, что они измеряют, отличается, улучшение TBT обычно улучшает FID, поскольку хорошо. .

Результаты физического осмотра

Не знаю, не знаю ли, но я в шоке, когда проверяю: шесть "жизненно важных органов" наполовину остыли... Пора делать операцию!

Оценка показателя

market-optimize-before.png

Рекомендации по улучшению

improve-advice.png

Операция

хирургический план

Поскольку это хирургия производительности, план в основном основан на показателях производительности как на измерении, которое в основном делится на следующие пункты:

  • Визуальная стабильность (кумулятивный сдвиг макета)
  • Загрузка (наибольшая содержательная краска)
  • TTI (Time to Interactive)
  • TBT (Total Blocking Time)
  • FCP (First Contentful Paint)

хирургическая процедура

Визуальная стабильность (кумулятивный сдвиг макета)

  • Оптимизировать элементы изображений, которые не устанавливают размеры

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

image-size.png

<img src="hello.png" width="640" height="320" alt="Hello World" />
  • Пользовательские файлы шрифтов остаются видимыми во время загрузки

В предложениях по улучшению упоминается использование свойства CSS font-display для обеспечения видимости файлов пользовательских шрифтов во время загрузки.

webfont-load.png

Это связано с тем, что веб-сайтам требуется некоторое время для загрузки файлов пользовательских шрифтов, и разные браузеры в это время ведут себя по-разному.Некоторые браузеры скрывают текст при загрузке пользовательских шрифтов, что называетсяFOIT(Flash Of Invisible Text).И некоторые браузеры будут отображать ухудшенные шрифты, что называетсяFOUT(Flash Of Unstyled Tex).Both из этих поведений может привести к тому, что "шрифт мерцающих проблем" влияет на визуальность (Cls).

Мой подход заключается в том, чтобы напрямую установить font-display: swap; это свойство гарантирует, что шрифт будет виден во время загрузки, хотя по-прежнему вызывает FOUT, но по сравнению с FOIT, влияние FOUT на визуальную стабильность будет меньше.

Лучшее решение — предварительно загрузить файл шрифта.

@font-face {
     font-family: 'Hello-World';
     src: url('../font/Hello-World.otf') format('OpenType');
     /* swap:如果设定的字体还未可用,浏览器将首先使用备用字体显示,当设定的字体加载完成后替换备用字体 */
     font-display:swap;
 }
  • Избегайте смены макета страницы

cls-ele.png

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

  • Избегайте несинтетических анимаций

non-composited-animation.png

В предложении по улучшению упоминалось, что следует избегать использования несинтетической анимации. Несинтетическая анимация сделает страницу загроможденной и повысит CLS. Что касается этого предложения по оптимизации, я думаю, что его следует проанализировать в конкретной сцене, а не " вызвано удушьем». В конце концов, CSS, которые можно компоновать в настоящее время. Свойства — это только преобразование и непрозрачность. Конечно, это также напоминает нам о том, что мы должны уделять внимание оптимизации при выполнении анимации CSS (например, обычное использование преобразования вместо топа).

Загрузка (наибольшая содержательная краска)

  • Замените самый большой элемент для рисования содержимого

В предложениях по улучшению я обнаружил, что самым большим элементом рисования контента на веб-сайте является элемент плитки в Google Maps.Неудивительно, что производительность данных индикатора LCP не идеальна, причина: слишком длинная ссылка - Скачать Google Maps Js sdk => Инициализировать Google Maps => draw .

Итак, я решил изменить самый большой элемент рисования контента, чтобы улучшить время LCP.Largest Contentful Paint APIЧто касается определения типа элемента, «цель» привязана к загружаемому элементу (низкая стоимость прорисовки: рендеринг по умолчанию, не зависит от каких-либо условий и суждений). После того, как я манипулировал размером элемента (увеличил), элемент Удачно "верхний".

TBT (Total Blocking Time) / TTI (Time to Interactive)

  • Асинхронно загружать карты Google Js SDK
    Исходная загрузка Google Maps Js sdk загружается синхронно путем динамического добавления тегов скрипта. Недостатки этого на самом деле очевидны:

    • Google Maps Js sdk загружается слишком поздно, что влияет на производительность TTI и взаимодействие с пользователем.
    • Движок js занимает основной поток для связанного выполнения js.

    Мое решение состоит в том, чтобы загрузить Google Maps Js sdk асинхронно. Здесь следует отметить разницу между скриптом async/defer. Я использую отсрочку для асинхронной загрузки (асинхронность будет выполняться сразу после загрузки, блокируя основной поток и влияя на синтаксический анализ DOM).

    <script
          src="//maps.googleapis.com/maps/api/js"
          type="text/javascript"
          defer
    ></script>
    
  • Оптимизация объема сборки сборки

Посмотреть на основеwebpack-bundle-analyzerСгенерированный отчет об анализе объемов, который я нашел, содержит два больших продукта, которые можно оптимизировать:

    • библиотека анимации Лотти

    На сайте, использующем эту библиотеку, есть только один анимационный эффект.После очередного перекуса с продуктом и пользовательским интерфейсом мы решили немного пожертвовать «визуальным эффектом».Удалим библиотеку lottie и вместо нее используем CSS3.

    • Встроенная зависимость momentjs в ant-design-vue

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

    После оптимизации размер пакета (до gizp) уменьшен с 1,8 МБ до 1,3 МБ.

FCP (First Contentful Paint)

Веб-сайт использует рендеринг на стороне клиента, сделанный Vue. Это также означает, что процесс FCP будет немного «долгим» (ряд задач, таких как инициализация экземпляра Vue, должен занимать основной поток для выполнения Js). Здесь я «умно» добавил его в html-файл «Прозрачный текстовый заполнитель», опережая время FCP. Лично я думаю, что это шоу немного сложно, вы можете выборочно игнорировать его ...

<div id="app">
   <!-- 占位符 -->
   <p style="color:#fff;">Hello World</p>
</div>

разное

В дополнение к оптимизации по вышеуказанным показателям и размерам, я также сделал несколько оптимизаций, которые кратко упомянуты здесь:

  • Оптимизация уровня и количества вложенности DOM
  • Сокращение ненужных запросов к интерфейсу
  • Используйте translate, чтобы заменить top для смещения/анимации

Результат операции

После стольких слов "ерунды", каков результат операции? Великолепная трансформация или "фея обратного дня Q"? Непосредственно выше:

90.png

На приведенной выше картинке мы видим, что все показатели и оценки совершили качественный скачок, хотя я «бессовестно урезал высшую оценку» (оценка LightHouse будет колебаться каждый раз, и фактический эффект будет увеличиваться с первоначальных 50-70 баллов). .до 70-90 баллов)!!!

Эпилог

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

Если вы считаете, что моя статья полезна для вас, добро пожаловатьПодписывайтесь на меняДавай поиграем вместе~