| guide language, sun tzu for tapping “:” know both sides, fight.” When pk with the product, the product most often say a word is, you see them (competing products) can achieve, why can’t you? Look at them so fast, look at you, why so slow?
Sun Tzu’s Art of War: “Know the enemy, know yourself, and fight a hundred battles without danger of defeat.” When pk with the product, the product most often say a word is, you see them (competing products) can achieve, why can’t you? Look at them so fast, look at you, why so slow? Every time I encounter such censure, I often can only fall into a meditation, I can only tell the product, our page is fast, really fast, you see, my report. The product always says at this time, don’t listen or don’t listen, I don’t listen. If you can’t come up with objective data on competing products, then such nonsense in the product’s view is developing your own widow mentality. In every deserted night, I had to silently open the browser when I encountered this problem.
Therefore, how to make the monitoring objective, independent, third party, becomes very important.
How to objectively monitor the page experience
First of all, the first question from the soul is, how do you objectively evaluate your page experience? You say your page experience is awesome, your page experience is awesome? You say the page of competing products is not good, the page of competing products is really not good? Every night WITH this thought, I silently open the browser.
There are many different ways to evaluate a page objectively, based on speed, based on error rate, based on SEO… , so many evaluation criteria, how to find the best indicator of user experience? Or to put it another way, what metrics best represent the real user experience?
Intuitively, the experience of a page can be broken down into the following parts:
Apply colours to a drawing experience
This experience is the most straightforward, how long it takes the user to open the page, how long it takes the user to open your page. What is the experience of opening the page? Is it a white screen, is it progressive loading, is it a Daisy screen, is it a skeleton screen? Different experiences give users different intuitive senses. How should these senses be evaluated objectively?
Interaction experience
Are the various interactions on the page timely? Is each interaction on the page targeted at different people? Are visually impaired people taken into account? Are interactions as expected by the browser? Does the script on the page use a dangerous API? Are too many resources loaded?
SEO
Is the page spider friendly? Is the page for being able to be correctly generated?
Of course, the above list is relatively simple and only covers a part of the page, but the above has covered a lot of page information we usually need to pay attention to, so how do we get and evaluate the information?
The easiest way to do this is to open DevTools in the browser, select the Performance TAB, and click Record. Then, we can see all the data we want. So how does the Performance TAB work? How does it get the various renderings of our page?
How does the Browser performance TAB work?
It all starts with this protocol: Chrome devTools Protocol. Chrome uses this protocol to expose some of the state of the kernel and browser. The essence of the Performance TAB we use on a regular basis starts with a glorified viewer using this protocol. There are still some things that are not fully covered in Performance. If you want to learn more about the kernel, you can go to the following page
chrome://tracing/
Copy the codeClick on Record and you will see the selection box below.
This will allow you to define in more detail the kernel content that you want to monitor and understand.
Well, the nice and unfortunate thing about this is that the Tracing TAB will monitor rendering information for all current Chrome tabs. So, be careful when you use it. One more thing to note is the explosion of tracing logs. Select as few tracing items as possible so that you can protect your memory. If you have time to explore this tracing section, you will find that browsers do not behave as you might expect. 🙂
Of course, in addition to using this form to use Chrome DevTools Protocol, we can also use nodeJS to obtain. After all, Anything that can be Written in JavaScript, will Eventually be Written in JavaScript. The most common nodeJS library is chrome-remote-interface (crI for convenience), but if you say I don’t want js, I don’t want js, that’s fine. Here, pick your favorite practice. Typescript, Go, Python, Ruby, and, of course, PHP, which we all love.
So, as a front-end engineer, let’s stick to NodeJS. Typescript is great, but I’ll go with JS. How do we put together a tool that can be used as a page monitor?
Refer to this wiki for details on how to use CRI
Instrumental page monitoring
All in all, we need to have a Chrome with debugger port open. You can use a shell script to start your own, but there’s also a more elegant way: Chrome-Launcher, which means you don’t have to write a shell script to start Chrome on a quiet night:).
With Chrome-Launcher, we pull Up Chrome, and we get a debug port that we need, and then we take that port, and we use CRI to get that we need Chrome-Debugger-Protocol, and once we get the Protocol, Here’s what we got when we came to Kangkang:
{"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"},
Copy the codeIf this sounds familiar, well, the profile.json file saved in Chrome is exactly the same format as the content above. So, what does this big lump of JSON mean? At this point, I would like to show you the documentation of my ancestral Chrome Tracing Event Format. I’m sure when you’re done, you’re gonna go, “Oh, my God, what the hell is that?” Such a difficult document is ridiculously difficult. The underlying workings of browsers are very complex, and the invocation of different classes and components makes tracking browser events a difficult task. Of course, if you want to see how a browser works in graphics, check out Life of a Pixel.
If we want to programmatically and instrumentally monitor and manage the underlying rendering behavior of the browser, we can only peel out the content we need from the thick Trace Event log for statistical analysis. At this time, we will think ah, is there a god to do this thing ah, we young brother, just watch and learn?
The answer is, of course. The Google Chrome team has its own open-source typescript-based analytics tool, Lighthouse, which allows us to quickly analyze the quality of our pages.
What is the Lighthouse
Lighthouse introduces itself as follows:
Lighthouse analyzes web apps and web pages, collecting modern performance metrics and insights on developer best practices.
Lighthouse seems to me to be more of a yardstick for Google to push standards. Let the development students know what is good, what is not good, in the vast sea of people, find the right person.
How Lighthouse works
Rather than have me repeat the above, here’s what Kangkang Lighthouse itself says about how it works:
Based on the above and above, I’m sure you’ve got a pretty good understanding of how Lighthouse works, and with the Readme of Lighthouse on Github, I’m sure you’ll be able to keep it running pretty easily as well. I won’t go into it here. NPM install, NPX Lighthouse, whatever.
Once we got Lighthouse running, we got a report that looked like this:
In addition to the standards and systems provided by Lighthouse, we use our own standards and systems more often. So the question was, how do we redevelop Lighthouse? How do we build our own standard meter based on Lighthouse?
Lighthouse’s secondary development guide
Before developing Lighthouse, we looked at the basic workflow. As you can see from the picture above, Lighthouse works as follows:
+--------------+ +-------------+ +------------+ +-------------------+ | | | | | | | | | connecting +----->+ collecting +------->+ auditing +------>+ report generation | | | | | | | | | +--------------+ +-------------+ +------------+ +-------------------+ Establish a connection Collect logs, analyze logs, and generate audit reportsCopy the codeWith that flow in mind, let’s take a look at some of the basic concepts, and Lighthouse features a few particularly important concepts:
- Driver: connector, which is the CRI mentioned above. Use to link to and get chrome DevTools Protocol
- Gatherers: collects trace event logs by category
- Audits: Audits the collected logs and ends up giving out points.
- Metic: Analyze and calculate log content. Typically a utility class called by audts
Okay, so with that in mind, you should be able to build your own Lighthouse. Normally, a good framework design comes with a set of plugins that allow us to add our own logic to the architecture of the Lighthouse in a very elegant, non-intrusive way. Lighthouse is no exception. Of course, if you say, no, I don’t want it, I want it to be my own pup, there are some guidelines below.
Plug-in development
Before developing the plug-in, we need to know what the structure of our plug-in looks like. Let’s take a quick look:
-
|-your_audit.js
|-plugin.js
|-package.json
Copy the codeWith just three files, you can easily implement a lighthouse plug-in.
Package. json is a required file for an NPM package. We need to point main in package.json to our plugin.js.
As a plugin, you only need to expose one of the following objects:
//plugin.js
module.exports = {
audits: [{
path: 'path/to/your/aduit',
}],
category: {
title: 'My Plugin',
description: 'my plugin.',
auditRefs: [
{id: 'your_audit', weight: 1}, // note that id and filename are always {id:'meta-description', weight: 1}, // Lighthourse is the default audit item],},};Copy the codeThen, in the Audit file, you can define your own audit rules, as follows:
//my-audit.js
const Audit = require('lighthouse').Audit;
class myAudit extends Audit {
static get meta() {
return {
id: 'my-aduit',
title: 'Show title',
failureTitle: 'Copy presented when not approved',
description: 'Description of a supplementary point'RequiredArtifacts: ['LinkElements']}; } static audit(artifacts) {// The content specified above will be passed to this function // process your logicreturn{score: 0, // Explicit score and decide whether to count through displayValue:'What is displayed'}; } } module.exports = myAudit;Copy the codeAs we execute the lighthouse command, we need to explicitly indicate which plugin we want to use as follows:
npx lighthouse https://example.com --plugins=my-plugin --view
Copy the codeAnd then, lighthouse goes to node_modules to find the Lighthouse Plugin that you’re using.
Lighthouse has provided a demo of its own plugin that you can check out for yourself. There are also renderings of the plugin.
As you can see, developing a plugin is simple. However, it was also obvious that the plugin was a bit weak, as it could only be used to audit the information it had already collected, rather than capture more data and define what it wanted.
As a matter of fact, if I just wanted to define my own evaluation system, this would have been enough. After all, lighthouse articles provide a lot of ideas. Basically, everything you can think of that you use. If you want to know what all articles have, see here. If you want to know more about plug-in development, you can refer to here.
For people like us, who don’t like to be constrained, trying to get rid of me with something like this? No! As an adult, as a man who opens his browser in the middle of the night, I want both! Ok, so let’s see how we can hardcore re-develop Lighthouse and make it our own.
The magic to change the source code
The source code for Lighthouse is well-written and typescript enabled, making it easy to read, as well as wonderfully annotated.
Before we can redevelop Lighthouse, we need to know what the source code structure of Lighthouse looks like. Here’s what it looks like (some logic not related to mods has been removed to save space) :
- ├ ─ assets ├ ─ build ├ ─ clients / / in the browser display logic │ └ ─ the extension / / extension ├ ─ docs / / document ├ ─ lighthouse - cli / / command line tools │ ├ ─ commands / / orders │ └ ─test├─ Guitar school - Core // Core logic │ ├─ ├─ arithmetic │ ├─ metrics │ ├─config │ ├─ Gather │ ├─connections │ ├─ gatherers Library │ │ ├ ─ lib / / tools ├ ─ report / / report generator │ │ └ ─ HTML │ │ └ ─ the renderer │ └ ─test├─ ├─ ├─ ├─ ├─ ├─ ├─ ├─ types // Test cases ├─ ├─ ├─ ├─ ├─ ├─ types //Copy the codeGiven that we already know some of the basic content and structure of Lighthouse, it’s easy to see what changes need to be made within the logic of Lighthouse- Core. The overall file looks like a lot of files, but the core logic is actually quite concentrated. The Lighthouse – core. The overall call relationship is shown in the following figure
It seems to be very complicated, rearranged as follows:
From the call chain, we can clearly see the process of connecting->collecting->auditing->report generation mentioned above. In fact, basically according to the function name, we can analyze the content of the function. Everyone according to their own needs, cut into the magic change, you can change whatever you want.
To be honest, Lighthouse’s overall design is pretty good, and with typescript, the code is extremely readable. In fact, based on the mechanism of plugin, basically can meet all kinds of needs. If one day, it is necessary to modify the source code, I hope the above content can help you.
How to be more objective?
Well, based on the changes above, we’ve got our own Lighthouse and our own auditing rules. However, the data on your computer is not true and does not represent the broad masses of the people. Therefore, we need to do the following:
- The cloud deployment
Deploy our service in the cloud machine, directly accept the baptism of the external network environment. At the same time limit hardware quality, maintain a more realistic machine level.
- How to deploy
Deploy in tianjin, Shanghai, Guangzhou and other nodes to see how much impact geographical location will have on the page.
- Long run
Do this at different times of the day, and at different times of the day, depending on the traffic cycle, when is your page at its worst? Of course, there is a more important role here, that is, spot check page accessibility, the page is not hung? Let you be the first to know the full information of the page.
- Run multiple times
Average multiple times to remove the impact of a single cache.
With this in mind, we developed Leadership, which can compare multiple reports at the same time and run in the cloud.
After completing all these, I was finally able to say to the product in a quiet and uneventful night that my page was really faster than that of competing products! Look, here’s my report!
Pay attention to [IVWEB community] public number to get the latest weekly articles, leading to the top of life!