Повышение эффективности за счет использования разделения кода, шаблона PRPL и отложенной загрузки
Пару недель назад я посетил встречу и имел возможность узнать о некоторых невероятных инструментах Google Dev Tools, доступных для использования через расширения Google Chrome, командную строку или модули Node. Один из моих любимых инструментов - Google Lighthouse, который проводит аудит веб-страницы и генерирует отчет с подробными сведениями о производительности, доступности, PWA и многом другом. Он также содержит конкретные сведения о том, какие факторы повлияли на конкретную оценку, а также четкие предложения с документацией о том, как можно улучшить оценку.
Перед недавним собеседованием я запустил Google Lighthouse на веб-сайте компании, чтобы проверить их эффективность (в надежде получить дополнительные баллы!). Оказывается, они набрали 27 баллов из 100 возможных по эффективности веб-сайтов, что ставит их в красную зону. Большой OOF!
Изучив отчет, мы увидели, что основными виновниками были:
- Работа в основном потоке
- Время выполнения JavaScript
- Огромные сетевые нагрузки
«JavaScript анализируется и компилируется в основном потоке. Когда основной поток занят, страница не может отвечать на ввод пользователя. […] JavaScript также выполняется в основном потоке. ”
Согласно отчету Google Lighthouse, работа с основным потоком добавила дополнительные колоссальные 10,2 секунды ко времени загрузки. На этот раз включает синтаксический анализ, компиляцию и выполнение JavaScript. Кроме того, сайт несет полезную нагрузку сети в размере 4327 КБ - определенно не оптимально. Чем больше объем JavaScript, тем больше время загрузки, больше стоимость сети и, к сожалению, тем неприятнее пользовательский опыт.
Итак, как мы можем уменьшить размер и время работы основного потока? Давайте рассмотрим несколько вариантов.
Разделение кода
Если вы попытаетесь съесть целый бутерброд сразу, это, вероятно, займет у вас больше времени, чем если вы будете есть по одному маленькому кусочку за раз и переваривать каждый кусочек по порядку. Точно так же, если вы доставляете весь свой JavaScript в одной огромной куче, компилятору потребуется много времени, чтобы сначала прочитать весь этот код, а затем обработать весь этот код в среде выполнения для визуализации веб-страницы. Разделение кода - это простой способ доставки JavaScript небольшими пакетами для ускорения синтаксического анализа и компиляции, а затем отправки каждого пакета в среду выполнения. С меньшими фрагментами JavaScript вы можете сократить время загрузки и повысить производительность в Интернете.
Три разных способа разделения кода:
- Разделение по поставщикам - это разделение всего, что вы можете считать «зависимостью» или сторонним источником, в отдельную папку, условно «/ vendor». Если есть какие-либо изменения, внесенные в код вашего приложения или код поставщика, они могут обрабатываться отдельно, не нарушая других.
- Разделение точки входа рекомендуется для приложений, для которых не предусмотрена четкая настройка маршрутизации на стороне сервера и маршрутизации на стороне клиента. Это означает разделение кода при первоначальной сборке зависимости с использованием таких инструментов, как webpack.
- Динамическое разделение рекомендуется для одностраничных приложений, где используются динамические операторы «import ()».
Восстановление всей базы кода для реализации разделения кода может показаться тяжелым испытанием, но хорошая новость заключается в том, что существует множество инструментов, позволяющих сделать этот процесс автоматическим (Preact CLI, PWA Starter Kit и т. Д. ). Но если вы работаете над небольшой функцией, проектом или только начинаете, знайте, что ручное разделение кода поддерживается React, Vue и Angular.
PRPL
- Push критически важных ресурсов для начального URL-маршрута.
- Визуализируйте первоначальный маршрут.
- Предварительно кэшировать оставшиеся маршруты.
- Ленивая загрузка и создание оставшихся маршрутов по запросу.
Рекомендуется построить архитектуру кода таким образом, чтобы вы сначала отправляли минимальный объем кода, необходимый для отображения страницы. По сути, начните с отправки скелета, а затем добавьте мышцы, органы и одежду. Это значительно сократит время, затрачиваемое на интерактивность. Разработчики разработали шаблон PRPL, чтобы сократить время загрузки и свести к минимуму использование памяти для мобильного Интернета.
Документация Google объясняет PRPL эффективно и действенно, но, чтобы дать вам краткое изложение, PRPL лучше всего использовать со следующей структурой приложения:
- точка входа: index.html - должен быть достаточно маленьким, чтобы минимизировать использование ОЗУ.
- оболочка: логика приложения верхнего уровня, маршрутизация, основной пользовательский интерфейс, статические зависимости
- фрагменты: все, что не сразу видно в загруженном содержимом DOM. Здесь в игру вступает ленивая загрузка.
Вы также можете настроить процесс независимой сборки и использовать HTTP / 2 Push или <link rel="preload">, чтобы указать, какие фрагменты кода важны для каркасной структуры. Если эти функции не поддерживаются, вы можете объединить процесс сборки в пакеты оболочки и фрагментов.
Другие способы уменьшения полезной нагрузки включают минимизацию JS, HTML и CSS с помощью компрессоров, использование сжатия текста, такого как GZIP, и выбор оптимальных типов файлов изображений и уровней сжатия.
Ленивая загрузка
Ленивая загрузка - это то, на что это похоже - она будет готова к загрузке, но позже, когда она вам понадобится. Быстрый способ сэкономить данные и время обработки - отложить любые ресурсы до тех пор, пока они не попадут в область просмотра. Для изображений вы можете использовать обработчики событий, такие как scroll или resize, но в более современных браузерах доступен API-интерфейс наблюдателя пересечения.
В обоих случаях вы указываете какой-то индикатор, чтобы сообщить коду, когда ресурс находится в области просмотра. Вы можете объявить ленивый URL-адрес изображения и фактический URL-адрес изображения, просто присвоив тегу изображения класс lazy; для фоновых изображений для div используйте классы .lazy-background и .lazy-background.visible. Как и ожидалось, эти библиотеки отложенной загрузки существуют для ускорения реализации отложенной загрузки, поэтому вам не нужно тщательно исследовать, что происходит за кулисами. Вам не нравится, как разработчики помогают друг другу облегчить жизнь?
Заключение
Шаблон PRPL - золотой стандарт, особенно для мобильной разработки, позволяющий минимизировать нагрузку на сеть и эффективно организовать архитектуру кода. Это в значительной степени означает, что для лучшей практики следует применять разделение кода и отложенную загрузку. Разделение кода прекрасно подходит для разбиения кода на управляемые части, которые среда выполнения должна обрабатывать, тем самым избавляя от лишнего шума работу основного потока. Ленивая загрузка может сэкономить память и сократить время загрузки за счет вызова фрагментов ресурсов, особенно типов медиафайлов, только тогда, когда они необходимы. С помощью этих трех простых реализаций вы можете значительно сократить время, затрачиваемое на интерактивность, и, следовательно, улучшить взаимодействие с пользователем.
Отправляйте только тот код, который нужен вашим пользователям.
Сократите код.
Сожмите код.
Удалите неиспользуемый код.
Кэшируйте свой код, чтобы уменьшить количество сетевых отключений.
