性能

Responsiveness simply means how fast the system provides outputs (possibly multiple ones) in response to user inputs.

Framerate is the rate at which the system changes pixels displayed to the user.

Humans usually cannot perceive differences in frame-rate above 60Hz.
That's why most modern electronic displays are designed to refresh at that rate.

All applications would retain the state created by the user the last time the user interacted with the application.

A well-designed system has been optimized to use as much memory as possible to maintain user state, while meeting other UPP goals.

In service of meeting UPP goals, the system must use only the minimum power required.

The Web platform provides many tools, some better suited for particular jobs than others.
All application logic is written in JavaScript.
To display graphics, developers can use HTML or CSS (i.e. high-level declarative languages), or use low-level imperative interfaces offered by the <canvas> element (which includes WebGL).
Somewhere "in between" HTML/CSS and Canvas is SVG, which offers some benefits of both.

HTML and CSS greatly increase productivity, sometimes at the expense of framerate or pixel-level control over rendering.
Text and images reflow automatically, UI elements automatically receive the system theme, and the system provides "built-in" support for some use cases developers may not think of initially, like different-resolution displays or right-to-left languages.

The canvas element offers a pixel buffer directly for developers to draw on. This gives developers pixel-level control over rendering and precise control of framerate, but now the developers need to deal with multiple resolutions and orientations, right-to-left languages, and so forth.
Developers draw to canvases using either a familiar 2D drawing API, or WebGL

The Gecko JavaScript engine supports just-in-time (JIT) compilation.
This enables application logic to perform comparably to other virtual machines — such as Java virtual machines — and in some cases even close to "native code".

The graphics pipeline in Gecko that underpins HTML, CSS, and Canvas is optimized in several ways. The HTML/CSS layout and graphics code in Gecko reduces invalidation and repainting for common cases like scrolling; developers get this support "for free". Pixel buffers painted by both Gecko "automatically" and applications to canvas "manually" minimize copies when being drawn to the display framebuffer. This is done by avoiding intermediate surfaces where they would create overhead (such as per-application "back buffers" in many other operating systems), and by using special memory for graphics buffers that can be directly accessed by the compositor hardware.
Complex scenes are rendered using the device's GPU for maximum performance.
To improve power usage, simple scenes are rendered using special dedicated composition hardware, while the GPU idles or turns off.

Fully static content is the exception rather than the rule for rich applications. Rich applications use dynamic content with animation and transition effects. Transitions and animations are particularly important to applications: developers can use CSS to declare complicated behaviour with a simple, high-level syntax. In turn, Gecko's graphics pipeline is highly optimized to render common animations efficiently.
Common-case animations are "offloaded" to the system compositor, which can render them in a performant, power-efficient fashion.

An app's startup performance matters just as much as its runtime performance. Gecko is optimized to load a wide variety of content efficiently: the entire Web! Many years of improvements targeting this content, like parallel HTML parsing, intelligent scheduling of reflows and image decoding, clever layout algorithms, etc., translate just as well to improving Web applications on Firefox.

三个用户可见事件

key to fast startup

The first important thing for high framerate is to choose the right tool.
Use HTML and CSS to implement content that's mostly static, scrolled, and infrequently animated.
Use Canvas to implement highly dynamic content, like games that need tight control over rendering and don't need theming.

For content drawn using Canvas, it's up to the developer to hit framerate targets: they have direct control over what's drawn.

For HTML and CSS content, the path to high framerate is to use the right primitives. Firefox is highly optimized to scroll arbitrary content; this is usually not a concern. But often trading some generality and quality for speed, such as using a static rendering instead of a CSS radial gradient, can push scrolling framerate over a target. CSS media queries allow these compromises to be restricted only to devices that need them.

Many applications use transitions or animations through "pages", or "panels". For example, the user taps a "Settings" button to transition into an application configuration screen, or a settings menu "pops up".

Firefox is highly optimized to transition and animate scenes that:

• use pages/panels approximately the size of the device screen or smaller
  
• transition/animate the CSS transform and opacity properties
  

Transitions and animations that adhere to these guidelines can be offloaded to the system compositor and run maximally efficiently.

Improving memory and power usage is a similar problem to speeding up startup:
don't do unneeded work or lazily load uncommonly-used UI resources.
Do use efficient data structures and ensure resources like images are optimized well.

Modern CPUs can enter a lower-power mode when mostly idle.
Applications that constantly fire timers or keep unnecessary animations running prevent CPUs from entering low-power mode. Power-efficient applications shouldn't do that.

