Сообщите начальству, моя страница действительно быстрее конкурентов!

внешний интерфейс

| Введение «Искусство войны Сунь-Цзы: заговор»: «Познай врага и познай себя, и тебе не будет угрожать опасность в сотне сражений». видите, что они (конкурирующие продукты) могут достичь этого, почему вы не можете? Посмотрите, какие они (конкуренты) быстрые, посмотрите на себя, почему они такие медленные?

«Искусство войны Сунь-Цзы: заговор»: «Познай врага и познай себя, и тебе не будет угрожать опасность в сотне сражений». (конкурирующие продукты) могут достичь этого, почему вы не можете? Посмотрите, какие они (конкуренты) быстрые, посмотрите на себя, почему они такие медленные? Всякий раз, когда я сталкиваюсь с такого рода обвинениями, я часто могу только задуматься, я могу только сказать продукт, наша страница очень быстрая, очень быстрая, видите ли, мой отчет. Продукты всегда говорят в это время, не слушай, не слушай, я не слушаю. Если вы не можете предоставить объективные данные о конкурирующих продуктах, то в глазах продукта такая болтовня может быть лишь развитием вашего собственного вдовьего менталитета. Каждую ночь, когда никто не сталкивался с этой проблемой, мне приходилось молча открывать браузер.

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

Как объективно отслеживать впечатления от страницы

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

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

Интуитивно работу со страницей можно разделить на следующие части:

Опыт рендеринга

Этот опыт является самым простым, сколько времени требуется пользователям, чтобы открыть страницу, и сколько времени требуется пользователям, чтобы открыть вашу страницу. Что это за опыт, когда страница открыта? Это белый экран, это прогрессивная загрузка, это диаграмма хризантемы или это каркасный экран? Разный опыт дает пользователям разные интуитивные ощущения, как объективно оценивать эти чувства?

Интерактивный опыт

Разнообразные интерактивные страницы могут быть своевременно? Каждое взаимодействие на странице - оба для разных людей? Будьте осторожны о визуально нарушенных людям, учитывают партию клавиатуры? Каждое взаимодействие соответствует ожиданиям браузера? Сценарий на странице, есть ли опасность API? Это загружено слишком много ресурсов?

SEO

Дружелюбен ли паук страницы? Подходит ли страница для правильного дохода?

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

Самый простой способ — открыть инструменты разработчика браузера, выбрать вкладку производительности и нажать «Запись». Затем мы можем увидеть все данные, которые нам нужны. Так вот вопрос, как работает вкладка производительность? Как он получает различные данные рендеринга нашей страницы?

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

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

chrome://tracing/

Нажмите на запись, и вы увидите окно выбора, как показано ниже.

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

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

Конечно, в дополнение к использованию протокола chrome devtools в этой форме, мы также можем использовать nodejs для его получения. после всего,Anything that can be Written in JavaScript, will Eventually be Written in JavaScript. Наиболее распространенными библиотеками nodejs являютсяchrome-remote-interface(далее сокращенно cri для удобства), конечно, если вы говорите, что я не хочу, я не хочу js, то это не невозможно.здесь, выберите практику, которая вам нравится. Любой typescript, go, python, ruby ​​и, конечно же, php, который нам всем нравится.

Что ж, как фронтенд-инженер, давайте честно использовать nodejs. Хотя typescript очень хорош, я выбираю js. Давайте перейдем к Kangkang. Как нам объединить различные инструменты, чтобы сделать их одним. А как насчет мониторинга страниц, который можно использовать с помощью инструментов?

Для конкретного использования cri, пожалуйста, обратитесь кэта вики

Инструментальный мониторинг страниц

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

Через chrome-launcher подтягиваем хром, после чего получаем порт, который нам нужно отлаживать.Затем берем этот порт и с помощью cri получаем нужный нам chrome-debugger-Protocol.После получения конкретного протокола заходим Канкан, что у меня есть:

