Как оптимизировать производительность интерфейса на работе (21 оптимизация + 7 методов позиционирования)

1. Важность

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

Если мы сможем сократить время отклика серверной части вдвое, общее время отклика может быть уменьшено только на 5–10 %. Однако, если вы сосредоточитесь на производительности внешнего интерфейса и уменьшите его время отклика вдвое, общее время отклика может быть уменьшено на 40-45%.

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

Только 10–20 % времени отклика конечного пользователя тратится на загрузку HTML-документов, а остальные 80–90 % времени тратятся на загрузку всех компонентов на странице.

2. Позиционирование

2.1 Технические решения

В ежедневной фронтенд-разработке очень важен технический выбор. Зачем говорить об этом? Из-за частых происшествий.

Когда фронтенд-инжиниринг серьезен, легкие фреймворки постепенно забываются. Не все бизнес-сценарии подходят для использования инженерных фреймворков, а react/vue не легковесны.

Сложные фреймворки предназначены для решения сложных задач.

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

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

Этот аспект является ключевой проблемой, которая приводит к Катону.

2.2 NetWork

Наш старый друг NetWork должен быть знаком с фронтенд-одноклассниками. Давайте сначала посмотрим на сетевую панель

Из панели мы можем увидеть некоторую информацию:

• запросить размер ресурса
• Длительность запроса ресурса
• количество запрашиваемых ресурсов
• Время отклика интерфейса
• Количество инициированных интерфейсов
• размер пакета интерфейса
• Статус ответа интерфейса
• водопадная диаграмма

водопадная диаграммаЧто тогда?

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

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

Описание цвета диаграммы водопада:

• DNS Lookup[Темно-зеленый] — прежде чем браузер сможет взаимодействовать с сервером, он должен выполнить поиск DNS, преобразуя доменное имя в IP-адрес. На этом этапе вы можете обработать очень немногое. Но, к счастью, не все запросы нужны пройти этот этап.

• Initial Connection[Оранжевый] — прежде чем браузер сможет отправить запрос, должно быть установлено TCP-соединение. Это происходит только в первых нескольких строках каскадной диаграммы, в противном случае это проблема производительности (подробнее об этом позже).

• Согласование SSL/TLS [фиолетовый] — если ваша страница загружает ресурсы через безопасный протокол, такой как SSL/TLS, на этот раз браузер устанавливает безопасное соединение. В настоящее время Google использует HTTPS в качестве одного из факторов ранжирования в поиске, SSL / Использование согласования TLS становится все более распространенным.

• Time To First Byte (TTFB)[Зеленый] — TTFB — это время отправки запроса браузера на сервер + время обработки запроса сервером + время поступления в браузер первого байта ответного сообщения. производительности веб-сервера недостаточно, или вам нужно использовать CDN.

• Загрузка (синий)- Это время, которое требуется браузеру для загрузки ресурса. Чем больше это время, тем больше ресурс. В идеале вы можете контролировать продолжительность этого времени, контролируя размер ресурса.

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

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

• Во-вторых, уменьшение количества запросов означает уменьшение высоты каскадной диаграммы: чем короче каскадная диаграмма, тем лучше.

• Наконец, ускорьте время рендеринга, оптимизировав порядок запросов ресурсов. На графике это означает перемещение зеленой линии «начать рендеринг» влево. Чем дальше эта линия сдвинута влево, тем лучше.

Таким образом, мы можем устранить «медленную» проблему с точки зрения сети.

2.3 webpack-bundle-analyzer

Пакет пакета, сгенерированный после сборки проекта, сжимается. webpack-bundle-analyzer — инструмент для анализа пакетов.

Давайте посмотрим, какие эффекты это может принести. Как показано ниже:

На приведенном выше рисунке наш пакет пакетов анализируется с первого взгляда. Чем больше площадь модуля, тем больше размер в комплекте поставки. Стоит отметить, акцентируя внимание на оптимизации.

Информация, которую он может узнать,