When applications are sent to the background, a visibilitychange event is fired on their documents.
This event is a developer's friend; applications should listen for it.

Use CSS animations and transitions

Use CSS transforms

Use requestAnimationFrame()
instead of setInterval()

Make events immediate

Keep your interface simple

延迟

浏览器的单线程

The first step of navigating to a web page is finding where the assets for that page are located.
If you navigate to https://example.com, the HTML page is located on the server with IP address of 93.184.216.34.
If you’ve never visited this site, a DNS lookup must happen.

Your browser requests a DNS lookup, which is eventually fielded by a name server, which in turn responds with an IP address.
After this initial request, the IP will likely be cached for a time, which speeds up subsequent requests by retrieving the IP address from the cache instead of contacting a name server again.

DNS lookups usually only need to be done once per hostname for a page load.
However, DNS lookups must be done for each unique hostname the requested page references.
If your fonts, images, scripts, ads, and metrics all have different hostnames, a DNS lookup will have to be made for each one.

This can be problematic for performance, particularly on mobile networks.
When a user is on a mobile network, each DNS lookup has to go from the phone to the cell tower to reach an authoritative DNS server.
The distance between a phone, a cell tower, and the name server can add significant latency.

Once the IP address is known, the browser sets up a connection to the server via a TCP three-way handshake.
This mechanism is designed so that two entities attempting to communicate—in this case the browser and web server
—can negotiate the parameters of the network TCP socket connection before transmitting data, often over HTTPS.

TCP's three way handshaking technique is often referred to as
"SYN-SYN-ACK"—or more accurately SYN, SYN-ACK, ACK
—because there are three messages transmitted by TCP to negotiate and start a TCP session between two computers.
Yes, this means three more messages back and forth between each server, and the request has yet to be made.

三次握手

For secure connections established over HTTPS, another "handshake" is required.
This handshake, or rather the TLS negotiation,
determines which cipher will be used to encrypt the communication, verifies the server,
and establishes that a secure connection is in place before beginning the actual transfer of data.
This requires three more round trips to the server before the request for content is actually sent.

While making the connection secure adds time to the page load,
a secure connection is worth the latency expense,
as the data transmitted between the browser and the web server cannot be decrypted by a third party.

After the 8 round trips, the browser is finally able to make the request.

The first response packet will be 14Kb.
This is part of TCP slow start, an algorithm which balances the speed of a network connection.
Slow start gradually increases the amount of data transmitted
until the network's maximum bandwidth can be determined.

In TCP slow start, after receipt of the initial packet, the server doubles the size of the next packet to around 28Kb.
Subsequent packets increase in size until a predetermined threshold is reached, or congestion is experienced.

If you’ve ever heard of the 14Kb rule for initial page load, TCP slow start is the reason why the initial response is 14Kb,
and why web performance optimization calls for focusing optimizations with this initial 14Kb response in mind.
TCP slow start gradually builds up transmission speeds appropriate for the network's capabilities to avoid congestion.

As the server sends data in TCP packets, the user's client confirms delivery by returning acknowledgements, or ACKs.
The connection has a limited capacity depending on hardware and network conditions.
If the server sends too many packets too quickly, they will be dropped. Meaning, there will be no acknowledgement.
The server registers this as missing ACKs.
Congestion control algorithms use this flow of sent packets and ACKs to determine a send rate.

processing the HTML markup and building the DOM tree

不会导致暂停HTML解析的资源

导致暂停HTML解析的资源

While the browser builds the DOM tree, this process occupies the main thread.

As this happens, the preload scanner will parse through the content available
and request high priority resources like CSS, JavaScript, and web fonts.

Thanks to the preload scanner, we don't have to wait until
the parser finds a reference to an external resource to request it.

It will retrieve resources in the background so that by the time
the main HTML parser reaches requested assets,
they may possibly already be in flight, or have been downloaded.

The optimizations the preload scanner provides reduce blockages.

To ensure the script doesn't block the process,
add the async attribute, or the defer attribute
if JavaScript parsing and execution order is not important.

Waiting to obtain CSS doesn't block HTML parsing or downloading,
but it does block JavaScript,
because JavaScript is often used to query CSS properties’ impact on elements.

the total time to create the CSSOM is generally less than the time it takes for one DNS lookup.

JavaScript Compilation

Building the Accessibility Tree

