Промежуточная платформа для событий vivo Wukong — оптимизация загрузки событий H5

JavaScript

Эта статья была впервые опубликована на официальном аккаунте Vivo Internet Technology WeChat.
Связь:Tickets.WeChat.QQ.com/Yes/6gt VR0, что VN…
Автор: Команда R&D станции Wukong

[Wukong Activity Middle Stage] серия замечательных статей в прошлом:

1. Предпосылки

Благодаря предыдущей серии статей на мероприятии Wukong у всех есть определенное понимание технических решений, таких как микрокомпоненты и динамическая компоновка. В этой статье мы познакомим вас с тем, как оптимизировать производительность Wukong H5.

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

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

Во-вторых, процесс оптимизации

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

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

1. Оптимизация сетевого уровня

(1) Обработка DNS: увеличить dns-prefetch

Первый процесс разрешения DNS и поиска веб-сайта браузером выглядит следующим образом: кеш браузера >> системный кеш >> кеш маршрутизатора >> кеш DNS провайдера >> рекурсивный поиск.

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

Чтобы помочь браузерам предварительно разрешить определенные доменные имена, мы добавили тег dns-prefetch в html-документ онлайн-мероприятия. После добавления этого тега шаги парсинга браузера выглядят следующим образом:

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

<meta http-equiv="x-dns-prefetch-control" content="on" />

**Шаг 2.** Используйте тег ссылки в заголовке страницы, чтобы принудительно выполнить предварительное разрешение DNS:

<link rel="dns-prefetch" href="//topicstatic.vivo.com.cn" />

Когда Wukong запускает ресурсы H5, ему необходимо генерировать разные адреса dns-prefetch в соответствии с разными регионами.Новая логика для компиляции активного тега ссылки на леса выглядит следующим образом:

<% if (国内活动) {%>
  <link rel="dns-prefetch" href="//topic.vivo.com.cn">
  <link rel="dns-prefetch" href="//cmsapi.vivo.com.cn">
  <link rel="dns-prefetch" href="//topicstatic.vivo.com.cn">
  <% } else if(印度活动) {%>
  <link rel="dns-prefetch" href="//in-goku.vivoglobal.com">
  <link rel="dns-prefetch" href="//topicstatic.vivo.com.cn">
  <link rel="dns-prefetch" href="//in-gokustatic.vivoglobal.com">
  <% } else { %>
  <link rel="dns-prefetch" href="//asia-goku.vivoglobal.com">
  <link rel="dns-prefetch" href="//asia-gokustatic.vivoglobal.com">
  <link rel="dns-prefetch" href="//asia-wukongapi.vivoglobal.com">
<% } %>

(2) Оптимизация распространения CDN

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

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

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

Конфигурация кэша ресурсов CDN выглядит следующим образом:

Вуконг загрузил статические ресурсы темы H5 в CDN, внеся следующие улучшения:

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

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

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

Цель отказа от кэширования файла записи HTML — предотвратить кэширование политики клиентом, что приведет к тому, что основной ресурс записи не будет обновляться, а онлайн-обновление не удастся.

(3) HTTP/2

HTTP/2 определяется как:

(Протокол передачи гипертекста версии 2, первоначально названныйHTTP 2.0), именуемыйh2(зашифрованное соединение на основе TLS/1.2 или выше) илиh2c(незашифрованное соединение)[1],ДаHTTPВторая основная версия протокола, используемая дляВсемирная сеть.

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

Способ открытия HTTP2.0 следующий:

server {  
 listen        443 **ssl** **http2**;  
  server_name   yourdomain;
  ……  
  ssl          on**;
  …… 
}

Включите прослушивание HTTP 2:

listen 443 ssl http2;

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

(4) Динамическое сжатие шрифтов

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

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

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

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

Далее мы сосредоточимся на схеме сжатия шрифтов Wukong, основанной на бизнес-сценариях.Основные требования к сжатым шрифтам:Файлы шрифтов можно сжимать, а текстовое содержимое можно динамически заменять для сжатия.

