The front-end framework era, for the development experience, efficiency and page performance brought, a very big revolution. People have picked up a series of packaging tools (Webpack/parcel etc), with a series of loaders to quickly build a SPA page.
The benefits of SPA applications are obvious;
- Improve the page switching experience
- Reduce switching time
- Easy to deploy & front-to-back separation
But it also brings a number of performance issues:
- Large Initial load Script
- Long first screen blank time
- When the page returns, the data is passively pulled back
These problems are unavoidable using the spa mode, by understanding the spa load run process, you can gradually see the root cause of performance problems, through the refinement of application loading, to solve these problems.
The SPA is becoming more and more fat
The biggest problem with the SPA, compared to a simple page, is the introduction of a large number of framework script scripts at the time of initialization, which results in a larger volume of script volume as the project grows.
Not just the volume
Many people will pay attention to the loading volume of the script, increase the cache hit rate by a series of scenarios, and reduce the number of script requests. In the network environment of poor mobile, minimizing the request time is of great significance.
But this is not a silver bullet, the mobile device parsing, compiling, and performing poorly on the script (script loading refers to the script on the tip of the book), and even if the cache can be fully utilized, execution time is a major bottleneck for performance.
Keep SPA Fit
The principle of performance optimization: Poverty is the only, rich and the world.
How to maintain a large SPA?
As the project continues to evolve and the page continues to grow, a steady stream of third-party components & libraries are added Bundle
, and a good spa architecture ensures the ultimate in performance and experience for large spa projects. Here's an introduction to the features of a good performance & experience SPA:
Performance Optimization 1. Fast Start--greatly increased loading speed (important)
Launch the app quickly, parallel-initiate Bundle loading & pull initial data. I believe you have discovered that when the SPA is initialized, it will have to wait for the bundle to return and execute before the data load is initiated.
Since bundle loading is very time-consuming on mobile devices (even with caching), we can take advantage of this time to preload data. This feature allows for a more pronounced effect on subsequent optimizations.
The following example code:
12 |
//App.js Promise. All([load(' bundle '), load(' data ')]) |
2. Based on route splitting-reduces the initial load volume
By using asynchronous loading, the method of providing an asynchronous pull component is provided when the route is registered, and the corresponding component is loaded only when it is necessary to enter the corresponding route.
1234 |
Route({ Home: () => import(' @/coms/home '), About : () => import(' @/coms/about ') }) |
3. Standalone package asynchronous components public bundle--improve reusability & Cache Hit Ratio
Within Home
and About
waiting for a route, there may be a common set of UI components that, if the asynchronous load common component is not packaged uniformly, loads a set of UI components each time the route is loaded. By packaging a common component extraction Vendor
, you can reduce the next incoming route load volume and time.
BTW: Inwebpack 时,依旧需要手动维护异步加载组件公用组件。webpack4
提供更丰富的异步组件抽离方案。
4. Component preload-reduces page switching time
When the first screen is loaded, the device & Network is idle, and other routing components can be preloaded to improve page switching performance.
Preloading is a very tedious process, and we can design a minimal launcher to quickly preload subsequent components after page rendering:
12 |
//All routing components that contain page will be preloaded boostraper. Loadmatch(' Page ') |
5. Use the ESM syntax--Package library on demand to reduce Bundle volume
webpack4
The ESM tree shaking
has been optimized to really "package on demand" when referencing a library, which requires both a library of your own development or a third-party tool library, which is necessary to package & use the ESM version.
6. Better taste with PWA-reduce the first screen rendering time and greatly improve the experience
Depending on the PWA cache policy, you can cache the pages you visit index.html
, prioritize the cache the next time you open, and then initiate a request to update the cache. This allows the SPA app to load the app's first-screen document stream with virtually no extra time.
Experience Optimization 1. Build your minimalist
Skeleton Page
SPA first screen load facing a long time white screen, skeleton diagram is a perfect "delaying tactic". As mentioned in the Google researcher's article, skeleton graphs have greatly improved the user experience:
- Quick Show
- With PWA first screen cache, skeleton diagram for instant loading & display, the first screen visual impact of the promotion
- Stable loading
- Eliminates "jitter" caused by multiple redraw & resource loading for page initial loading
It should be noted that the skeleton diagram should be kept as small and simple as possible to ensure that the page's subsequent loading is not severely affected.
2. Page Switch Loading
In any case, optimize the performance load, in the page switch still need to get page data, if the processing is not good, may be a short time before the data return of the unfriendly "blank." This problem can be handled in the following ways:
- Friendly switching before Loading
- Ensure page interactivity and reduce user congestion before components & data are loaded
- Transition animations
- In most native applications, transition animations are included as standard
- Instant Components & Data has been fully loaded, in the moment of switching to a new page, still need page rendering time, this time may cause the page short blank or "visual blocking"
- The transition animation time can be a good way to alleviate this problem, most of the page is guaranteed after the transition animation is still finished rendering
At last
In addition to the SPA optimization program mentioned above, the Web Performance Foundation is also a must-have cornerstone (such as domain convergence, reasonable document structure). The essence of performance optimization is a process of fine-grained monitoring of the operation of the page, and also requires us to think and understand more about the process and logic of Web loading.
Ultimate Web Performance--spa Performance Guide