The third step in the critical rendering path is combining the DOM and CSSOM into a render tree.
The computed style tree, or render tree, construction starts with the root of the DOM tree,
traversing each visible node.

Tags that aren't going to be displayed, like the <head> and its children and
any nodes with display: none, such as the script { display: none; } you will find in user agent stylesheets,
are not included in the render tree as they will not appear in the rendered output.
Nodes with visibility: hidden applied are included in the render tree, as they do take up space.
As we have not given any directives to override the user agent default,
the script node in our code example above will not be included in the render tree.
(这句意思不懂，以后需要理解了再研究)

Each visible node has its CSSOM rules applied to it.
The render tree holds all the visible nodes with content and computed styles
-- matching up all the relevant styles to every visible node in the DOM tree,
and determining, based on the CSS cascade, what the computed styles are for each node.

The fourth step in the critical rending path is running layout on the render tree to compute the geometry of each node.
Layout is the process by which the width, height, and location of all the nodes in the render tree are determined,
plus the determination of the size and position of each object on the page.
Reflow is any subsequent size and position determination of any part of the page or the entire document.

Once the render tree is built, layout commences. The render tree identified which nodes are displayed (even if invisible) along with their computed styles, but not the dimensions or location of each node. To determine the exact size and location of each object, the browser starts at the root of the render tree and traverses it.

On the web page, most everything is a box. Different devices and different desktop preferences mean an unlimited number of differing viewport sizes. In this phase, taking the viewport size into consideration, the browser determines what the dimensions of all the different boxes are going to be on the screen. Taking the size of the viewport as its base, layout generally starts with the body, laying out the dimensions of all the body’s descendants, with each element's box model properties, providing placeholder space for replaced elements it doesn’t know the dimensions of, such as our image.

The first time the size and position of nodes are determined is called layout.
Subsequent recalculations of node size and locations are called reflows. In our example, suppose the initial layout occurs before the image is returned.
Since we didn't declare the size of our image, there will be a reflow once the image size is known.

The last step in the critical rendering path is painting the individual nodes to the screen,
the first occurence of which is called the first meaningful paint.
In the painting or rasterization(光栅化) phase, the browser converts each box calculated in the layout phase to actual pixels on the screen.
Painting involves drawing every visual part of an element to the screen, including text, colors, borders, shadows,
and replaced elements like buttons and images. The browser needs to do this super quickly.

To ensure smooth scrolling and animation, everything occupying the main thread, including calculating styles, along with reflow and paint, must take the browser less than 16.67ms to accomplish.
At 2048 X 1536, the iPad has over 3,145,000 pixels to be painted to the screen. That is a lot of pixels that have to be painted very quickly.
To ensure repainting can be done even faster than the initial paint, the drawing to the screen is generally broken down into several layers.
If this occurs, then compositing is necessary.

Painting can break the elements in the layout tree into layers.
Promoting content into layers on the GPU (instead of the main thread on the CPU) improves paint and repaint performance.
There are specific properties and elements that instantiate a layer, including <video> and <canvas>,
and any element which has the CSS properties of opacity, a 3D transform, will-change, and a few others.
These nodes will be painted onto their own layer, along with their descendants,
unless a descendant necessitates(使成为必要) its own layer for one (or more) of the above reasons.

Layers do improve performance, but are expensive when it comes to memory management,
so should not be overused as part of web performance optimization strategies.

When sections of the document are drawn in different layers, overlapping each other,
compositing is necessary to ensure they are drawn to the screen in the right order and
the content is rendered correctly.

As the page continues to load assets, reflows can happen (recall our example image that arrived late).
A reflow sparks a repaint and a re-composite.

Element

window.getComputedStyle()

window

表单

Mouse events

Range

contenteditable

直接改变className，如果动态改变样式，则使用 cssText 合并 css 修改：

// 不好的写法
var left = 1;
var top = 1;
el.style.left = left + "px";
el.style.top = top + "px";

// 比较好的写法
el.className += " className1";

// 比较好的写法
el.style.cssText += "left: " + left + "px; top: " + top + "px;";

a) 使用 DocumentFragment 进行缓存操作,引发一次回流和重绘；

b) 使用 display:none 技术，只引发两次回流和重绘；

c) 使用 cloneNode(true or false) 和 replaceChild 技术，引发一次回流和重绘；
var dupNode = node.cloneNode(deep);
replacedNode = parentNode.replaceChild(newChild, oldChild);

when content appears on the screen that is actually meaningful;

