When asked about performance, most people freeze. I always feel like I have a lot to say, but I don’t know where to start.

  1. Reducing HTTP requests
  2. Using HTTP2
  3. Use server-side rendering
  4. Static resources use CDN
  5. Place the CSS at the top of the file and the JavaScript file at the bottom
  6. Use the font icon iconfont instead of the image icon
  7. Make good use of caching and do not load the same resource twice
  8. The compressed file
  9. Image optimization
  10. Load the code on demand through Webpack, extract the third library code, reduce the redundant code from ES6 to ES5
  11. Reduce redrawing rearrangements
  12. Using event Delegate
  13. Pay attention to the locality of the program
  14. If – else contrast the switch
  15. A lookup table
  16. Avoid page lag
  17. Use requestAnimationFrame to implement visual changes
  18. Use Web Workers
  19. Use bit operation
  20. Do not override native methods
  21. Reduce the complexity of CSS selectors
  22. Use Flexbox instead of the earlier layout model
  23. Animating is implemented using the transform and opacity property changes
  24. Use rules wisely and avoid over-optimization
Even if you recite all of the above and recite dozens of them at a time, the interviewer will not be very satisfied. One reason is that having too many items and no priorities can get annoying and the interviewer can’t remember what you said. The second is that this way of answering clearly gives people a rote to do the feeling of the question. (The interviewer really sucks.)

So what are we gonna talk about

There are two ways to answer the performance question. Along these two lines of thought, don’t need too much memory can naturally and “very insightful” answer a dozen or even dozens of optimization plan, of course, the premise is that these optimization plan you really use.

Idea 1: Start from the front-end performance scenarios you are familiar with

Performance bottlenecks occur in three scenarios

  1. It takes a few minutes to package each change at development time, which is too slow (development construction phase)
  2. Open the website and wait dozens of seconds to see the page, too slow (resource loading and page rendering phase)
  3. The animation on the page is not smooth after the page is displayed. Scrolling the page or dragging elements will get stuck, and even the page will crash (operation experience stage)

I. Development construction phase (FAQ: How to make Webpack faster)

  • Concurrency: Use multi-process packaging
  • Caching: Leverage caching when packaging
  • Keep packaging small: narrow file search and reduce unnecessary compilation

Second, resource loading stage

The core ideas are: small amount of transmission, short distance, parallel transmission, resource reuse, preloading.

The amount of transmission should be small

  • HTML compression at build time
  • CSS compression merge at build time
  • JavaScript compression merge at build time
  • Image compression at build time
  • Use SVG Sprite or font ICONS instead of picture ICONS
  • Gzip is enabled on the server and the data is compressed again before transmission
  • Build with TreeShaking to reduce unnecessary code introduction
  • Lazy route loading for a single page reduces the volume of resources loaded for the first time
  • Components load lazily, reducing the volume of resources loaded for the first time
  • Image lazy loading, reducing the volume of the first load of resources

If you are close to

  • Static resources are deployed to the CDN

Parallel transmission

  • Upgrade to HTTP2.0 (FAQ: What are the upgrades to HTTP1.x? Multiplexing; Binary frame splitting; Server push; Data flow priority; Head compression)

Resource reuse

  • Server configuration static resource caching (FAQ: HTTP cache policy? Cache-control? Keep alive? 304? ETag?
  • Subcontracting reuse during packaging

preloaded

  • Browsers secretly preload at idle times,<link rel="prefetch" href="url">

Third, page rendering stage

  • CSS on top, JS on bottom
  • It is recommended to load the CSS using link rather than @import
  • Unimportant externally-introduced JS are loaded asynchronously using defer or the Async property

Iv. Operation experience stage

  • Smooth animation

    • Try to use Transition and animation for CSS animations instead of JS animations (running on the main thread affects the smoothness of the animations)
    • Use transfrom and opacity as much as possible (best performance without redrawing or backflow)
    • TranslateZ/Translate3D hardware acceleration is enabled
    • JS animations use requestAnimationFrame and less setInterval
  • Scroll/move/operate smoothly

    • Fewer DOM additions and deletions (virtual long lists, DOM Diff)
    • Use anti-shake and throttling for high frequency operation
  • Intensive computing Computationally intensive operations can be handed over to the WebWorker for concurrent processing

Second, from the perspective of life to talk about front-end performance

Suppose you are the CTO of your company, and you have a product that needs to be launched in the shortest possible time. How do you do it under the premise that your existing team does not work overtime or 996? The solution is nothing more than:

  1. Compression requirements, iterative development — compression
  2. Use more old wheels (code, solution, architecture) and less new wheels — caching
  3. Add manpower – concurrent

Corresponding to front-end performance optimization

  • Compression requirements, iterative development: compression consolidation of static resources, Gzip, lazy loading of various types, narrowing of file search when developing packaging
  • Use the old wheels (code, schema, architecture) and create fewer new wheels: HTTP caching for resource requests, configuring caching for development packaging, and configuring subcontracting reuse for packaging
  • Increase manpower: resource requests using HTTP2 to achieve concurrent requests, development package configuration using concurrent capabilities, WebWorker

Starting with the above two ideas will be a natural flow of ideas for you, which will easily excite you and your interviewer, and even influence the follow-up questions to a certain extent.

When it comes to performance, six words come to mind: compression, caching, and concurrency. I’ll leave the rest to the cerebellum.

This article is originally published by FJL. The copyright of this article belongs to me and Hungry People Valley