• Показать все импортированные модули в пакете
• Отображение размера и размера модуля после gzip

Очень важно проверить положение модулей в пакете.Используйте webpack-bundle-analyzer, чтобы проверить некоторые бесполезные модули и негабаритные модули. Тогда оптимизируйте. Чтобы уменьшить размер пакета и время загрузки.

Установить

# NPM 
npm install --save-dev webpack-bundle-analyzer
# Yarn 
yarn add -D webpack-bundle-analyzer

Использовать (как плагин Webpack)

const BundleAnalyzerPlugin = require('webpack-bundle-analyzer').BundleAnalyzerPlugin;
 
module.exports = {
  plugins: [
    new BundleAnalyzerPlugin()
  ]
}

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

2.4 Performance

Собственный модуль производительности Chrome. Сначала прикрепите официальный сайт портала документов:Performance

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

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

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

• Время FCP / LCP слишком долго?
• Паошенствие запросов есть частая параллелия?
• Последовательность инициирования запроса Неверная ли последовательность инициирования запроса?
• выполнение javascript слишком медленное выполнение javascript?

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

Помните, как сначала получить эти индикаторы, а затем анализировать и оптимизировать их один за другим.

2.5 PerformanceNavigationTiming

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

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

function showNavigationDetails() {
  const [entry] = performance.getEntriesByType("navigation");
  console.table(entry.toJSON());
}

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

Параметр Описание

navigationStart Время начала загрузки
redirectStart время начала перенаправления (если происходит HTTP-перенаправление, и каждое перенаправление находится в том же домене, что и текущий документ, возвращается значение fetchStart, с которого началось перенаправление. В остальных случаях возвращается 0)
redirectEnd время окончания перенаправления (если происходит перенаправление HTTP, и каждое перенаправление находится в том же домене, что и текущий документ, будет возвращено время, когда последнее перенаправление завершило прием данных. В других случаях он вернет 0)
fetchStart Когда браузер инициирует запрос ресурсов, при наличии кеша возвращает время начала чтения кеша
domainLookupStart Время начала запроса DNS. Если запрос не инициирует DNS-запрос, например, поддержание активности, кеширование и т. д., вернуть fetchStart.
domainLookupEnd Время окончания DNS-запроса. Если DNS-запрос не инициирован, то же, что и выше
connectStart Время начала установления TCP-запроса. domainLookupEnd возвращается, если запрос активен, кэширован и т. д.
(secureConnectionStart) Если выполняется TLS или SSL, вернуть время рукопожатия
connectEnd Время завершения TCP-соединения. Если это keep-alive, cache и т. д., то же, что и connectStart
requestStart Время, когда был инициирован запрос
responseStart Время, когда сервер начал отвечать
domLoading Судя по картинке, пора начинать рендерить дом, подробности неизвестны
domInteractive Неизвестно
domContentLoadedEventStart Время запуска события DomContentLoadedEvent.
domContentLoadedEventEnd Время окончания события DomContentLoadedEvent
domComplete — время завершения рендеринга dom, как видно из рисунка, подробности неизвестны.
время загрузки триггера loadEventStart, если нет, вернуть 0
loadEventEnd Время выполнения события загрузки, если нет, вернуть 0
unloadEventStart, когда срабатывает событие выгрузки
unloadEventEnd Время выполнения события выгрузки

Что касается нашей веб-производительности, параметры времени, которые мы будем использовать:

Время разрешения DNS: domainLookupEnd - domainLookupStart
Время установления TCP-соединения: connectEnd - connectStart
Время белого экрана: responseStart - navigationStart
время завершения рендеринга dom: domContentLoadedEventEnd — navigationStart
Время загрузки страницы: loadEventEnd - navigationStart

На основе этих временных параметров мы можем определить, какой этап влияет на производительность.

2.6 Захват пакетов

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

Здесь я рекомендую инструмент для захвата пакетовcharles.

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

2.7.1 Pingdom

2.7.2 Load Impact