Основываясь на динамической упаковке и онлайн-методе микрокомпонентов Wukong, мы решили использоватьfontminдля завершения динамического сжатия шрифтов.

Динамическое сжатие шрифтов делится на следующие этапы:

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

const request = require('request')
request(url,  (error, response, data) => {
  if (error) {                  
    console.error(err);
    return
  }
  const res = JSON.parse(data)
  if (res.code === 0) {
    //获取专题配置数据
    const config = JSON.parse(URLDecode(res.data.config))
    const pages = config.pages
    let str = ''
    const familyList = new Set()
    pages.forEach(page => {
      const items = page.items
      items.forEach(item => {
        //根据配置,拼接需加载字体的字符串和字体类型
        if (item.pluginInfo.enName === 'site-text') {
          str += item.pluginConfig.pureText
          familyList.add(item.pluginConfig.typeFace)
        }
      })
    });
    //处理字体
    handleFont(str, familyList)
  }
});

**Второй шаг** — пройтись по списку типов шрифтов familyList и использовать fontmin для сжатия файлов шрифтов. Этот шаг требует, чтобы мы добавили локальные файлы шрифта в скаффолд компиляции. При сжатии вам необходимо сгенерировать соответствующий файл css через плагин webpack:

Логика обработки динамического сжатия шрифта:


const compressFont = (fontText, fontName) => {
  const srcPath = `dist/${siteId}/font/${fontName}.ttf`; 
  const destPath = `dist/${siteId}/compressFont`;   

  const fontmin = new Fontmin()
    .src(srcPath)               // 输入配置
    .use(Fontmin.glyph({        // 字形提取
      text: fontText            // 动态注入文字
    }))
    .use(Fontmin.ttf2eot())     // eot转换
    .use(Fontmin.ttf2woff())    // woff转换    
    .use(Fontmin.ttf2svg())     // svg转换
    .use(Fontmin.css({
      fontPath: `/compressFont/`,
      fontFamily: fontName,  
    }))       
    .dest(destPath);            // 输出文件

  fontmin.run(function (err, files, stream) {
    if (err) {                  
      console.error(err);
      return
    }
    // 读取生成后的对应的 css 文件内容并合成
    const fontCss = fs.readFileSync(path.join(__dirname, `../dist/${siteId}/compressFont/${fontName}.css`)).toString()
    fontStyleStr += fontCss
    loadHtml(fontStyleStr)
  })
}

const handleFont = (fontText, familyList) => {
  familyList.forEach(name => {
    compressFont(fontText, name)
  })
}

2. Оптимизация ресурсов

(1) Ленивая загрузка картинок

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

Общая форма ленивой загрузки:

  1. Откройте домашнюю страницу, проведите пальцем по странице

  2. Ленивая загрузка изображений для отображения изображений по умолчанию

  3. Замените изображение по умолчанию реальным изображением

Согласно существующему стеку технологий Wukong, мы выбираем vue-lazyload для поддержки загружаемого изображения битового компонента:

  • Встроенная поддержка vue, все компоненты доступны после расширения платформы

  • Удобная и быстрая императивная разработка, src тега img изменен на v-lazy для реализации ленивой загрузки картинок

  • Функция, как и ожидалось, поддерживает ленивую загрузку фонового изображения и динамическую модификацию URL-адреса изображения в webp.

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


<template>
  <div>
    <img v-lazy="imgUrl" />
    <div v-lazy:background-image="imgUrl"></div>

    <!-- with customer error and loading -->
    <img v-lazy="imgObj" />
    <div v-lazy:background-image="imgObj"></div>

    <!-- Customer scrollable element -->
    <img v-lazy.container="imgUrl" />
    <div v-lazy:background-image.container="img"></div>

    <!-- srcset -->
    <img
      v-lazy="'img.400px.jpg'"
      data-srcset="img.400px.jpg 400w, img.800px.jpg 800w, img.1200px.jpg 1200w"
    />
    <img
      v-lazy="imgUrl"
      :data-srcset="imgUrl' + '?size=400 400w, ' + imgUrl + ' ?size=800 800w, ' + imgUrl +'/1200.jpg 1200w'"
    />
  </div>
