Практика оптимизации производительности внешнего интерфейса для оптимизации домашней страницы приложения Baidu

Оригинальная технология панорамирования Baidu App

предисловие

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

применять к: Можно использовать все традиционные методы оптимизации: упаковка и распаковка, уменьшение размера и количества HTTP-запросов, CDN и загрузка по требованию и т. д., но производительность все равно не идеальна.

Определение индикаторов и построение отчетов

Формулировка отличной программы в первую очередь должна быть подкреплена точными данными.

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

Персональная домашняя страница — это веб-страница в клиенте приложения Baidu. Существует два разных способа открыть гибридную версию (с использованием файлового протокола для прямой загрузки локальных HTML, JS, CSS) и веб-версию (открытие веб-URL).

Во-первых, давайте взглянем на структуру страницы профиля:

В области заголовка отображается личная информация текущего автора, а в области вкладок — контент, созданный автором. Все данные на странице извлекаются асинхронно.

Процесс открытия персональной домашней страницы можно упростить следующим образом:

Затраты времени можно разделить на три части: время окончания, время сети и сервера и время рендеринга переднего плана:

На основании вышеуказанного процесса мы разработали принципы определения показателей:

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

Домашняя страница - это SPA-страница, созданная san.DOM, синхронизированный на HTML, не имеет реального содержимого.До того, как пользовательские данные на первом экране будут возвращены, страница отображается в состоянии загрузки. Итак, определение белого экрана:Контент на странице DOM mount(первый раз, когда пользователь видит, что страница больше не пустая)

Поскольку время срабатывания события загрузки в терминале для iOS и Android отличается, загрузка ресурсов в iOS будет блокировать отрисовку страницы, поэтому домашняя страница была настроена для iOS, используя rAF, чтобы запускать загрузку iOS при запуске JS, и Android в первую очередь срабатывает после загрузки всех необходимых экрану ресурсов типа картинок и jsonp, поэтому данный индикатор в основном используется как вспомогательная функция.

В процессе построения отчета в сочетании с бизнес-формой главной страницы (и для Android, и для iOS есть как гибридная версия, так и веб-версия) и смыслом определения показателя этапы всего процесса максимально детализированы, следующим образом:

• Сгруппируйте три версии домашней страницы: гибридную версию, гибридную гибридную веб-версию и веб-версию. Он может избежать вмешательства в данные и провести экспериментальное сравнение, контролируя время в сети.
• Добавить ксистема, внутри и снаружи, отправная точкаВ качестве условия фильтра исключите различия в данных, вызванные различными условиями использования, что полезно для сужения области анализа и анализа позиционирования.
• В соответствии с процессом выполнения домашней страницы, трудоемкий процесс подразделяется на дальнейшее обнаружение проблемы.Вся стадия подразделяется на:Занимает много времени в конце (от щелчка до разбора верхней части заголовка страницы), требует много времени на синхронизацию каждого эталонного этапа JS в HTML, требует много времени на запрос данных, требует много времени на конечные возможности страницы. и жизненный цикл каждого компонента до первого экрана(Времязатратная часть постепенно уточняется в фактической оптимизации)

Наконец, получается подробное разделение каждого этапа:

Дополнительные инструкции:

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

• Трудоемкая часть терминала может только подсчитать общее время от клика предыдущей страницы до начала страницы парсинга.

Анализ данных, предложение направления оптимизации

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

Данные производительности на рисунке показывают основные трудоемкие этапы:Трудоемкость на стороне клиента, трудоемкость при внедрении основного profile.js в js, трудоемкость на интерфейсе первого экрана, трудоемкость на обработку данных страницы и рендеринг, по основным трудоемким этапам оптимизация делится на следующие аспекты:

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

Начните оптимизировать, постепенно улучшайте

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

• Страница находится в режиме SPA, но бизнес сложный и общий размер кода большой.
• Ресурсы, необходимые для первого экрана гибридной версии, возвращаются двумя интерфейсами, и эти два интерфейса являются зависимыми.Интерфейсное последовательное исполнение
• Основные пользовательские данные веб-версии используют синхронизированные данные, а интерфейс зависимой вкладки такой же, как и в гибридной версии.
• Особенности гибридной версии:
  • Гибридная версия и веб-версия используют один и тот же набор кода, скомпилированный по-разному, но первый интерфейс в веб-версии является синхронным, и данные возвращаются с шаблоном HTML, тогда как все интерфейсы в гибридной версии являются асинхронными.
  • Используется больше сцен
  • Используйте файловый протокол для загрузки HTML-шаблона и используйте метод jsonp для запроса внутреннего интерфейса данных.

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

интерфейсный код

Активировать раннюю загрузку iOS

• Метод: используйте вложенный setTimeout rAF для запуска события onload заранее, чтобы решить ситуацию, когда загрузка ресурса iOS блокирует отображение страницы.
• Преимущество: время, видимое пользователю в верхней части страницы, не блокируется нагрузкой.

Уменьшить зависимость от первого экрана

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

После периода анализа сбора данных и проверки кода мы обнаружили некоторые области для улучшения:

• В части логики перед первым экраном, когда JS инициализирует некоторые данные, он одновременно вызывает несколько нативных методов (конечные возможности), что приводит к трудоемкому 80-му процентилю выполнения конечных возможностей, что намного превышает теоретическое значение;
• Самый внешний компонент App страницы SPA монтируется после возврата данных первого интерфейса. Для веб-версии страницы первый интерфейс является синхронным, поэтому приложение монтируется после того, как интерфейс оказывает незначительное влияние; но для гибридной версии с большим количеством сценариев использования требуется как минимум два интерфейса для первого экрана страницы. и все интерфейсы Запросы все асинхронные, до возврата первого интерфейса достаточно обработать необходимую логику многих страниц, а время на монтирование приложения очень неподходящее.
• На странице зарыто много точек, кроме pv, остальные в основном представляют собой точки представления каких-то мелких компонентов на странице.Частые запросы точек перед фолдом занимают время загрузки картинок в фолде.

На основании вышеизложенного код был скорректирован следующим образом:

• Отрегулируйте порядок выполнения вызовов собственных возможностей, оставьте первый экран по мере необходимости и опубликуйте остальные, чтобы сократить время выполнения конечных возможностей.
• Оптимизировать необходимую информацию кода (например: время выполнения персональной домашней страницы от начала до конца) логику инициализации
• Монтирование самого внешнего компонента приложения не зависит от данных интерфейса, страница инициализируется заранее, данные интерфейса запрашиваются параллельно, рендеринг асинхронный.
• Настройте логику выполнения кода, переместите ключевую логику в хранилище и выполните ее заранее
• Некоторая логика, такая как точки на странице, помещается позади, уменьшая время выполнения монтажа страницы

После волны операций был получен прирост 100 мс+ в 80-м процентиле.

Слияние интерфейсов в верхней части страницы

Как упоминалось выше, гибридный первый экран должен последовательно выполнять два асинхронных сетевых интерфейса на внешнем интерфейсе. Судя по статистике производительности, в процессе вызова интерфейса и получения данных интерфейса самое долгое время - это установление сетевого соединения. Два интерфейса объединены в один интерфейс, и первое время экрана может быть сохранено в хотя бы раз Время подключения к сети (персональная домашняя страница достигла 110 мс+). Конечно, слияние интерфейсов также должно учитывать плавный звук на стороне сервера и учитывать потерянное время белого экрана, которым можно пожертвовать.

Интерфейс переднего экрана

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

Известно, что основной браузер может обрабатывать запрос на параллельную обработку, как правило, по умолчанию от 4 до 6, при загрузке JS (JSONP) последовательное изменение происходит параллельно, экономя одно из двух перекрывающихся времен. Интерфейс первого экрана делает так:
Гибрид соответствует небольшому пакету кода с минимальным размером, и данные первого интерфейса берутся, а глобальная переменная депонируется и отправляется в виде события. Поскольку первый запрос в первый раз в части сетевого подключения iOS длиннее, в случае возможности Native end вместо JSONP интерфейс первого экрана опережает доход iOS на 260 мс +, Android 60 мс.

Инжиниринг

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

Упаковка и распаковка

Ресурсы JS и CSS упакованы и объединены, но необходимо учитывать, что упакованный файл слишком большой и один запрос занимает слишком много времени, необходимо разумно разделить пакет кода в соответствии с бизнес-сценарием. Количество запросов, которые могут обрабатываться параллельно основными браузерами, по умолчанию обычно составляет от 4 до 6, а пакеты ресурсов можно разумно разделить, а общее время отклика можно сократить за счет использования параллельных запросов. Максимально используйте кэш браузера, правильно разбивая пакеты. Заблокируйте версию, сохраняйте стабильное значение хеш-функции, когда каждый небольшой пакет не изменился, а более крупные JS, CSS и изображения будут напрямую записываться в кеш жесткого диска. Например, по частоте модификации кода персональная домашняя страница разбивает js-пакет на три пакета одинакового размера, среди которых вендоры — различные npm-зависимости, версия стабильна и обычно не меняется. После каждого выхода в сеть браузеру пользователя достаточно запросить еще два пакета кода из CDN, а вендоры используют локальный кеш, срок действия которого не истек в прошлый раз.

современный режим

Обычно при разработке мы используем ES6 (ES2015+) для написания кода.Новая функция ES6 может сделать работу по разработке более удобной, но пакеты, нужно конвертировать в Babel, чтобы наш код мог работать в браузере, не поддерживающем ES6 . Код преобразования присоединится к Polyfill, самое интуитивное ощущение — это размер пакета кода. СОВРЕМЕННЫЙ РЕЖИМ В браузере, который поддерживает собственный ES6, JS загрузит скомпилированную версию Babel, загрузив

Анализ данных после оптимизации

Время первого экрана на обоих концах значительно сокращается, а запрос первого экрана (оранжевая часть на двух рисунках) выигрывает от оптимизации производительности интерфейса одноклассников сервера, а один только плоский звук сокращается на 80 мс+;

На Android, благодаря оптимизации гибридного фреймворка терминальных студентов, скорость загрузки гибридных страниц и локальных js-ресурсов быстрее, а эффект еще значительнее.

Суммировать

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