{"pid":8784,"tid":8728,"ts":4123614461,"ph":"X","cat":"ipc,toplevel","name":"ChannelMojo::OnMessageReceived","args":{"class":50,"line":101},"dur":2,"tdur":1,"tts":22268542},
{"pid":8784,"tid":8728,"ts":4123615131,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../content/browser/renderer_host/media/media_stream_manager.cc","src_func":"SendMessageToNativeLog"},"dur":4,"tdur":4,"tts":22268810},
{"pid":8784,"tid":8728,"ts":4123615138,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../ipc/ipc_channel_proxy.cc","src_func":"Send"},"dur":8,"tdur":8,"tts":22268817},
{"pid":8784,"tid":8788,"ts":4123551336,"ph":"X","cat":"toplevel","name":"MessageLoop::RunTask","args":{"src_file":"../../base/trace_event/trace_log.cc","src_func":"SetEnabled"},"dur":130,"tdur":130,"tts":64927429},
{"pid":8784,"tid":8788,"ts":4123551358,"ph":"I","cat":"disabled-by-default-devtools.timeline","name":"TracingStartedInBrowser","args":{"data":{"frameTreeNodeId":101,"persistentIds":true,"frames":[{"frame":"7CB62147F076D4C38B128F711003B9E9","url":"https://www.huya.com/badaozongcai","name":"201905171157120c93bb02c2ca5f727133a5547b2a8d4000016f6b3731c1440","processId":5368}]}},"tts":64927451,"s":"t"},

Звучит знакомо? Сохраненный в Chrome файл profile.json имеет тот же формат, что и содержимое выше. Итак, что же означает этот большой кусок json? В это время я возьму свой родовойДокументация по формату событий трассировки ChromeВозьмите его для вас. Я верю, что после прочтения вы обязательно завопите: «Что за черт!» Такой кривой документ, все просто. Базовый принцип работы браузера очень сложен, а вызов различных классов и компонентов затрудняет отслеживание событий браузера. Конечно, если вы хотите понять принцип работы браузера с картинками и текстами, обратитесь к"жизнь пикселя".

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

Ответ - конечно есть! Команда Google Chrome открыла инструмент анализа на основе машинописного текста Lighthouse, который может помочь нам быстро проанализировать качество страниц.

Что такое Маяк

lighthouseВот как он представился:

Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.

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

Как работает маяк

Вместо того, чтобы просить меня повторить вышесказанное, что Кан Кан Лайтхауз говорит о себе?Принцип работыиз:

Судя по приведенному выше рисунку и предыдущей статье, я считаю, что у всех есть очень глубокое понимание того, как реализован Lighthouse.Благодаря ридми Lighthouse на github я считаю, что каждый может легко запустить Lighthouse. Я не буду здесь вдаваться в подробности. Ничего, кроме установки npm, маяка npx и так далее.

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

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

Вторичное руководство по разработке Lighthouse

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

+--------------+      +-------------+        +------------+       +-------------------+
|              |      |             |        |            |       |                   |
|  connecting  +----->+  collecting +------->+  auditing  +------>+ report generation |
|              |      |             |        |            |       |                   |
+--------------+      +-------------+        +------------+       +-------------------+
    建立连接             收集日志              分析，审计               生成报告

Поймите процесс, мы приходим на то, чтобы понять некоторые основные концепции, которые в маяке есть несколько особенно важных концепций:

  • Драйвер: разъем - это кри, упомянутый выше. Используется для ссылки и получения протокола chrome devtools
  • сборщики: сборщики, классифицируют и собирают журналы событий трассировки.
  • аудиты: проведите аудит собранных журналов и поставьте оценку в конце.
  • metic: Анализ и расчет содержимого журнала. Обычно класс инструментов, вызываемый аудиторами

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

разработка плагинов

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

-
|-your_audit.js
|-plugin.js
|-package.json

Имея всего три файла, вы можете реализовать плагин маяка самостоятельно, не правда ли, это очень просто!!!

package.json — необходимый файл для пакета npm, нам нужно указать main в package.json на наш plugin.js.

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

//plugin.js
module.exports = {
  audits: [{
    path: 'path/to/your/aduit',
  }],
  category: {
    title: 'My Plugin',
    description: 'my plugin.',
    auditRefs: [
      {id: 'your_audit', weight: 1}, //这里需要注意，id和文件名一直
      {id: 'meta-description', weight: 1}, // lighthourse的默认审计项目
    ],
  },
};

Затем в файле аудита вы можете определить свои собственные правила аудита, например:

//my-audit.js
const Audit = require('lighthouse').Audit;

class myAudit extends Audit {
  static get meta() {
    return {
      id: 'my-aduit',
      title: '展示的title',
      failureTitle: '未通过的时候，展示的文案',
      description: '补充的一点的描述内容',

      // 你所需要的收集内容
      requiredArtifacts: ['LinkElements'],
    };
  }

  static audit(artifacts) { // 上面指定的内容，将会被传递到这个函数中
   // 处理你的逻辑
    return {
      score: 0, // 外显的分数以及决定是否算通过
      displayValue: '显示的内容',
    };
  }
}

module.exports = myAudit;

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

npx lighthouse https://example.com --plugins=my-plugin --view

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

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

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

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

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

волшебный исходный код

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

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

——
├─assets
├─build
├─clients // 浏览器中的展示逻辑
│  └─extension // 扩展
├─docs // 文档
├─lighthouse-cli // 命令行工具
│  ├─commands // 命令
│  └─test 
├─lighthouse-core // 核心逻辑
│  ├─audits
│  ├─computed
│  │  └─metrics
│  ├─config
│  ├─gather
│  │  ├─connections
│  │  └─gatherers
│  ├─lib // 工具库
│  ├─report // 报告生成器
│  │  └─html
│  │      └─renderer
│  └─test // 测试用例
├─lighthouse-logger // 日志收集
├─lighthouse-viewer // 报告渲染工具
└─types // 类型文件

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

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

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

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

Как быть более объективным?

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

  • Облачное развертывание

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

  • Развертывание в нескольких местах

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

  • многократная операция

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

  • запустить несколько раз

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

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

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

Подпишитесь на официальный аккаунт [IVWEB Community], чтобы получать свежие статьи каждую неделю, ведущие к вершине жизни!

Категории