definited in the Largest Contentful Paint API,
reports the render time of the largest content element visible in the viewport.

it measures the average time for pixels on the visible screen to be painted.

Make fallback fonts the same size and weight so that when fonts load the page change is less noticeable.

Making a content request on keydown rather than waiting for keyup can shave 200ms off the perceived load of the content.

Adding an interesting but unobtrusive 200ms animation to that keyup even can reduce another 200ms of the perceived load.

You're not saving 400ms of time, but the user doesn't feel like they're waiting for content until, well, until they're waiting for content.

链接类型

只加载当前页面需要的资源

HTTP2 的性能优点

Llinking CSS with a tradional link tag with rel="stylesheet" is synchronous and blocks rendering.
Optimize the rendering of your page by removing blocking CSS.

To load CSS asynchronously one can simpy set the media type to print and then change to all once loaded.
The following snippet includes an onload attribute, requiring Javascript,
so it is important to include a noscript tag with a traditional fallback.

<link rel="stylesheet" href="/path/to/my.css" media="print" onload="this.media='all'">
<noscript><link rel="stylesheet" href="/path/to/my.css"></noscript>

noscript 不清晰，以后有需要了再详尽研究

The downside with this approach is the flash of unstyled text (FOUT.)
The simplist way to address this is by inlining CSS that is required for any content that is rendered above the fold, or what you see in the browser viewport before scrolling. These styles will improve perceived performance as the CSS does not require a file request.

<style type="text/css">
// Insert your CSS here
</style>

1. Avoid Javascript blocking by using the async or defer attributes, 
   
2. or link javascript assets after the page's DOM elements. 
   

Javascript only block rendering for elements that appear after the script tag in the DOM tree.

EOT and TTF formats are not compressed by default.
Apply compression such as GZIP or Brotli for these file types.
Use WOFF and WOFF2. These formats have compression built in.

Within @font-face use font-display: swap.
By using font display swap the browser will not block rendering and will use the backup system fonts that are defined.
Optimiize font weight to match the web font as closely as possible.

Icon web fonts

The Critical Rendering Path is the sequence of steps
the browser goes through to convert the HTML, CSS,
and JavaScript into pixels on the screen.

Optimizing the critical render path improves render performance.

The critical rendering path includes the Document Object Model (DOM),
CSS Object Model (CSSOM), render tree
and layout.

• critical - absolutely needed ( initial view )
  
• render - display or show (in our case our webpages are "rendered" when they can be seen by a user)
  
• path - the chain of events that lead to our webpage being displayed in a browser
  
• initial view - also known as "above the fold", the initial view is the part of a webpage visible to a user before they scroll

The document object model is created as the HTML is parsed.

The HTML may request JavaScript, which may, in turn, alter the DOM.

The HTML includes or makes requests for styles, which in turn builds the CSS object model.

The browser engine combines the two to create the Render Tree.

Layout determines the size and location of everything on the page.

Once layout is determined, pixels are painted to the screen.

Optimizing the critical rendering path improves the time to first render.

Understanding and optimizing the critical rendering path is important to
ensure reflows and repaints can happen at 60 frames per second,
to ensure performant user interactions and avoid jank.

DOM construction is incremental.

The HTML response turns into tokens which turns into nodes which turn into the DOM Tree.

A single DOM node starts with a startTag token and ends with an endTag token.
Nodes contain all relevant information about the HTML element.
The information is described using tokens.
Nodes are connected into a DOM tree based on token hierarchy.
If another set of startTag and endTag tokens come between a set of startTag and endTags,
you have a node inside a node, which is how we define the hierarchy of the DOM tree.

The greater the number of nodes, the longer the following events in the critical rendering path will take.
Measure! A few extra nodes won't make a difference, but divitis can lead to jank.

The DOM contains all the content of the page.
The CSSOM contains all the styles of the page; information on how to style that DOM.

CSSOM is similar the the DOM, but different.
While the DOM construction is incremental, CSSOM is not.

CSS is render blocking: the browser blocks page rendering until it receives and processes all of the CSS.

CSS is render blocking because rules can be overwritten, so the content can't be rendered until the CSSOM is complete.

CSS has its own set of rules for identifying valid tokens.
Remember the C in CSS stands for 'Cascade'. CSS rules cascade down.
As the parser converts tokens to nodes, with descendants of nodes inheriting styles.
The incremental processing features don't apply to CSS like they do with HTML,
because subsequent rules may override previous ones.
The CSS object model gets built as the CSS is parsed,
but can't be used to build the render tree until it is completely parsed
because styles that are going to be overwritten with later parsing should not be rendered to the screen.

