В течение длительного процесса итерации страницы Penguin Tutoring H5 постепенно накапливались некоторые проблемы с производительностью, что приводило к замедлению загрузки страницы и скорости рендеринга. Чтобы улучшить взаимодействие с пользователем, недавно были сделаны специальные оптимизации для скорости загрузки страниц и скорости рендеринга.Эта статья представляет собой практическое резюме этой оптимизации. Процесс анализа более детализирован, и я надеюсь помочь студентам, которым не хватает опыта анализа производительности.
история проекта
Проект H5 является основным проектом Penguin Tutoring. Он повторялся более четырех лет. Он включает в себя такие страницы, как страница сведений о курсе/страница сведений об учителе/страница регистрации/страница оплаты. Продукты созданы для приложения Penguin Tutoring APP/H5. (WeChat/QQ/Browser) , в процессе итерации накопились некоторые проблемы с производительностью, что привело к замедлению загрузки страниц и скорости рендеринга. Чтобы улучшить взаимодействие с пользователем, недавно был запущен проект «Оптимизация производительности H5», и были проведены специальные оптимизации. была сделана для скорости загрузки страницы и скорости рендеринга.Сводка этой оптимизации включает следующие части.
- Отображение эффекта оптимизации производительности
- Показатели эффективности и сбор данных
- Метод анализа производительности и подготовка среды
- Особая практика оптимизации производительности
1. Показатели эффективности и сбор данных
Показатели эффективности, используемые Penguin Coaching H5, включают:
1. Время загрузки страницы: насколько быстро страница загружается и отображает элементы на странице.
- First contentful paint (FCP): измеряет время, когда страница начинает загружаться до тех пор, пока на ней не отобразится определенный фрагмент контента.
- Largest contentful paint (LCP): измеряет время, в течение которого страница начинает загружаться, пока на странице не отобразится самый большой текстовый блок или изображение.
- Событие DomContentLoaded: время завершения синтаксического анализа DOM
- Событие OnLoad: время завершения загрузки ресурса страницы
2. Время отклика после загрузки: сколько времени требуется странице, чтобы реагировать на действия пользователя после загрузки и выполнения кода js.
- First input delay (FID): Измерьте время от первого взаимодействия пользователя с веб-сайтом (например, нажатия ссылки, кнопки, пользовательского элемента управления js) до фактического ответа браузера.
3. Визуальная стабильность. Будут ли элементы страницы двигаться не так, как ожидает пользователь, и мешать взаимодействию с ним.
- Cumulative layout shift (CLS): измеряет совокупную оценку непредсказуемых изменений макета, происходящих с момента начала загрузки страницы до момента, когда состояние становится скрытым.
Проект использует IMLOG для отчетности данных,Система ELK для мониторинга сетевых данных в реальном времени, представление конфигурации Grafana, наблюдайте за текущей ситуацией в сети.
В соответствии с распределением данных индикаторов можно вовремя обнаружить аномальные данные страницы и принять меры.
2. Анализ производительности и подготовка среды
Текущий статус страницы:
Видно, что индикатор выполнения все еще загружается после отображения страницы, а время загрузки составляет десять секунд, что влияет на взаимодействие с пользователем.
в соответствии сДокументация по разработке GoogleОбъяснение архитектуры браузера:
Когда отправка навигации завершена, процесс рендеринга начинает загрузку ресурсов и рендеринг страницы. Как только процесс рендеринга «завершен», он уведомляет процесс браузера через IPC (обратите внимание, что это происходит для всех кадров на странице).onloadКогда событие было запущено и соответствующий обработчик был выполнен), тогда поток пользовательского интерфейса остановит вращающийся круг на панели навигации.
Мы можем знать, что время загрузки индикатора выполнения тесно связано со временем загрузки.Если индикатор выполнения должен закончиться как можно скорее, время загрузки должно быть уменьшено.
В соответствии со статусом-кво используйте ChromeDevTool в качестве базового инструмента анализа производительности для наблюдения за производительностью страницы.
Сеть: следите за временем и последовательностью загрузки сетевых ресурсов.
Производительность: наблюдайте за производительностью рендеринга страницы и выполнением JS.
Маяк: оцените сайт в целом и найдите вещи для оптимизации
Ниже сСтраница сведений о курсе обучения пингвиновПроведите анализ случая, чтобы определить потенциальные оптимизации
(Обратите внимание на использование окон Chrome в режиме инкогнито и отключение надстроек, чтобы устранить влияние других надстроек на страницу)
1. Сетевой анализ
Обычно для сетевого анализа требуется отключить кеш и включить ограничение скорости сети (4g/3g), чтобы имитировать ситуацию загрузки мобильного терминала в условиях слабой сети, поскольку сеть Wi-Fi может сгладить разрыв в производительности.
Вы можете видеть, что время DOMContentLoaded составляет 6,03 с, но время загрузки составляет 20,92 с.
Сначала наблюдайте за фазой DOMContentLoaded и найдите, чтоСамый длинный путь запроса — в vendor.js, размер JS — 170 КБ, время — 4,32 с.
Продолжайте наблюдать за периодом от DOMContentLoaded до загрузки.
Можно обнаружить, что событие onload блокируется большим количеством медиа-ресурсов.Факторы, влияющие на событие onload, см.эта статья
ВыводБраузер инициирует загрузку, когда ресурс полностью загружен (ресурсы, проанализированные HTML, и динамически загружаемые ресурсы).
Объедините приведенную выше картинкуМожно обнаружить, что загружаются изображения, видео, iFrames и другие ресурсы, что блокирует срабатывание события onload.
Сводка по сети
- На синтаксический анализ DOM влияет загрузка и выполнение JS. Попробуйте сжать и разделить JS (под HTTP2), чтобы сократить время DOMContentLoaded.
- Картинки, видео, iFrames и другие ресурсы будут блокировать срабатывание события onload.Необходимо оптимизировать время загрузки ресурсов и запускать onload как можно раньше.
2. Анализ производительности
Используйте производительность для моделирования мобильного терминала.Обратите внимание, что мощность процессора мобильного телефона хуже, чем у ПК, поэтому обычно устанавливайте замедление процессора в 4 или 6 раз для моделирования.
Соблюдайте несколько основных данных
- Web Vitals (FP / FCP / LCP / Layout Shift) Метрики основной страницы и сроки Продолжительность
Видно, что LCP, DCL и Onload Event занимают много времени, и есть много смен макета.
Чтобы активировать LCP как можно раньше, нужно сократить время рендеринга крупных элементов на странице, наблюдать за скриншотами фреймов или скриншотов и обращать внимание на рендеринг элементов на странице.
Конкретное содержимое смещения можно найти на панели «Сводка», щелкнув «Сдвиг макета» в строке «Опыт».
- Основные длинные задачи Количество и продолжительность длинных задач
Видно, что на странице большое количество длинных задач, которые необходимо оптимизировать, а время парсинга и выполнения couse.js (кода страницы) составляет целых 800 мс.
При работе с длинными задачами вы можете записывать в среде разработки, чтобы видеть конкретный файл выполнения кода и время использования на основной временной шкале.
Сводка производительности
- Время запуска LCP страницы задерживается, и есть несколько смещений макета, что влияет на взаимодействие с пользователем. Необходимо как можно быстрее отобразить контент и уменьшить смещение макета.
- На странице много длинных задач, и JS необходимо разделить и загрузить разумно, чтобы уменьшить количество длинных задач, особенно задач, которые влияют на DCL и событие загрузки.
3. Анализ маяка
Используйте встроенный маяк ChromeDevTool для оценки страницы.
Оценка низкая. Вы можете видеть, что Metrics дает основные показатели данных. Здесь это показывает, что TTI SI TBT не соответствует требованиям, LCP нуждается в улучшении, FCP и CLS достигли хороших стандартов, вы можете просмотретьСтандарт расчета баллов
В то же время маяк предоставит некоторые предложения по оптимизации.В возможностях и диагностике вы можете увидеть конкретные руководства по работе, такие как размер изображения, удаление бесполезного JS и т. д. Вы можете оптимизировать проект в соответствии с руководством.
Оценка контента маяка основана на общей загрузке проекта.Рассмотренные проблемы также включают содержание сети и производительности, поэтому его также можно рассматривать как предложение по оптимизации для проблем сети и производительности.
Резюме маяка
- По баллам видно, что четыре показателя TTI, SI, TBT и LCP нуждаются в улучшении.документация маякаоптимизировать.
- Возможности и диагностика предоставляют конкретные предложения по оптимизации, которые вы можете использовать для улучшения.
4. Подготовка окружающей среды
Сейчас идет предварительный анализ проблемы на веб-странице в Интернете, и нам нужно ее оптимизировать и наблюдать за ней.Необходимо смоделировать среду, чтобы эффект оптимизации мог более реалистично отразиться в тестовой среде.
Использование прокси: свисток, чарльз, скрипач и т. д.
Локальная среда, имитация тестовой среды: nginx, nohost, stke и т.д.
Отчетность по данным: IMLOG, TAM, RUM и т. д.
Внешний анализ упаковки кода: webpack-bundle-analyzer, rollup-plugin-visualizer и т. д.
Используйте локальный код при анализе проблем, локально моделируйте онлайн-среду, чтобы проверить эффект оптимизации, и, наконец, разверните его в тестовой среде для проверки, чтобы повысить эффективность разработки.
В-третьих, конкретная практика оптимизации производительности
ЧАСТЬ 1. Оптимизация времени загрузки
Классифицировать ресурсы, загруженные на страницу в Сети
Первая часть — это ресурсы JS, влияющие на синтаксический анализ DOM.Вы можете видеть, что они подразделяются на критические JS и некритические JS в соответствии сУчаствовать ли в отделе рендеринга первой стороны
Для некритических JS здесь мы можем рассмотреть отложенную асинхронную загрузку, а критические JS разделены и оптимизированы.
1. Ключевая оптимизация упаковки JS
Количество файлов JS — 8, общий объем — 460,8 КБ, а самый большой файл — 170 КБ.
1.1 Правильная настройка сплитчанков
vendor.js 170 КБ (gzipd) — это общий файл, который будут загружаться все страницы, и правила упаковкиminiChunks: 3, модули, на которые ссылаются более 3 раз, будут введены в этот js
Проанализируйте конкретный состав vendor.js (выше)
В качестве примера возьмем string-strip-html.umd.js, размер которого составляет 34,7 КБ, что составляет 20% от объема vendor.js, ноТолько одна страница использует этот пакет несколько раз, что приводит к срабатыванию правила miniChunks., был оценен в vendor.js.
Точно так же при анализе других модулей vendor.js такие модули, как iosSelect.js, howler.js и weixin-js-sdk, имеют только 3 или 4 зависимости страниц/компонентов, но они также включены в vendor.js.
Из приведенного выше анализа мы можем сделать следующие выводы:Вы не можете просто полагаться на правила miniChunks для извлечения и упаковки модулей, зависящих от страницы, но разделяете общедоступные зависимости в соответствии с конкретными обстоятельствами.
Модифицированный поставщик извлекает общие зависимости (imutils/imlog/qqapi) различных страниц и компонентов в соответствии с конкретными потребностями бизнеса.
vendor: {
test({ resource }) {
return /[\\/]node_modules[\\/](@tencent\/imutils|imlog\/)|qqapi/.test(resource);
},
name: 'vendor',
priority: 50,
minChunks: 1,
reuseExistingChunk: true,
},
Для других неуказанных общедоступных зависимостей добавьте файл common.js, увеличьте пороговое значение до 20 или выше (текущее количество страниц — 76), сделайте общие зависимости зависимостями большинства страниц и улучшите использование кеша зависимостей. размер vendor.js уменьшен до 30 КБ, а размер common.js — 42 КБ
Общий размер двух файлов составляет 72 КБ, что на 60 % меньше (100 КБ) по сравнению с размером до оптимизации.
1.2 Загрузка общедоступных компонентов по запросу
course.js 101kB (gzipd) Этот файл является файлом бизнес-кода страницы
Глядя на картинку выше, это в основном бизнес-код, за исключением огромного значка компонента **, на который приходится 25k **,1/4 размера файла подкачки, но в кодеВсего используется только 8 иконок.
Проанализируйте код, вы можете увидеть, что svg загружается с помощью require здесь,Webpack упаковывает содержимое требуемой папки вместе, что приводит к избыточным компонентам значков страниц.
Как решить такие проблемы, чтобы добиться загрузки по требованию?
Контент, загружаемый по запросу, должен быть отдельным компонентом, мы будем использовать предыдущий компонент ICON с одной записью (динамический опасно SetInnerHTML)Перейдите в режим компонента с одним файлом, чтобы напрямую ввести использование значков.
Однако в реальной разработке это будет немного проблематично, обычно требуется единый путь импорта, указываются и затем загружаются нужные значки.babel-plugin-import, мы можем настроить зависимый путь загрузки Babel, чтобы настроить способ представления Icon, тем самым реализуя загрузку значков по запросу.
После загрузки по запросу перекомпилируйте и просмотрите преимущества упаковки,Статистический размер компонента «Иконки» на странице был уменьшен с 74 КБ до 20 КБ, а объем уменьшен на 70%.
1.3 Разделение кода бизнес-компонентов
Наблюдая за страницей, вы можете видеть, что три модуля «Схема курса», «Детали курса» и «Инструкции по покупке курса» не находятся на первом экране, отображающем содержимое страницы.
Мы можем рассмотреть возможность разделения этих частей страницы, а затем отложить загрузку, чтобы уменьшить размер и время выполнения бизнес-кода JS.
Есть много способов разделить, вы можете использовать react-loadable, @loadable/component и другие библиотеки для достижения, вы также можете использовать React.lazy, официально предоставленный React
сплит-код
Разделение кода приведет к задержке рендеринга компонентов, поэтому решения следует принимать на основе пользовательского опыта и производительности проекта.Разделение также может задерживать загрузку некоторых ресурсов для оптимизации времени загрузки.
1.4 Оптимизация встряхивания дерева
В проекте используется оптимизация TreeShaking, будьте внимательны при ее использованииСценарии использования побочных эффектов, чтобы избежать несоответствия между упаковкой продуктов и разработкой.
После вышеуказанных шагов оптимизации общее содержимое пакета:
Количество файлов JS — 6, общий размер — 308 КБ, максимальный размер файла — 109 КБ.
Сравнение ключевых данных оптимизации JS:
| общий размер файла | Максимальный размер файла | |
|---|---|---|
| До оптимизации | 460.8 kb | 170 kb |
| Оптимизировано | 308 kb | 109 kb |
| Эффект оптимизации | 50% уменьшение общего объема | Максимальный размер файла уменьшен на 56% |
2. Некритическая ленивая загрузка JS
Страница содержит некоторые JS, связанные с отчетами, такие как sentry, beacon (SDK маяка) и т. д. Для таких ресурсов слабая сеть может стать фактором, влияющим на синтаксический анализ DOM.
Чтобы уменьшить влияние таких некритичных JS, некритические JS могут быть загружены после загрузки страницы, например, sentry официально предоставляетрешение для ленивой загрузки
В проекте также были обнаружены некоторые некритичные JS, такие как компоненты кода проверки, чтобы использовать кеш для загрузки как можно скорее на следующей странице,Таким образом, предыдущая страница загружается один раз заранее для создания кеша.
Если к следующей странице нет доступа, это может рассматриваться как недопустимая загрузка, и этот тип схемы раннего кэширования повлияет на производительность страницы.
Для этого ресурса мы можем использовать подсказки ресурсов для предварительной выборки ресурса.
Проверьте, поддерживает ли браузер prefech,Мы можем создавать ссылки Prefetch, если они поддерживаются, если она не поддерживается, используйте старую логику для загрузки напрямую, что может в большей степени обеспечить производительность страницы и обеспечить поддержку ранней загрузки следующей страницы.
const isPrefetchSupported = () => {
const link = document.createElement('link');
const { relList } = link;
if (!relList || !relList.supports) {
return false;
}
return relList.supports('prefetch');
};
const prefetch = () => {
const isPrefetchSupport = isPrefetchSupported();
if (isPrefetchSupport) {
const link = document.createElement('link');
link.rel = 'prefetch';
link.as = type;
link.href = url;
document.head.appendChild(link);
} else if (type === 'script') {
// load script
}
};
Эффект оптимизации: некритичный JS не влияет на загрузку страницы
3. Оптимизация загрузки медиаресурса
3.1 Оптимизация времени загрузки
Можно заметить, что загрузка блокируется большим количеством ресурсов изображений и видеоресурсов, но соответствующие изображения или видео не отображаются на странице, и эта часть контента должна загружаться лениво.
Метод обработки в основном заключается в управлении логикой отложенной загрузки изображений (например, загрузка после загрузки), которую можно реализовать с помощью различных библиотек отложенной загрузки. Проект H5 использует изображение определения положения (getBoundingClientRect), чтобы достичь видимой области страницы и затем отобразить ее.
Тем не менее, следует отметить, что ленивая загрузка не может блокировать нормальное отображение бизнеса.Вы должны принять основные меры, такие как тайм-аут обработки и повторная попытка.
3.2 Оптимизация размера
Страница сведений о курсе Ширина каждого подробного изображения составляет 1715 пикселей, что уже в 4 раза больше, чем у 6 (375 пикселей). Большие изображения будут влиять на загрузку страницы и скорость рендеринга при слабых сетевых условиях.
Используйте функцию сжатия размера изображения CDN для рендеринга изображений разных размеров в зависимости от разных устройств, настройки формата изображения и рендеринга изображений с разным разрешением в соответствии с условиями сети.
Видно, что в случае слабой сети (мобильная сеть 3G) максимальная и минимальная скорости загрузки одного и того же изображения с разными размерами различаются почти в 6 раз, что дает пользователям совершенно разные впечатления.
CDN сотрудничает с бизнесом для реализации:Используйте атрибут srcset/sizes тега img и тег picutre для реализации адаптивного изображения., пожалуйста, обратитесь кДокументация
Используйте динамическое соединение URL-адресов для создания запроса URL-адреса и настройте текущую ширину изображения, кратную ширине модели и условиям сети.(например, iphone 1x, ipad 2x, слабая сеть 0,5x)
Эффект оптимизации: на мобильном терминале объем изображения уменьшается на 220% при нормальных условиях сети, а объем изображения уменьшается в 13 раз при слабых условиях сети.
Обратите внимание, что визуальные студенты должны участвовать в реальном бизнесе, оценивать, соответствует ли четкость изображения визуальным стандартам, и избегать обратной оптимизации!
3.3 Другие виды оптимизации ресурсов
iframe
Загрузка iframe может серьезно повлиять на загрузку страницы. Загрузка до загрузки заблокирует запуск события загрузки, тем самым заблокировав загрузку, но есть еще одна проблема.
Как показано на рисунке ниже, страница запускает загрузку iframe, когда страница уже загружена, и индикатор выполнения продолжает вращаться до тех пор, пока содержимое iframe не будет загружено.
Вы можете установить время iframe после загрузки и использовать setTimeout для запуска асинхронной загрузки iframe, чтобы избежать эффекта загрузки, вызванного iframe.
отчетность данных
Запрос данных с использованием изображения в проекте может не повлиять на производительность страницы в нормальных условиях сети.
Но в некоторых особых случаях, например, когда один из запросов изображения занимает очень много времени, он блокирует запуск события загрузки страницы и продлевает время загрузки.
Существуют следующие решения для решения проблемы отчета о влиянии на производительность.
- Отложенная эскалация слияния
- Использование API маяка
- Используйте публикацию, чтобы сообщить
Проект H5 принимает план отложенного слияния и отчетности, и бизнес может быть выбран в соответствии с фактическими потребностями.
Эффект оптимизации: все отчеты данных обрабатываются после загрузки, чтобы избежать какого-либо влияния на производительность.
оптимизация шрифтов
Проект может содержать много визуально заданных шрифтов для рендеринга. Если файл шрифта относительно большой, это также повлияет на загрузку и рендеринг страницы. Вы можете использовать fontmin для сжатия ресурсов шрифта для создания упрощенной версии файла шрифта. ,
До оптимизации: 20 КБ => После оптимизации: 14 КБ
ЧАСТЬ 2: оптимизация рендеринга страницы
1. Прямая оптимизация времени TTFB страницы
В настоящее время мы развернули прямую исходящую услугу в STKE.Путем мониторинга мы обнаружили, что среднее время прямого исходящего соединения составляет 300+ мс.
Время TTFB колеблется между 100 и 200, что влияет на отрисовку прямых страниц.
через журнал,Просмотр журналов Nginx Accesslog, отнимающий много времени мониторинг шлюза, получены следующие данные (рис.
- Прямая процедура STKE занимает около 20 мс.
- Прямой выход из шлюза NGW -> STKE занимает около 60 мс.
- Обратный прокси-шлюз NGINX -> NGW занимает около 60 мс.
Войдите на машину, где находится NGW, пропингуйте машину STKE, и там следующие данные
Средняя задержка 32 мс, трехстороннее рукопожатие tcp + данные возврата (данные отправлены при последнем аке) = 2 rtt, около 64 мс, соответствует данным, записанным в логе
Убедитесь, что область, в которой находится машина NGW, находится в Тяньцзине, а область, в которой находится машина STKE, — в Нанкине.Предварительно можно определить, что задержка в сети вызвана физическим расстоянием аппаратной, как показано на следующем рисунке. фигура
Переключение NGW на машину в Нанкине пингует машину STKE в Нанкине, есть следующие данные:
Сетевая задержка пингующих машин в той же области составляет всего 0,x миллисекунд, как показано на следующем рисунке:
Основываясь на приведенном выше анализе, основной причиной длительного времени TTFB прямой страницы является:Развертывание шлюза NGW не находится в той же области, что и Nginx и STKE, что приводит к задержке в сети.
РешениеРазверните шлюз и комнату прямого обслуживания в одном месте, сделал следующее:
- Расширение мощностей NGW
- Polaris открывает доступ поблизости
До оптимизации
Оптимизировано
Эффект оптимизации показан выше:
| Среднее время работы шлюза за семь дней | |
|---|---|
| До оптимизации | 153 ms |
| Оптимизировано | 31 мс оптимизировано 80% (120 мс) |
2. Оптимизация времени рендеринга страницы
Смоделируйте ситуацию со слабой сетью (медленный 3g) Ситуация рендеринга страницы записи производительности, вы можете найти ее на скриншоте ниже
- DOM начинает синтаксический анализ, но страница еще не отрисована
- Страница отображается нормально после загрузки файла CSS
CSS не будет блокировать синтаксический анализ страницы, но заблокирует отрисовку страницы.Если файл CSS большой или сеть слабая, это повлияет на время отрисовки страницы и повлияет на взаимодействие с пользователем.
Используйте инструмент ChromeDevTool Coverage (в разделе «Дополнительные инструменты») для записи использования CSS во время рендеринга страницы.
Установлено, что коэффициент использования CSS первого экрана составляет всего 15%, что можно считатьВстраивайте критический CSS в верхнюю часть страницы,Пусть рендеринг страницы не блокируется CSS, а затем загрузите полный CSS
Оптимизация для реализации Critical CSS может рассмотреть возможность использованияcritters
После оптимизации:
Когда ресурс CSS загружается, страница может отображаться и отображаться нормально.По сравнению с до оптимизации время рендеринга улучшается на 1-2 времени загрузки файла CSS.
3. Оптимизация дрожания макета страницы
Наблюдайте за изменениями в элементах страницы
До оптимизации (левое изображение): отсутствующие значки, отсутствующие фоновые изображения, дрожание страницы, вызванное изменением размера шрифта, дрожание страницы, вызванное неожиданными элементами страницы
После оптимизации: контент относительно фиксирован, а элементы страницы кажутся ненавязчивыми.
Основное содержание оптимизации:
- Определяем положение прямых элементов страницы и делаем макет по прямым данным
- Небольшое изображение страницы может быть обработано base64, и оно будет отображаться сразу после анализа страницы.
- Уменьшите влияние динамического содержимого на макет страницы, используйте выход из потока документов или задайте ширину и высоту
В-четвертых, отображение эффекта оптимизации производительности
Эффект оптимизации количественно оценивается следующими показателями
First Contentful Paint (FCP): отмечает момент времени, когда браузер отображает первый контент из DOM.
Максимальное время рендеринга содержимого окна LCP (Largest Contentful Paint): Это означает, что просматриваемая область страницы близка к завершению рендеринга
Время загрузки индикатора выполнения: время запуска события загрузки браузера, отображение индикатора выполнения панели навигации завершается после запуска
Сравнение эмулятора Chrome 4G без кеша (до левой оптимизации, после правой оптимизации)
| Максимальное время отрисовки содержимого в верхней части сгиба | Время загрузки индикатора выполнения (onload) | |
|---|---|---|
| До оптимизации | 1067 ms | 6.18s |
| Оптимизировано | 31 мс оптимизировано 80% (120 мс) | 1.19 с оптимизировано 81% |
Сравнительный анализ Lighthouse
До оптимизации
Оптимизировано
| оценка производительности | |
|---|---|
| До оптимизации | В среднем от 40 до 50 |
| Оптимизировано | Среднее число от 75 до 85 увеличилось на 47% |
Еженедельные данные теста производительности srobot
srobot — это инструмент для определения производительности внутри команды, который использует команду TRobot для создания проверки работоспособности страницы одним щелчком мыши и автоматически определяет производительность страницы и аномалии через определенные промежутки времени.
До оптимизации
Оптимизировано
| Среднее время загрузки индикатора выполнения (onload) (4G) | |
|---|---|
| До оптимизации | 4632ms |
| Оптимизировано | 2581 мс, увеличение на 45% |
V. Итоги оптимизации и планирование на будущее
- Вышеупомянутые методы оптимизации в основном сосредоточены на трудоемкой оптимизации рендеринга при первой загрузке страницы, но еще есть много возможностей для оптимизации при второй загрузке, например:Использование PWA, непрямой обработки экрана скелета страницы, преобразования CSR в SSR и т. д..
- По сравнению с конкурирующими продуктами мы обнаружили, что загрузка нашего CDN занимает много времени.Мы собираемся начать миграцию CDN в облако в ближайшем будущем и с нетерпением ждем улучшения эффекта CDN после миграции в облако.
- Итерация проекта продолжается, и нам нужно думать о том, как постоянно обеспечивать производительность страницы в инженерных
- Выше приведен анализ и оптимизация страницы сведений о курсе. Несмотря на то, что весь проект был оптимизирован, серебряной пули для оптимизации производительности не существует. Оптимизация различных страниц должна выполняться в соответствии с конкретными потребностями страницы, и разработчики нужно взять на себя инициативу, чтобы обратить внимание.
Спасибо, что терпеливо читаете, приглашаем к общению, указывайте на ошибки и упущения в тексте, учитесь вместе!