2.7.3 WebPage Test

2.7.4 Octa Gate Site Timer

2.7.5 Free Speed Test

3. Оптимизация

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

3.1 tree shaking

Китайский (дрожание дерева), важная часть оптимизации сборки веб-пакета. Встряхивание дерева используется для очистки некоторого бесполезного кода в нашем проекте, и оно основано на синтаксисе модуля в ES.

Например, при ежедневном использовании lodash

import _ from 'lodash'

Если ссылка на библиотеку lodash указана выше, весь пакет lodash будет введен в наш пакет пакетов при сборке пакета.

import _isEmpty from 'lodash/isEmpty';

Если ссылка на библиотеку lodash указана выше, только метод isEmpty будет извлечен и вставлен в наш пакет пакета при сборке пакета.

Это значительно уменьшит размер нашего пакета. Поэтому при ежедневном цитировании сторонних библиотек нужно обращать внимание на способ импорта.

Как включить встряхивание дерева

Tree-shaking поддерживается по умолчанию в webpack4.x. Используйте встряхивание дерева в webpack2.x:портал

3.2 split chunks

Китайский (субподряд)

Ничего не настраивая, webpack 4 разумно сделает за вас подпакет кода. Файлы, от которых зависит входной файл, упаковываются в main.js, а сторонние пакеты размером более 30 КБ, такие как echarts, xlsx, dropzone и т. д., упаковываются в отдельные пакеты.

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

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

• Является ли новый чанк общим или модулем из node_modules
• Размер нового фрагмента больше 30 КБ перед сжатием.
• Количество одновременных запросов на загрузку чанков по запросу меньше или равно 5
• Количество одновременных запросов при первоначальной загрузке страницы меньше или равно 3

大家可以根据自己的项目环境来更改配置。 Код конфигурации выглядит следующим образом:

splitChunks({
  cacheGroups: {
    vendors: {
      name: `chunk-vendors`,
      test: /[\\/]node_modules[\\/]/,
      priority: -10,
      chunks: 'initial',
    },
    dll: {
      name: `chunk-dll`,
      test: /[\\/]bizcharts|[\\/]\@antv[\\/]data-set/,
      priority: 15,
      chunks: 'all',
      reuseExistingChunk: true
    },
    common: {
      name: `chunk-common`,
      minChunks: 2,
      priority: -20,
      chunks: 'all',
      reuseExistingChunk: true
    },
  }
})

Проекты, не использующие версию webpack4.x, все равно могут проходитьнагрузка по требованиюВ виде субподряда наши пакеты разбросаны, а производительность загрузки улучшена.

Загрузка по требованию также была одним из важных способов субподряда в прошлом.

Вот очень хорошая статья рекомендуется:Как webpack использует загрузку по запросу

3.3 Распаковка

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

Потому что эти плагины "разобраны". А не играть вдвоем в связке. Вместо этого он размещается на CDN. Ниже я привожу пример для пояснения.

Предположение: первоначальный пакет пакетов имеет размер 2M, и запрос на включение выполняется за один раз. Разделить на пакет (1M) + React Bucket (CDN) (1M) для двух одновременных запросов на вытягивание.

С этой точки зрения режим 1+1 вытягивает ресурсы быстрее.

Иными словами, в случае полного развертывания проекта пакетный пакет будет извлекаться каждый раз при его развертывании. Скорее пустая трата ресурсов. Метод React Bucket может ударить по сильному кешу, таким образом, даже если он полностью развернут, вам нужно только повторно вытащить пакет 1M слева, экономя ресурсы сервера. Оптимизирована скорость загрузки.

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

3.4 gzip

После того, как сервер настроен на сжатие gzip, размер ресурса можно значительно уменьшить.

Метод настройки Nginx

http {
  gzip on;
  gzip_buffers 32 4K;
  gzip_comp_level 6;
  gzip_min_length 100;
  gzip_types application/javascript text/css text/xml;
  gzip_disable "MSIE [1-6]\.";
  gzip_vary on;
}

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

