Hi, I’m Casson.

What’s your first reaction when you talk about Chrome?

The number one browser by market share? The famous V8? DevTools is standard for browser debugging?

For Chrome team members, the first reaction is likely to be to these two kpIs:

  • User Experience (UX

  • DX (Developer Experience

As a developer, you’ll feel a lot of improvement around these two metrics:

  • Iteration of the underlying V8, WebAssembly engine

  • Quantitative analysis of UX and DX metrics with Lighthouse tool

  • Chrome’s quick support for new features in the ES standard

When all is said and done, what else can be mined around these two metrics?

Let’s take a look at what the Chrome team is doing to save the country for a better web experience.

Logic to arrange

Here’s the logic:

  1. Most web projects in the world today rely on open source tools

  2. Better open source tools lead to better Web experiences

By this logic, any time we (the Chrome team) work with open source projects and make them better, we are contributing to a better Web experience.

Therefore, we just need to select the right projects and conduct in-depth cooperation according to their suitable optimization types (UX, DX).

Next, let’s take a look at some of the projects we’ve been working on with the Chrome team.

And the Next. Js cooperation

Next. Js is available as a full-featured production framework based on React, and its SSR feature has been in deep collaboration with the React team.

The Chrome team created a set of Timing apis for Next. Js based on the SSR scenario.

The new Timing API includes SSR related metrics (such as hydrate time).

At the same time, LightHouse collects more SSR data for reference:

Cooperate with Babel

We often use @babel/preset-env to compile advanced ES syntax into ES5 syntax based on the target browser version.

The idea behind this degraded compilation is that each high-level syntax can be viewed as a collection of one or more syntax transformations.

When you encounter a high-level syntax, replace it with an implementation of those syntax transformations.

For example, function parameters can be a collection of three features: destruct, parameter default, and remaining parameters. For the following source code:

const foo = ({ a = 1 }, b = 2. args) = > [a,b,args];
Copy the code

The output compiled by @babel/preset-env contains the realization of destruct, parameter default, and remaining parameters:

const foo = function foo(_ref, b) {
 let { a = 1 } = _ref;

 if (b === void 0) { b = 2; }

 for (
   var _len = arguments.length,
     args = new Array(_len > 2 ? _len - 2 : 0),
     _key = 2;  _key < _len; _key++
 ) {
   args[_key - 2] = arguments[_key];
 }

 return [a, b, args];
};
Copy the code

As you can see, the overall amount of code that was compiled exploded!

Some advanced syntax may already be more or less supported by modern browsers, just not well.

So a better way to think about it is:

Replace unsupported syntax with supported syntax

This eliminates the need to implement this part of the code.

Only one modern browser does not support the syntax in the above example due to its own bugs.

The solution is: replace {a = 1} with {a: a = 1}.

Therefore, the above code will work in modern browsers as long as it is compiled as follows:

const foo = ({ a: a = 1 }, b = 2. args) = > [a,b,args];
Copy the code

Comparing the two compilation results, the latter is 80% less code than the former!

This difference between browsers creates more room for optimization than the Babel team could do on its own.

So, the Chrome team worked with them to develop @Babel /preset- Modules, which has been integrated into @babel/preset-env as a bugfixes parameter.

Cooperate with the React

As the heaviest view library in the front end, React is always looking for run-time optimization space.

The navigator. The scheduling. IsInputPending API is the product of its cooperation with the Chrome team.

This API returns a function that returns true if an input event is currently scheduled.

For example, pause JS thread execution when a mouse or keyboard event is scheduled:

while (workQueue.length > 0) {
  if (navigator.scheduling.isInputPending(['mousedown'.'mouseup'.'keydown'.'keyup']) {break;
  }
  let job = workQueue.shift();
  job.execute();
}
Copy the code

Input from an input field can be rendered faster by the browser, significantly reducing the number of frames that the browser is framing (as the input field gets stuck).

conclusion

Trees die, people live.

When the project reaches a certain stage and there is not much room for internal optimization, it needs to take the initiative to empower other verticals, focus on user perception of the track, and use reuse to achieve lasting benefits!

As the saying goes: hang out with other teams and KPIs will come.

Did you get it?