Skip to content

Commit e0e3b52

Browse files
authored
Merge pull request #423 from pastelsky/patch-3
Proofreading code splitting guide
2 parents 08bb677 + 6aee38f commit e0e3b52

File tree

1 file changed

+23
-15
lines changed

1 file changed

+23
-15
lines changed

content/guides/code-splitting.md

Lines changed: 23 additions & 15 deletions
Original file line numberDiff line numberDiff line change
@@ -3,16 +3,35 @@ title: Code Splitting
33
sort: 2
44
contributors:
55
- pksjce
6+
- pastelsky
67
---
78

8-
Code splitting is the most compelling feature for `webpack` usage. You can split your code into various bundles and load them on demand with `webpack`. It allows to tweak an application for these optimisations using the configuration.
9-
You can load them at a later time in your code or in a specific route only or on an event from the user even.
9+
Code splitting is one of the most compelling features of webpack. It allows you to split your code into various bundles which you can then load on demand — like when a user navigates to a matching route, or on an event from the user. This allows for smaller bundles, and allows you to control resource load prioritization, which if used correctly, can have a major impact on your application load time.
1010

11-
There are mainly two kind of code-splits that need to be accomplished with `webpack`
11+
There are mainly two kinds of code splitting that can be accomplished with webpack:
12+
13+
## Resource splitting for caching and parallel loads
14+
15+
### Vendor code splitting
16+
17+
A typical application can depend on many third party libraries for framework/functionality needs. Unlike the application code, code present in these libraries do not change very often.
18+
19+
If we keep code from these libraries onto its own bundle, separate from the application code, we can leverage browser's caching mechanism to cache these files for longer durations on the end user's machine.
20+
21+
For this to work, the `hash` portion in the vendor filename must remain constant, regardless of application code changes. Learn [how to split vendor/library](/guides/code-splitting-libraries) code using the CommonsChunkPlugin.
22+
23+
### CSS splitting
24+
25+
You might also want to split your styles into a separate bundle, independent from application logic.
26+
This enhances cacheability of your styles and allows the browser to load the styles in-parallel with your application code, thus preventing a FOUC (flash of unstyled content).
27+
28+
Learn [how to split css](/guides/code-splitting-css) using the `ExtractTextWebpackPlugin`.
1229

1330
## On demand code-splitting
1431

15-
`webpack` can help us split our code into logical pieces or chunks as per our application routes or as per predicted user behaviour. This means that we can load non-essential assets when the user performs an action like route change and demands for it.
32+
While resource splitting of the previous kind requires the user to specify the split points upfront in the configuration, one can also create dynamic split points in the application code.
33+
34+
This can be used for more granular chunking of code, for eg. as per our application routes or as per predicted user behaviour. This allows the user to load non-essential assets on demand.
1635

1736
### Code splitting with `require.ensure()`
1837

@@ -21,15 +40,4 @@ Learn [how to split code](/guides/code-splitting-require) using `require.ensure(
2140

2241
?> Document `System.import()`
2342

24-
## Resource splitting for cacheing and parallel loads
25-
26-
### CSS splitting
27-
28-
An application owner would want to split all the css into a separate bundle. This enhances cacheability of the resource bundle and also allows the browser to parallely load the bundle which makes for a solid performance improvement.
29-
Learn [how to split css](/guides/code-splitting-css) using the ExtractTextWebpackPlugin.
30-
31-
### Vendor code splitting
32-
33-
A typical application uses third party libraries for framework/functionality needs. Particular versions of these libraries are used and code here does not change often. However, the application code changes frequently. Bundling application code with third party code would be inefficient. This is because the browser can cache asset files based on the cache header. To take advantage of this, we want to keep the hash of the vendor files constant regardless of application code changes. We can do this only when we separate the bundles for vendor and application code.
3443

35-
Learn [how to split vendor/library](/guides/code-splitting-libraries) code using the CommonsChunkPlugin.

0 commit comments

Comments
 (0)