предисловие

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

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

Выдающиеся показатели производительности

Первая основа оптимизации производительности — это данные и показатели. Без правильных данных и руководства по индикаторам идеи и направления оптимизации могут быть отклонены.

UC поддерживает индикаторы ядра и стандартные индикаторы W3C в статистике индикаторов производительности первого экрана.

Метрики ядра

start: момент времени, когда ядро блинка начинает создавать запрос, что можно понимать как точку "0"
T0: время, когда blink получил заголовок http
T1: время, когда содержимое отображается на первом экране.
T2: время, когда отображается весь первый экран

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

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

Обычной практикой является использование domContentLoadedEventEnd - fetchStart или даже использование loadEventStart-fetchStart после анализа дерева DOM страницы и отображения содержимого. Ниже приводится метод подсчета показателей производительности страницы.

мониторинг производительности

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

Платформа панорамного мониторинга Yueying может анализировать данные, собранные и переданные SDK, в режиме реального времени, а также интуитивно и удобно просматривать показатели производительности приложения. А за счет установки правил оповещения, когда индекс производительности достигает порогового значения, он будет своевременно уведомлен, и проблема будет обнаружена и устранена вовремя.

рынок в реальном времени

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

Просмотр тенденций производительности

Проверьте производительность страницы и проанализируйте производительность верхней части страницы и производительность загрузки страницы с помощью основных показателей, таких как первый байт, готовность DOM и полная загрузка страницы. (Если ядро UC подключено, можно интуитивно понять производительность первого экрана через T2)

Анализировать и находить определенные страницы

Дальнейший анализ, понять производительность верхних страниц доступа

Благодаря многомерному агрегированному анализу можно дополнительно определить масштаб проблемы.

Детальный анализ

Идеи оптимизации производительности

После тщательного анализа онлайн-данных можно продолжить углубленный анализ и оптимизацию.

1 направление оптимизации

Внешний интерфейс: внешний интерфейс фокусируется на оптимизации первого экрана, объединении доменных имен, управлении ресурсами js, управлении затратами времени на js, управлении изображениями и управлении интерфейсом.

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

[Предупреждение о галантерее] Ниже представлена наша общая идея оптимизации в проекте оптимизации H5 компании Ele.me.

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

HttpCache: в соответствии с определенными правилами ресурсы, возвращаемые из сети, кэшируются локально и могут быть напрямую прочитаны из локальной сети при следующем использовании. stale-while-revalidate позволяет продолжать использовать ресурсы в течение определенного периода времени после истечения срока их действия и в то же время инициировать асинхронный запрос, позволяя сначала использовать ресурсы, а затем проверять их.
LocalStorage: внешний интерфейс может использовать LocalStorage для локального хранения ресурсов, аналогично IndexedDB. LocalStorage также имеет некоторые ограничения, например, доменное имя может хранить только 5M данных и не может считываться между доменами.
MemoryCache: Кэш памяти. MemoryCache в Chrome в основном управляется сборщиком мусора. Когда ресурс попадает в MemoryCache, с ним связывается слабая ссылка, и она будет очищена при закрытии основного документа.
Автономный пакет (ZCache): когда пользователь обращается к странице, ядро спрашивает оболочку, есть ли доступные ресурсы через shouldInterceptRequest.Если есть доступные ресурсы, оболочка возвращает ресурсы, не обращаясь к сети для запроса ресурсов. [ZCache перейдет к логике перехвата оболочки, которая менее эффективна, чем HttpCache. Как правило, ресурсы доходят до ядра Blink за 100 мс, а для основного документа — 300 мс]
NetCache: результаты разрешения DNS, повторное использование длительного соединения.
Кэш байт-кода V8: Кэш байт-кода V8. [JS был выполнен один раз, и второе выполнение может значительно сократить время].
Кэш декодирования изображения: Кэш декодирования изображения.
PageCache: кэш на уровне страницы, WebViewCache в верхнем углу UC и нажатие кнопок «вперед» и «назад» в браузере UC сгенерируют WebViewCache.

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

Загружать полноэкранные документы заранее: в основном используется в информационном потоке, загружать документы первых нескольких элементов заранее, и пользователи могут получить к ним доступ за считанные секунды при нажатии.
Предварительная загрузка изображения над сгибом: в основном используется в информационном потоке. Когда вы нажимаете, чтобы получить доступ к документу, одновременно отправляется запрос на изображение. Когда для анализа документа необходимо использовать изображение, изображение выше сгиба было загружено локально заранее.
Предварительная загрузка ссылок: Ресурсы, которые необходимо предварительно загрузить, отмечены в заголовке ответа ресурса или в заголовке основного документа.Ядро загрузит эти ресурсы заранее в соответствии с определенными правилами и приоритетами.
Предварительная загрузка модуля: аналогична предварительной загрузке Link, но это предварительная загрузка на уровне модуля.Помимо предварительной загрузки зависимых ресурсов модуля, он также может заранее компилировать и анализировать модуль JS.
Предварительная выборка ссылки: имя домена адресовано заранее.
Заранее загружать данные интерфейса: предварительная загрузка навигации и предварительная загрузка алгоритма в режиме ожидания.

Что касается предварительной загрузки интерфейса, мы делаем это в плагине js. Конечно, вы также можете перехватить обработку в промежуточном программном обеспечении сетевой библиотеки. Существует две реализации предварительной загрузки интерфейса HTTP:

