Этот текст основан на недавней совместной работеПриходите и спросите у сиреневого доктора СПАОрганизован опыт оптимизации скорости загрузки апплета Dr. Lilac.

Отсканируйте Wechat, чтобы испытать мини-программу Dr. Lilac:

Эффект

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

подойди и спроси сиреневого доктора

Chrome Network

Для случайной выборки были выбраны главная страница и моя страница с большим количеством посещений, из рисунка ниже видно, что время загрузки главной страницы снизилось с 5,1 с до 1,67 с, а моей страницы с 2,92 с до 1,82 с.

Перед оптимизацией

титульная страница

моя страница

Оптимизировано

титульная страница

моя страница

mta

Согласно данным о скорости отклика страницы на утро 2018.01.02, средняя скорость загрузки в различных провинциях Китая составляет 0,99~2 с (хотя она не достигает 1 с, но при нынешнем уровне бизнеса такая скорость приемлема). ):

Google PageSpeed Insightsа такжеПлагин для Chrome для анализа скорости загрузки страниц

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

Апплет доктора Гвоздики

Для апплета после оптимизации отзывы студентов на кафедре следующие:

Каковы конкретные показатели данных? Хотя нет особенно простых в использовании метода тестирования производительности (включая официальный инструмент тестирования производительности), в конце концов, SHU ZHE, студент в нашей группе, использовал официально предоставленный инструмент для простых сравнений. Данные следующим образом:

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

Зачем оптимизировать скорость загрузки?

Непосредственная причина проста: медленно. Хотя скорость загрузки страницы не является невыносимо низкой, по крайней мере, люди не могут сказать, что скорость загрузки очень высока.

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

Это хороший вопрос, который я задавал себе много раз посреди ночи. Ответ, который я дал себе, таков: «Прежде всего, я должен признать ограниченность собственного технического уровня и опыта. ситуация может быть лучше, чем до оптимизации. Во-вторых, предыдущие проекты всей продуктовой линейки находились в процессе освоения и быстрой итерации, а ресурсы front-end R&D в основном всегда находятся в состоянии наполнения спросом, а приоритет быстрого запуска требований к продукту - самый высокий. Именно потому, что общий ритм продукта немного замедлился, у ресурсов НИОКР есть энергия для некоторой оптимизации.

Почему оптимизация скорости отклика фронтенда, а не фронтенда и бэкенда?

Поскольку я наблюдал, что эти два проекта растут со своими глазами, с точки зрения вспомогательной инженерии, в пределах объема моего собственного познания, я давно полагал, что в проекте есть некоторые области, которые необходимо оптимизировать. Я провел идею начать с первого конца первого конца, потому что я прочитал«Руководство по высокопроизводительным веб-сайтам»В этой книге упоминается золотое правило производительности (Performance Golden Rule): только 10% ~ 20% времени отклика конечного пользователя тратится на загрузку HTML-документов. Кстати говоря, почему вы колеблетесь, давайте начнем с внешнего проекта, засучим рукава и усердно поработаем.

Раньше я посещал Qcon и другие технические конференции и слышал несколько отзывов о скорости загрузки. Например: использование HTTP2, front-end и back-end оптимизация на уровне всего сайта и т.д. План действительно хороший план, но вопрос о том, следует ли применять его к реальному проекту вашей собственной команды, должен обсуждаться в долгосрочной перспективе в соответствии с размерами затрат на выполнение и технического резерва команды.

Почему он первичен?

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

Как?

Прелюдия такая длинная, наконец пора начинать.

Приходите и спросите у сиреневого доктора СПА

Сначала посмотрите на картинку (зеленая часть — это метод, который был применен в проекте):

Реализовать механизм посетителей

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

Процесс преобразования выглядит примерно следующим образом: разбор существующего процесса продукта -> отмена принудительного входа в систему при входе пользователя в приложение -> определение статуса входа пользователя в основную часть процесса продукта и управление входом в систему. Конкретные детали реализации здесь не повторяются.

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

После реализации механизма посетителей следующим шагом будет начало работы над пакетом ресурсов приложения. Поскольку это видно из инструментов разработчика Network of Chrome, загрузка ресурсов CSS и JS по-прежнему занимает много времени. Следующая картинка — до уменьшения размера пакета ресурсов:

Оптимизированный размер пакета до оптимизации - Gzip

Оптимизация сторонних зависимостей

Чтобы уменьшить размер ресурсов, вам сначала нужно знать, какие ресурсы следует/можно удалить. Поскольку проект построен на Webpack, вы можете использоватьWebpack Bundle AnalyzerПроанализируйте состав тела пакета, сгенерированного Webpack. Затем удалите его в соответствии с реальной ситуацией.

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

разделение кода

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

Разделение кода в основном основано на динамическом импорте Webpack.

Webpack в настоящее время имеет три распространенных метода разделения кода:

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

После сравнения был окончательно выбран метод динамического импорта.

динамический импорт

webpack предоставляет две похожие технологии:

синтаксис import() (рекомендуется, соответствует предложению ECMAScript)
require.ensure (предписано webpack)

Пример

// 分离 lodash
async function getComponent() {
    const _ = await import(/* webpackChunkName: "lodash" */ 'lodash');
}

ленивая загрузка

Ленивая загрузка — это шаг к разделению кода.

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

Vue-RouterВ сочетании с VueАсинхронные компонентыи вебпакразделение кодафункция, реализованнаяЛенивая загрузка компонентов маршрутизации.

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

Гзарился:

Ресурсы js, которые пользователь должен загрузить при входе на домашнюю страницу, взяты изvendor.js,main.jsа такжеchunksВсего 672,84кб становится нужно только загрузить 186кбmain.js.

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

спросить доктора Лайлак основано наVue.jsРеализована вся семейная корзина, а управление состоянием используетVuex.

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

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

Полное разделение передней и задней части

Ознакомьтесь с этой статьей:Путь исследования для полного разделения передней и задней частей SPA

Апплет доктора Гвоздики

Старые правила, сначала посмотрите на картинку:

Ресурсы изображений

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

Оптимизация аутентификации входа

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

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

предварительный рендеринг

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

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

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

Загрузка подпакета

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

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

Суммировать

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

законченный?

Нет! Оптимизация производительности внешнего интерфейса — это долгий путь.

Автор этой статьи: Front-end Engineer Lilac Garden @zhiyao