</template>
<script>
export default {
  data() {
    return {
      imgObj: {
        src: 'http://xx.com/logo.png',
        error: 'http://xx.com/error.png',
        loading: 'http://xx.com/loading-spin.svg',
      },
      imgUrl: 'http://xx.com/logo.png', // String
    }
  },
}
</script>

(2) Сжатие изображения

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

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

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

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

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

Мы можем посмотреть на следующий набор данных, чтобы увидеть эффект сжатия с потерями webp:

Сжатие с потерями Webp (коэффициент качества 75%).

await execFileSync(cwebp, ['-q', '75', filePath, '-o', webpPath]);

После преобразования Wukong загрузит как исходное изображение, так и преобразованное изображение webp в CDN для создания резервной копии.В реальных бизнес-сценариях вы можете выбрать, использовать ли изображения Webp в соответствии с вашими потребностями.

На изображении ниже показано сжатие Webp до и после сжатия, а изображение справа показывает сжатое изображение с уменьшенным размером изображения с 215 КБ до 17 КБ.

Вуконг также столкнулся с различными проблемами при использовании сжатия Webp, а именно:

  • Почему Goku выбрал качество сжатия 75%?

  • Какие характеристики изображений не подходят для сжатия Webp?

  • Некоторые изображения становятся больше после сжатия

Последующая статья, «Мероприятия WUKONG в Тайване, основанном на WebP Pictures Эффективная схема загрузки» предоставит подробное описание того, как схема сжатия Wukong WebP с точки зрения платформы.

(3) Избегайте запросов опций между доменами

Тема Wukong H5 использует схему разделения внешнего и внутреннего интерфейса.Доменное имя сервера несовместимо с доменным именем темы, на которое будет влиять политика браузера о том же происхождении.

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

Вообще говоря, почтовый запрос с использованием application/json неизбежно приведет к запросу OPTION.

Используется для получения параметров связи, поддерживаемых целевым ресурсом. Клиенты могут использовать метод OPTIONS для определенного URL-адреса или для всего сайта (установив для URL-адреса значение «*»).

существуетCORSВ вы можете инициировать запрос предварительной проверки, используя метод Options, чтобы определить, может ли фактический запрос быть принят сервером. Заголовок Access-Control-Request-Method в сообщении с запросом на предварительную проверку информирует сервер о необходимости действительного запроса используемого метода HTTP; заголовок Access-Control-Request-HEADERS сообщает, что сервер фактически запрашивает настраиваемый заголовок пользовательского заголовка. На основе информации, полученной из запроса предварительной проверки, сервер определяет, принят ли следующий фактический запрос.

Интересно, что подробности темы GET-интерфейс, почему GET-запрос также инициирует предварительную проверку опции?

Причина этого начинается с простых запросов и сложных запросов.Кросс-доменные запросы делятся на два типа: простые и сложные:

Простой запрос:

Метод запроса является одним из следующих:

HEAD

GET

POST

Заголовки HTTP-запроса могут содержать только следующую информацию:

Accept

Accept-Language 

Content-Language 

Last-Event-ID 

Content-Type, но только один из следующих

application/x-www-form-urlencoded 

multipart/form-data 

text/plain

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

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

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

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

3. Оптимизация выполнения рендеринга

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

При изменении элемента DOM браузер повторно выполнит генерацию и отрисовку дерева рендеринга, которые мы называем перекомпоновкой и перерисовкой.

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

(1) Избегайте перестановки

Схема структуры браузера:

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

(1) Добавить или удалить узлы DOM;