3.5 Сжатие изображения

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

Как мы можем сжимать изображения, если у компании нет инструмента для работы с картами? Я рекомендую несколько способов, которые я обычно использую

• Интеллектуальное сжатие карты(Baidu трудно найти официальный сайт, бесплатный, пакетный, простой в использовании)
• tinypng(бесплатно, пакетно, блокировка скорости)
• Инструменты Fireworks сжимают пиксели и размеры (сделай сам, освои масштаб)
• Найдите пользовательский интерфейс и отправьте его вам после сжатия.

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

3.6 Сегментация изображения

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

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

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

3.7 sprite

Юг называется картой спрайтов, а север — картой спрайтов. Это явление очень интересно.

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

Какая польза от этого? Давайте сначала популяризируем правило

Когда браузер запрашивает ресурсы, существует максимальное ограничение параллелизма при запросе ресурсов с одного и того же исходного доменного имени.Chrome — 6. Например, если у вас на странице есть 10 маленьких изображений одного и того же доменного имени CDN, вам нужно инициировать 10 запросы на их вытягивание. Дважды одновременно. После возвращения первого параллельного запроса инициируется второй параллельный запрос.

Если вы объедините 10 маленьких картинок в одну большую, вы сможете получить ресурсы 10 маленьких картинок одним запросом. Уменьшите нагрузку на сервер, уменьшите параллелизм и сократите количество запросов.

Пример спрайта прилагается.

3.8 CDN

В китайском (Content Delivery Network) сервер централизован, а CDN «децентрализован».

В проекте много чего размещено на CDN, например: статичные файлы, аудио, видео, js ресурсы, картинки. Так почему же использование CDN ускоряет загрузку ресурсов?

Возьмем простой пример:

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

Ты в порядке.

Поэтому рекомендуется размещать статические ресурсы на CDN, что может ускорить загрузку ресурсов.

3.9 Ленивая загрузка

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

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

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

Как использовать ленивую загрузку?

• Ленивая загрузка изображения
• layzr.js

3.10 iconfont

Китайский (таблица шрифтов) сейчас более популярен. Есть несколько преимуществ использования диаграммы шрифтов

• вектор
• Легкий
• легко изменить
• Не занимает запросы ресурсов изображения.

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

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

3.11 Логический обратный сдвиг

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

Порядок запросов без логической обратной обработки выглядит так

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

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

Оптимизированный порядок выглядит следующим образом.

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

3.12 Алгоритмическая сложность

В сценариях приложений с большим объемом данных необходимо обратить внимание на проблему сложности алгоритма.

Вы можете обратиться к этомуАнализ сложности алгоритмов JavascriptЭта статья.

Например, из индикаторов выполнения Javascript, проанализированных выше с помощью Performance, вы можете сделать вывод, насколько эффективно выполняется ваш код.Если время выполнения слишком велико, вам следует подумать, следует ли оптимизировать сложность.

При выборе времени для пространства и пространства для времени выбор следует делать согласно бизнес-сценарию.

3.13 Рендеринг компонентов

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

Старомодная тема, есть несколько способов оптимизировать отрисовку компонентов.

• Управление циклом объявления — например, shouldComponentUpdate реакции для управления рендерингом компонента.
• API предоставлено официальным сайтом - PureComponent
• Параметры, управляющие вводимыми компонентами
• Назначение уникального ключа компонента

Ненужный рендеринг — это огромная потеря производительности.

3.14 node middleware

Китайский (промежуточное ПО узла)

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

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

3.15 web worker

Роль Web Worker заключается в создании многопоточной среды для JavaScript, позволяющей основному потоку создавать рабочие потоки и назначать последним некоторые задачи для выполнения. Пока работает основной поток, рабочий поток работает в фоновом режиме, не мешая друг другу. Подождите, пока рабочий поток завершит задачу вычисления, а затем верните результат в основной поток. Преимущество этого в том, что некоторые ресурсоемкие задачи или задачи с высокой задержкой ложатся на рабочий поток, а основной поток (обычно отвечающий за взаимодействие с пользовательским интерфейсом) будет работать плавно и не будет блокироваться или замедляться.

