Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Web Performance Optimization Summary #70

Closed
xianshenglu opened this issue Jan 27, 2019 · 4 comments
Closed

Web Performance Optimization Summary #70

xianshenglu opened this issue Jan 27, 2019 · 4 comments

Comments

@xianshenglu xianshenglu pinned this issue Jan 27, 2019
@xianshenglu xianshenglu changed the title Performance Optimization Web Performance Optimization Summary Mar 30, 2019
@xianshenglu
Copy link
Owner Author

xianshenglu commented Mar 30, 2019

Where to Learn Web Performance Optimization(WPO)

About one month ago, I started to learn and summarize the knowledge about web performance optimization. However, beyond my expectations, there is too many things need to know. After thinking, I chose developers.google.com to start to learn. And other resources are listed here with this article.

The reasons that I chose developers.google.com can be listed below:

  • Articles will update when some methods or workarounds is outdated. This is extremely important for me to check it out when I need to update my knowledge about WPO. Also, it lets me know that I am learning something which can be tested and applied right now. For me, a blog is not better than a real-time updated document.
  • All the knowledge about WPO was listed systematically which is easy to understand, remember and use.

Summary About WPO

There are too many things for me to remember or test according to the doc. So, I am trying to summarize and abstract to make it simple to deduce and remember. Well, let's start with the questions.

What Is the Target of WPO

To make the page load as quickly as possible, also in a progressive way if possible.

How Can We Do That

Generally, we can analyze from the following aspects.

  • Use as much cache as possible.

    • For a better control of cache in the front end, we may need to learn something about PWA or Service Worker.
    • Or we might need some knowledge about offline storage like Indexed DB, Web SQL, localStorage and so on.
  • For those content that we can't use the cache, we need to take other measures.

    • Send the content as closely as possible which

      • may need the help of CDN.
    • Send the content simultaneously as many as possible which

      • need the help of http/2.0 to breakthrough the 6 parallel TCP connections limit in http/1.1 and request the resources simultaneously instead of one by one.
    • Send as little content as possible which

      • needs code compression, GZIP, code split, tree shake, image compression and remove or replace the bigger resources with smaller ones if possible.
    • Load the resource in a more efficient way which

      • needs to put script at the bottom of body

      • or use the async according to the situation

  • Render the page in a more efficient way which requires more efficient practice in our daily code. For examples,

    • Use requestAnimationFrame to change the UI instead of setTimeout or setInterval.

    • Implement lazy load with Intersection Observer instead of calculating the position of each target element by getBoundingClientRect.

    • Stick to compositor-only properties like transform and opacity to avoid re-layout and re-paint.

    • Reduce the complexity of selectors.

    • ....

How Can We Prove That Our Optimization Is Work

We need some tools like below to collect the result each time we did an optimization.

Strictly

Strictly speaking, if we want to do WPO seriously for a long time, we still need to do something like:

  • Set a performance budget
  • Use performance or google analysis tool to get the performance data in the real scene.
  • ...

Last Words

Here is just a summary about WPO. More accurate information is in developers.google.com.

Source

Reference

@xianshenglu
Copy link
Owner Author

demo:
WPO-v1.0.0-start
WPO-v1.0.0-end

@xianshenglu xianshenglu unpinned this issue May 2, 2019
@xianshenglu
Copy link
Owner Author

Think about running performance?

https://juejin.im/post/5b960fcae51d450e9d645c5f

@xianshenglu
Copy link
Owner Author

xianshenglu commented May 3, 2020

Server Push

Points Inferred from Rules of Thumb for HTTP/2 Push.

Rule 1: Push Enough to Fill Idle Network Time and No More

  • If we move the JS file in the , the browser would request the JS file before the HTML file has been entirely downloaded. In other words, the browser can request some resources while downloading the remaining HTML simultaneously.

If we modify the above example to import the JS file from the end of the HTML, instead of , then the browser won’t request the JS file until after the HTML file has been entirely downloaded.
Browsers typically do not evaluate scripts incrementally like HTML -- instead, the entire script file must be downloaded before it is evaluated

Rule 2: Push Resources in the Right Order

If the pushes occupy exactly one BDP, this delays the main response by ½ RTT.

An optimal strategy is to build a topological sort of the page evaluation graph, label each resource by its size, then push the first N resources from the topological order, where the cumulative size of the HTML and the first N-1 resources is less than cwnd, while the Nth resource brings the cumulative size just above cwnd.

When the optimal strategy cannot be used, it is always safe to push any N resources where the cumulative size of the HTML and those N resources is less than cwnd -- this may not result in a performance improvement, but at minimum, it should avoid degrading performance relative to “no push”.

It is better to avoid bufferbloat directly. To fix excessive kernel-level buffering, the server should take control using options like TCP_NOTSENT_LOWAT (also see this paper). Another solution is to switch from TCP to QUIC.

Rule 3: Don’t Push Resources the Client has Already Cached

in cases where service workers control the cache, it may be possible to implement this directly in a service worker without any browser changes

Rule 5: Consider Preload Instead of Push

Reference

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

1 participant