In terms of selector performance, less specific selectors are faster than more specific ones.
For example, .foo {} is faster than .bar .foo {} because when the browser finds .foo, in the second scenario,
it has to walk up the DOM to check if .foo has an ancestor .bar.
The more specific tag requires more work from the browser, but this penalty is not likely worth optimizing.

If you measure the time it takes to parse CSS, you'll be amazed at how fast browsers truly are.
The more specific rule is more expensive because it has to traverse more nodes in the DOM tree -
but that extra expense is generally minimal.
Measure first. Optimize as needed.
Specificity is likely not your low hanging fruit.
When it comes to CSS, selector performance optimization, improvements will only be in microseconds.
There are other ways to optimize CSS,
such as minification,
and separating defered CSS into non-blocking requests by using media queries.

media queries 部分 可查看 css 脑图：

The render tree captures both the content and the styles:
the DOM and CSSOM trees are combined into the render tree.
To construct the render tree, the browser checks every node,
starting from root of the DOM tree, and determine which CSS rules are attached.

The render tree only captures visible content.
The head section (generally) doesn't contain any visible information,
and is therefore not included in the render tree.
If there's a display: none; set on an element, neither it, nor any of its descendants, are in the render tree.

Once the render tree is built, layout becomes possible.
Layout is dependent on the size of screen.
The layout step determines where and how the elements are positioned on the page,
determining the width and height of each element, and where they are in relation to each other.

What is the width of an element?
Block level elements, by definition, have a default width of 100% of the width of their parent.
An element with a width of 50%, will be half of the width of its parent.
Unless otherwise defined, the body has a width of 100%, meaning it will be 100% of the width of the viewport.
This width of the device impacts layout.

The viewport meta tag defines the width of the layout viewport, impacting the layout.
Without it, the browser uses the default viewport width,
which on by-default full screen browsers is generally 960px.
On by-default full screen browsers, like your phone's browser,
by setting <meta name="viewport" content="width=device-width">,
the width will be the width of the device instead of the default viewport width.
The device-width changes when a user rotates their phone between landscape and portrait mode.
Layout happens every time a device is rotated or browser is otherwise resized.

Layout performance is impacted by the DOM -- the greater the number of nodes, the longer layout takes.
Layout can become a bottleneck, leading to jank if required during scrolling or other animations.
While a 20ms layout on load or orientation change may be fine, it will lead to jank on animation or scroll.
Any time the render tree is modified, such as by added nodes, altered content, or updated box model styles on a node,
layout occurs.

To reduce the frequency and duration of layout events, batch updates and avoid animating box model properties.

The last step in painting the pixels to the screen.
Once the render tree is created and layout occurs, the pixels can be painted to the screen.

Onload, the entire screen is painted.
After that, only impacted areas of the screen will be repainted,
as browsers are optimized to repaint the minimum area required.

Paint time depends on what kind of updates are being applied to the render tree.
While painting is a very fast process, and therefore likely not the most impactful place to focus on in improving performance,
it is important to remember to allow for both layout and re-paint times when measuring how long an animation frame may take.
The styles applied to each node increase the paint time, but removing style that increases the paint by 0.001ms may not
give you the biggest bang for your optimization buck.
Remember to measure first. Then you can determine whether it should be an optimization priority.

减少首屏 http 请求

减小请求资源体积

合理设置缓存

使用 CDN

For classic scripts, if the async attribute is present, then the classic script will be fetched in parallel to parsing and evaluated as soon as it is available.

For module scripts, if the async attribute is present, then the module script and all its dependencies will be fetched in parallel to parsing, and the module script will be evaluated as soon as it is available.

This attribute allows the elimination of parser-blocking JavaScript where the browser would have to load and evaluate scripts before continuing to parse. defer has a similar effect in this case.

This is a boolean attribute: the presence of a boolean attribute on an element represents the true value, and the absence of the attribute represents the false value.

这个布尔属性被设定用来通知浏览器该脚本将在文档完成解析后，触发 DOMContentLoaded 事件前执行。

Scripts with the defer attribute will prevent the DOMContentLoaded event from firing until the script has loaded and finished evaluating.

This attribute allows the elimination of parser-blocking JavaScript where the browser would have to load and evaluate scripts before continuing to parse. async has a similar effect in this case.

async

defer

defer

async