Разумные и практичные веб-работники могут оптимизировать сложные вычислительные задачи. Вот вступительная статья Руан Ифэн:портал

3.16 Кэш

Принцип кэширования заключается в более быстром чтении и записи носителя + сокращение операций ввода-вывода + сокращение вычислений ЦП = оптимизация производительности. Первый закон оптимизации производительности: отдавайте приоритет использованию кеша.

Основными средствами кэширования являются: кеш браузера, CDN, обратный прокси, локальный кеш, распределенный кеш и кеш базы данных.

3.17 Рендеринг графического процессора

Каждая веб-страница содержит в той или иной степени анимацию CSS. Обычно простая анимация мало влияет на производительность. Однако, когда дело доходит до более сложной анимации, неправильное обращение с ней может сделать проблемы с производительностью очень заметными.

Opera, такая как Chrome, FireFox, Safari, IE9+ и последние версии, поддерживают ускорение графического процессора, которое включается, когда они обнаруживают, что определенные правила CSS применяются к элементу DOM на странице.

Хотя мы можем не захотеть применять 3D-преобразования к элементам, мы все же можем включить 3D-движок. Например, мы можем использоватьtransform: translateZ(0)чтобы включить ускорение графического процессора.

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

3.18 Кэширование Ajax

После того, как данные, отправленные Ajax, будут успешно отправлены, чтобы улучшить скорость отклика и удобство использования страницы, запрошенный URL-адрес и возвращенный результат ответа будут сохранены в кеше, и при следующем вызове Ajax для отправки того же запроса (URL и параметры точно такие же), он будет брать данные прямо из кеша.

При выполнении Ajax-запроса вы можете максимально использовать метод get, чтобы кеш клиента можно было использовать для повышения скорости запроса.

3.19 Resource Hints

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

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

Идеи Resource Hints заключаются в следующем:

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

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

3.20 SSR

Процесс рендеринга завершается на стороне сервера, а конечная HTML-страница результата рендеринга отправляется клиенту по HTTP-протоколу, который считается «изоморфным» или «универсальным». страницы подробностей, рекомендуется выбрать рендеринг на стороне сервера.

В дополнение к SEO, рендеринг на стороне сервера (SSR) часто используется для оптимизации первого экрана, чтобы ускорить первый экран и улучшить взаимодействие с пользователем. Однако к серверу предъявляются требования, а по сети передается большой объем данных, что занимает часть вычислительных ресурсов сервера.

Nuxt.js от Vue и next.js от React — это методы рендеринга на стороне сервера.

3.21 UNPKG

UNPKG — это сайт, который предоставляет пакеты npm для ускорения CDN, поэтому некоторые фиксированные зависимости могут быть записаны в html-шаблоны для повышения производительности веб-страниц. Во-первых, эти зависимости нужно объявить как внешние, чтобы эти ресурсы не загружались из node_modules при упаковке webpack.Конфигурация следующая:

externals: { 'react': 'React' }

Во-вторых, вам нужно написать зависимые ресурсы в шаблоне html, этот шаг необходимо использоватьhtml-webpack-plugin. Вот пример:

<% if (htmlWebpackPlugin.options.node_env === 'development') { %>
  <script src="https://unpkg.com/react@16.7.0/umd/react.development.js"></script>
<% } else { %>
  <script src="https://unpkg.com/react@16.7.0/umd/react.production.min.js"></script>
<% } %>

Этот код необходимо внедрить в node_env, чтобы вы могли получать более понятные сообщения об ошибках во время разработки. Вы также можете выбрать еще несколько автоматических библиотек, которые помогут нам завершить этот процесс, напримерwebpack-cdn-plugin,илиdynamic-cdn-webpack-plugin.

4. Резюме

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

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