When referring to Preloading and Prefetching, I would like to talk about code splitting. This example shows why code splitting is required.

// index.js
import _ from 'lodash'; // Assume the size is 1 MBBusiness code// Assume the size is 1 MB
Copy the code
  • At first access, the index.js file is 2 MB in size and the size that needs to be loaded is 2 MB
  • The business code changes the size of index.js to 2 MB when the user accesses it again, and the size that needs to be loaded is 2 MB

Now for code splitting:

// src/index.js Business code// Assume the size is 1 MB

// src/lodash.js
import _ from 'lodash';
window. _ = _;// You can use the Lodash library later by using _ in other files.
Copy the code

  • At first access, index.js is 1 MB, lodash.js is 1 MB, the size of the load is 2 MB, and it can be loaded in parallel, which is generally faster than the above.

  • When the business code changes and the user accesses it again, index.js is 1 MB. Since the lodash.js file has not changed, it does not need to be loaded again, because the browser cache has it, so it only needs to be loaded 1 MB this time.

As you can see from the above example, code splitting improves performance, but the first access time doesn’t decrease much, and WebPack wants to make it optimized for the first access as well.

Let’s start with the default configuration of the SplitChunkPlugin in Webpack.

optimazition: {
  splitChunks: {
    chunks: 'async'.// asynchronous code is split. }}Copy the code

As you can see, chunks are configured async, and code splitting is only done when asynchronous.

Why does WebPack have this default setting?

Or from the following example to illustrate:

Create a div element and display it on the page.

// index.js
document.addEventListener('click'.() = > {
  const div = document.createElement('div');
  div.innerHTML = 'hello webpack';
  document.body.appendChild(div);
});
Copy the code

Is there a problem with the above code? Is there room for optimization?

Now we package the above code and run it in the browser. Press Ctrl + Shift + P in the browser, then input coverage in the popup dialog box, click Enter, and then click the small black origin below. After the small black dot turns into a red dot, refresh the page, and the page as shown below will appear:

You can see from the red box that the current page utilization of the currently loaded file is 74.6%.

Taking a closer look at the code above, the next three lines of code in the callback function are only useful after the page is clicked, so there is no need to load them when the page is loaded.

const div = document.createElement('div');
div.innerHTML = 'hello webpack';
document.body.appendChild(div);
Copy the code

Now let’s write it differently, load them in asynchronously, and create a new click file:

// click.js
function handleClick() {
  const div = document.createElement('div');
  div.innerHTML = 'hello webpack';
  document.body.appendChild(div);
}

export default handleClick;
Copy the code

Then rewrite the index.js file:

document.addEventListener('click'.() = > {
  import('./click.js').then(({default: func}) = >{ func(); })});Copy the code

The asynchronous code is written in a separate file that only loads click.js when the page is clicked.

Now, if you look at the code utilization at this point, it’s 75%, which is a little bit of an improvement, assuming that if the code is asynchronously loaded at a larger size, it’s going to improve a lot.

Now we can see why Webpack uses a default configuration like chunks: ‘async’.

Webpack optimization focuses on the use of code rather than caching, but the use of caching to optimize the meaning is not much, through the asynchronous way to improve the use of code to a greater extent to improve the performance of the website.

This is why writing asynchronous code has always been advocated.

Another problem is that the click.js file is only loaded when the user clicks on the page, so if the file is large, it will take a long time to load and the user experience will be poor.

So how can this problem be solved?

Some of you might wonder if you can load this file when the network is idle after loading the page. That is when Preloading and Prefetching comes to last.

  • Prefetching

    Use method is also relatively simple, is to load asynchronously before the file with /* webpackPrefetch: true */ magic comment can be.

    document.addEventListener('click'.() = > {
  import(/* webpackPrefetch: true */ './click.js').then(({default: func}) = >{ func(); })});Copy the code

    When the page is clicked, the 0.js is loaded directly from the cache, so it takes a very short time.

  • What is the difference between Preloading and Prefetching?

    The difference between Preloading and fetching is that Preloading occurs when bandwidth is free after core code has been loaded, whereas Preloading is loaded with a core code file.

Therefore, it is more appropriate to load asynchronous files using Prefetching, but be aware of browser compatibility issues.