(2) отображение:нет (переупорядочить и перерисовать), видимость:скрыть (перерисовать);

(3) Переместить элементы на странице;

(4) Изменить размер элемента (ширину, высоту, внутренние и внешние поля, границы и т. д.);

(5) Пользователь изменяет размер окна, прокручивает страницу и т. д.;

(6) Первоначальный рендеринг страницы;

(7) Измените содержимое элемента (текст или изображения и т. д.).

offsetTop, offsetLeft,...
scrollTop, scrollLeft, ...
clientTop, clientLeft, ...
getComputedStyle() (currentStyle in IE)

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

document.body.style.minWidth = '12OOpx'
document.body.style.overflow = 'hidden'
//获取某div的偏移量
document.querySelector('xxx').offsetTop

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

(2) Эффективно используйте жизненный цикл Vue.

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

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

Мы помещаем действие данных инициализации активности в этап beforeCreate, а работу и мониторинг dom монтируем в Mounted.

{
  beforeCreate(){
    fetch({
      url: topicUrl,
      params: {
        //...
      }
    }).then(res=>{
      //数据处理
      //...
    })
  },
  mounted() {
    // global listener
    window.addEventListener('xxx');
    // get dom element by refs
    this.$refs.xxx
    // get dom element use native api
    document.querySelector
  }
}

Для браузера весь процесс рендеринга еще не начался или готов начаться Для Vue экземпляр не был инициализирован, наблюдатель данных и событие/наблюдатель не вызывались В это время время запроса страницы данные инициализации относительно зрелые.

(3) Уменьшить время белого экрана

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

Время белого экрана — это время с момента, когда браузер отвечает на ввод пользователем URL-адреса, до момента, когда браузер начинает отображать содержимое.

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

  • Скелетный экран, эффект перехода HTML-рендеринга напрямую

  • Изменить порядок импорта стороннего JS

  • Используйте SplitChunksPlugin для разделения общего кода;

  • Используйте динамический импорт, чтобы разделить код страницы и уменьшить размер JS в верхней части страницы.

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

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

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

animation: loading 1s linear 300ms infinite;
···
@keyframes loading{
  from {
    opacity: 1;
  }
  to {
    opacity: 1;
  }
}

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

3. Результаты оптимизации

1. Сравнение данных до и после оптимизации одной и той же темы

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

2. Эффект домашней деятельности

В той же теме настройки:

3. Эффект зарубежной деятельности

В той же теме настройки:

В-четвертых, сбор данных о производительности

1. Общие индикаторы

Что касается индикаторов, то в отрасли существует множество решений и данных:

  • время загрузки страницы

  • Время загрузки выше сгиба

  • Продолжительность готовности дома

  • Дом Полная продолжительность

  • Время рендеринга главной страницы

  • Время рендеринга контента главной страницы

  • Эффективное время рендеринга главной страницы

  • .......

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

2. Как рассчитать

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

Время белого экрана:

время белого экрана= время начала рендеринга (время первого байта + время завершения загрузки HTML) = responseStart - navigationStart

время первого рендера= полная продолжительность регистрации события = loadEventEnd - navigationStart

время отрисовки страницы= Получить данные в конец загрузки = loadEventEnd - fetchEnd (самозапись)

3. Метод отчетности

Что касается метода представления данных о производительности, платформа использует sendBeacon для сообщения неблокирующих данных о производительности.

Метод navigator.sendBeacon() можно использовать для передачиHTTPАсинхронно передает небольшие объемы данных на веб-сервер.

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

function stat() {
  navigator.sendBeacon('/path', analyticsData)
}

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

V. Мышление и мировоззрение

Одновременно с вышеупомянутыми исследованиями мы также проводим исследование тематических решений ***, Miaokai и CSR, постоянно пытаясь улучшить опыт H5 и стремясь к совершенству.

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

6. Ссылки

  1. Developers.Google.com/Web/Женщины большие…

  2. nuggets.capable/post/684490…