These notes are unpolished collections of thoughts, unfinished ideas, and things I want to remember later. In the spirit of learning in public, I'm sharing them here. Have fun exploring, if you want!

Gatsby and Bundle Chunking

Tags:

This my understand on how Gatsby chunks bundles, based on this PR by Ward Peeters.

Big libraries over 160kb are moved to a separate library all together to improve js parsing & execution costs.

Gatsby now has the following bundles:

## App

dependencies used across the app, things like Apollo, theming / style libraries, poly fills

This bundle is produced from production-app.js which will mostly be discussed in this section. It is configured in webpack entry

## webpack-runtime-[contenthash].js

This contains the small webpack-runtime as a separate bundle (configured in optimization section). In practice, the app and webpack-runtime are always needed together.

## Framework (framework-[contenthash].js)

(for react and react-dom) might move reach/router in here too. This lets Gatsby do caching of dependencies that don't change.

## commons-[contenthash].js

Libraries used on every Gatsby page are bundled into the commons javascript file. By bundling these together, you can make sure your users only need to download this bundle once.

## component---[name]-[contenthash].js

Things like (component--src-pages-index-hash.js, component--src-templates-post-hash.js), page or component only.

This is a separate bundle for each page. The mechanics for how these are split off from the main production app are covered in Code Splitting.

## Granular chunks

These are are completely hashed, like this: 4f8ce8a27ecdca4a64741fe9081f6491727e7816-176af1ec8bf65e843533.js. These are dependencies used in at least two pages -- actually, I'm not sure if this is the case.

Linked references

Front End Performance AuditFront End Performance Audit Tags: [[Code]] [[Drafts]] [[Performance]] How to do a front end performance audit and some resources. Resources…