задний план
-
产品: Посмотрите, как медленно загружается эта страница, как пользователи могут ею пользоваться? (и скинул мне запись экрана) -
我: (Добавить контрмеры на интерфейсе) Интерфейс должен загружать vue, js, html и css, что требует времени, не так ли? Не говоря уже о запросах интерфейса, запросах к базе данных и выполнении js, все это требует времени, верно? Так что медленная загрузка — это нормально, пусть пользователи используют Wi-Fi. (Эм... ну вот и все...) -
产品: Ваша последняя компания обанкротилась из-за таких отличных сотрудников, как вы, верно? !
Так что я не уверен, давайте сначала посмотрим видео:
Скрестим пальцы, всего 10 секунд, и он вернулся. . . . . . . . . . . . Ладно, ладно, я не могу это исправить.
прелюдия
Если вы хотите попрактиковаться в этом навыке, вы должны сначала отправиться во дворец. Лоб. . неправильно. Чтобы понять производительность, вы должны сначала проанализировать. На рынке есть много видов пакетов медицинского осмотра, но по сути все они меняют суп вместо лекарства. Что такое лекарство (стандартное)? Мы объясним это ниже. Здесь я выбрал собственный сын Google «LightHouse» для проверки работоспособности.
Из вышеизложенного видно, что маяк оценивается по нескольким показателям производительности и разным весам.Эти показатели в основном определяются в соответствии со стандартами PerformanceTiming и PerformanceEntry API.Большинство пакетов медицинского осмотра на рынке также настраиваются на основе эти индикаторы Давайте посмотрим, что означают эти индикаторы.
конкретное значение
FCP (First Contentful Paint)
First Contentful Paint (FCP)Метрики измеряют время, необходимое для отображения любой части содержимого страницы на экране с момента начала загрузки страницы. Для этой метрики «контент» относится к тексту, изображениям (включая фоновые изображения),<svg>элемент или небелый<canvas>элемент.
SI (Speed Index)
Индекс скорости измеряет, насколько быстро контент визуально отображается во время загрузки страницы.
LCP (Largest Contentful Paint)
LCP измеряет, когда самый большой элемент контента в области просмотра отображается на экране. Это примерно то время, когда основной контент страницы виден пользователю.
TTI (Time to Interactive)
TTI измеряет, сколько времени требуется, чтобы страница стала полностью интерактивной. Страница считается полностью интерактивной, если:
- Страницы отображают полезный контент, согласно оценке First Contentful Paint,
- Зарегистрированные обработчики событий для наиболее видимых элементов страницы
- И реакция страницы на взаимодействие с пользователем в течение 50 миллисекунд.
TBT (Total Blocking Time)
Сумма времени, в течение которого основной поток блокируется длительными задачами (более 50 мс) между FCP и TTI.
TBT измеряет общее время, в течение которого страница не реагирует на действия пользователя, такие как щелчки мышью, щелчки экрана или нажатия клавиш. Сумма рассчитывается путем сложения блокирующих частей всех длинных задач, то есть первой отрисовки контента и времени взаимодействия. Любая задача, выполнение которой занимает более 50 мс, является долгой задачей. Время после 50 миллисекунд является блокирующей частью. Например, если Lighthouse обнаружит задачу длительностью 70 миллисекунд, блокирующая часть будет составлять 20 миллисекунд.
CLS (Cumulative Layout Shift)
Совокупное значение смещения макета
FID (First Input Delay)
Измерьте наихудшую задержку первого ввода, с которой могут столкнуться ваши пользователи. Задержка первого ввода измеряет время с момента, когда пользователь впервые взаимодействует с вашим веб-сайтом (например, нажатие кнопки), до момента, когда браузер фактически может реагировать на это взаимодействие.
Результаты физического осмотра
Ха-ха-ха, достойно быть отличным фронтенд-инженером. . . 5 из 6 показателей эффективности.
хирургический план
Предложения по оптимизации
Что ж, прорвемся по одному.
Сокращение времени отклика начального сервера
Вот мой дружеский разговор с бэкендом:
-
我: Интерфейс вашей домашней страницы 2.39s Вы писали интерфейс с закрытыми глазами? -
后端大佬: xxxбип бип бип бип хххх, Я хочу умереть? ! ******xxxxx哔哔哔哔哔哔哔哔哔哔 -
我: Я тоже думаю, что проблема переднего конца, гм, беспокоит. . .
Хорошо, следующая точка оптимизации.
Уменьшите неиспользуемый JavaScript
После анализа я обнаружил, что домашняя страница включает только запросы ресурсов и не требует загрузки библиотеки запросов (наша внутренняя упаковка), в то же время зависимые сторонние библиотеки не требуют долгосрочных обновлений версий, поэтому их не нужно упаковывать в чанки-вендоры. Посмотреть на основеwebpack-bundle-analyzerСоздав отчет об анализе объемов, я нашел два больших продукта, которые можно оптимизировать:
Внутренне упакованная библиотека запросов требует зашифрованных запросов md5 и sha256, в результате чего получается дополнительно 600 КБ упакованных пакетов, поэтому после консультации с лидером было решено переписать пакет с помощью axios.
Vue, Vuex, Vue-маршрутизатор, буфер обмена, Vue-I18n, Tripatte библиотека Axios Загрузить CDN, Home Preload.
После оптимизации объем Bundle (до GIZP) был уменьшен с исходных 841kb до 278kb.
Избегайте использования устаревшего JavaScript в современных браузерах.
Я не придумал хорошей альтернативы, поэтому пока отложил ее.
визуальная стабильность
Оптимизируйте неразмерные элементы изображения
Высокоприоритетная оптимизация, упомянутая в предложениях по улучшению, заключается в том, чтобы задать явную ширину и высоту для элементов изображения, тем самым уменьшив смещения макета и улучшив CLS.
<img src="hello.png" width="640" height="320" alt="Hello World" />
Избегайте смены макета страницы
Заголовок в нашем продукте настраиваемый, и этот заголовок приведет к тому, что общий макет веб-сайта сместится вниз. Это вызывает большое смещение макета. После торговли с продуктом «qs» страница удлиняется, а заголовок фиксируется и позиционируется над потоком текста. .
самый большой элемент контента для рисования
Замените самый большой элемент для рисования содержимого
В предложениях по улучшению я обнаружил, что самым большим элементом отрисовки контента на главной странице является фрагмент текста, что неудивительно, что показатели данных индикатора LCP неудовлетворительны, причина: слишком длинная ссылка - домашняя страница загружает js -> загружает языковой пакет -> отображает текст.
Итак, я решил изменить самый большой элемент рисования контента, чтобы улучшить время LCP.Я взглянул на определение типа элемента в Largest Contentful Paint API и заблокировал «цель» для загружаемого элемента (низкая стоимость рисования: рендеринг по умолчанию , нет Зависит от любых условий и суждений) После того, как я манипулировал размером элемента (увеличил), элемент успешно "масштабировался".
разное
Помимо оптимизации вышеперечисленных индикаторов, я также провел несколько оптимизаций, кратко упомянутых здесь:
- Оптимизация уровня и количества вложенности DOM
- Сокращение ненужных запросов к интерфейсу
- Замените top на translate для перемещения/анимации.
Результаты оптимизации
Эй, отлично, все еще отличный фронтенд-инженер~~~~~хахахахаха
Следующая статья:Как решить проблему, вызванную изменением базового кода