Перехват shouldInterceptRequest: перехватывать, есть ли здесь кеш Response, и возвращать его Недостаток в том, что синхронизацию интерфейсов сделать нельзя.
Перехват MtopWVPlugin (ANetBridge): мы повторно реализовали расширение JS Plugin, которое совпадает с MtopWVPlugin, и перехватывает его на уровне расширения.

2 Инструменты и платформы для анализа производительности

Luban Ruler: UC Luban Ruler основан на Lighthouse, он анализирует реальный рендеринг страницы в ядре и дает предложения по оптимизации.
Seagull Lab: UC Seagull Lab — это платформа для анализа производительности, которая может предоставить полные данные анализа первого экрана, памяти, запуска и частоты кадров.
Lighthouse: обнаружение узких мест в производительности страницы.
Временная шкала: запишите конкретные сведения о запущенном процессе страницы, которые используются для анализа конкретного места проблемы со страницей.
Профиль: Анализируйте использование страничной памяти и время выполнения JS/CSS. Как правило, вы можете использовать TImeline для определения приблизительного местоположения, а затем использовать профилировщик ЦП JavaScript для подробного анализа времени, затрачиваемого каждой функцией JS.
Chrome Trace: записывает весь процесс выполнения страницы в ядре браузера с детализацией до каждого функционального метода, что позволяет точно определить конкретные проблемы.

Практика оптимизации

Далее давайте посмотрим, как проанализировать точку оптимизации производительности страницы H5.

1 Получить данные анализа производительности

Можно использовать платформу линейки UC Luban. он генерирует отчет о сексуальной активности

Линейка Luban основана на Lighthouse. Когда Lighthouse работает локально, помимо создания отчетов о производительности, он также может создавать файлы Chrome Trace для нашего анализа.

Конечно, вы также можете сохранять журналы Timeline и Chrome Trace локально. Получив отчет о производительности, мы можем примерно увидеть, какие места требуют больше времени, загрузки ресурсов, S времени и так далее. Затем проанализируйте его по журналу трассировки.

2 Получите журнал T2 и проанализируйте временную шкалу T2

Если ядро UC подключено, вы можете проанализировать журнал T2, и при анализе обратить внимание на несколько данных:

frameCount: количество кадров последнего T2, указывающее, что вычисление T2 завершено в этом кадре. Когда мы искали T2Paint_Event в интерфейсе Trace, мы нашли этот frameCount, нажали клавишу m и отметили линию T2.
tStart: представляет собой время, когда T0 начинает вычисляться.Поиск TStart_Point может найти эту точку.

После определения строки T2 можно проанализировать ситуацию с отрисовкой страницы перед строкой T2, а также факторы, влияющие на отрисовку страницы.

3 Проанализируйте общую производительность

Проанализируйте общую ситуацию рендеринга перед T2, например, часть с длительным выполнением JS и часть с длительным временем загрузки.

4 Анализ производительности загрузки

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

5 Анализ производительности типографики

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

6 Анализ производительности JS

Производительность JS в основном включает три аспекта:

Время парсинга и компиляции JS
JS соответствующая бизнес-логика
Выполнение конкретной функции JS занимает много времени

Вообще говоря, v8.compile занимает более 100 мс, что занимает больше времени.

Кроме того, вам нужно обратить внимание на интервал выполнения между двумя v8.runs.Вообще говоря, когда возникает интервал, он ожидает интерфейса или ресурса. Этот кусок может быть точкой оптимизации, такой как предзагрузка интерфейса, офлайн ресурса и т.д.

Затем используйте временную шкалу, чтобы проанализировать затраты времени на определенные функции, найти более трудоемкие функции js и соответствующим образом оптимизировать их.

7 Обратите внимание на влияние декодирования изображения на время T2.

Вообще говоря, на расчет T2 влияют два фактора:

Декодирование и рендеринг изображения.
Содержимое над сгибом меняется. (Скольжение, ленивая загрузка изображений, динамические узлы)

Картинки, особенно маленькие значки, значительно влияют на время T2 на некоторых страницах.Например, на странице выбора красного конверта Ele.me, после анализа, именно маленький значок в списке красных конвертов значительно продлевает время T2.После изменения это к иконке. Оптимизация T2 занимает более 1400 мс, а производительность повышается более чем на 45%.

Так что мы можем заменить эту часть маленьких картинок на IconFont или css (векторная графика svg не может рассчитать ширину и высоту картинки, поэтому она не включается в расчет). Если для некоторых изображений необходимо игнорировать расчет T2, вы также можете использовать отметку uc-perf-stat-ignore (новая версия ядра поддерживает 3.22).

Сравните разницу во времени между T2Paint_Event UC и loadEventStart W3C, чтобы увидеть влияние декодирования изображения на вычисление T2.

Найдите DecodeImage, чтобы наблюдать за декодированием изображения.

Бесплатная пробная версия платформы панорамного мониторинга Yueying

Эта статья познакомит вас со многим.Если вы хотите узнать производительность приложения в Интернете, вы можете попробовать платформу панорамного мониторинга Yueying.

Платформа панорамного мониторинга Yueying упрощает работу с пользователем>>>Ткните меня, чтобы посетить платформу панорамного мониторинга Yueying