Disclaimer: I’m not a financial advisor. This is not financial advice. I’m only sharing my knowledge. No rights can be derived from the content of this article.

I will first explain the general Dutch pension system and then explain the tax benefits.
If you just want to see what the tax benefits are, you can skip the first section.

The Four Pillars of the Dutch Pension System

Netherlands uses the 4 pillars pension system to guarantee income for the elderly.

1. State Pension

2. Workplace pension

3. Private pension

4. Personal wealth & investments

State Pension (AOW)

The Algemene Ouderdomswet (AOW) provides a basic state pension to all residents who have lived or worked in the Netherlands. The amount depends on the number of years you’ve contributed between the ages of 15 and retirement age.

Typically, the AOW forms the foundation of retirement income.

Workplace Pension (Tweede Pijler)

Many employers in the Netherlands offer occupational pensions (tweede pijler). Contributions are usually shared between employer and employee.

These pensions are generally collective schemes, managed by pension funds or insurers, and significantly supplement the AOW.

You can check how much pension you have accrued so far by going to mijnpensioenoverzicht.nl and logging in with your DigiD.

Private Pension Savings (Derde Pijler)

The third pillar is an individual, voluntary way of saving for retirement. This is especially relevant for self-employed professionals and employees without strong employer-provided schemes. Contributions to third-pillar products—such as lijfrente (annuity policies) or pensioenbeleggingsrekening (pension investment accounts)—can be made in a tax-advantaged way. This is the focus of the article.

Personal Wealth & Investments (Vierde Pijler)

This is all investments and savings that people do independently of pension products. This includes cash savings, equity, bonds, real estate (non-primary residence) and commodities (crypto, gold, etc).

While this pillar does not enjoy the same tax benefits as the third pillar, it provides more flexibility.

In the Dutch tax system, these assets generally fall under Box 3 (wealth tax). In 2025 this is 2.2% of the principal of the amount on January 1 (on non cash assets) and is proposed to go up in the coming years.

Taxing on principal in this way really puts brakes on compounding your wealth, so it is more important to optimize this tax burden.

Saving taxes with Private pension

Let us dive deeper into how you can use the third pillar to save taxes.

Calculating the amount of private pension you can invest

There is a limit set to how much you can invest in a private pension account. There are 2 main categories for the limits: Jaarruimte and Reserveringsruimte.

You can calculate both Jaarruimte and Reserveringsruimte limits using the portal by belastingdienst.

Jaarruimte (Annual allowance)

The Jaarruimte (also called vrije ruimte) is the amount you are allowed to contribute to a third-pillar pension product on a tax-deductible basis each year. It depends on your income and your existing pension accrual through your employer.

If you already build up significant pension rights via your employer, your jaarruimte will be lower. Conversely, freelancers or those with minimal employer pensions typically have higher jaarruimte.

To calculate this for this year you would need your total taxable income in Box 1 and your Factor A of the previous year.

An easy way to find total taxable income in Box 1 for previous year is to go to login to the belastingdienst portal with your DigiD and check your last year’s tax statement.

For Factor A, you can find it by logging in with DigiD to the pension account where your employer contributes and looking into the Uniform Pensioen Overzicht (UPO) document.

Reserveringsruimte (Catch-Up Allowance)

If you did not fully use your jaarruimte in past years, you can carry it forward for up to 10 years. This is known as reserveringsruimte. It allows you to make larger pension contributions in later years and still benefit from tax deductions. There are annual maximums for reserveringsruimte contributions, but for people nearing retirement (ages 56–70), these maximums are higher to allow more aggressive catch-up savings.

Use the portal by belastingdienst to calculate these limits. A handy way to do this is to write down the taxable income and factor A for each year. Then calculate the Jaarruimte for each year separately and write it down. After this calculate the vrije ruimte for last year and fill in the reserveringsruimte for previous years to get the final number.

Example calculation

For 2025 contribution then you can answer “Yes” to the question do you want to calculate reserveringsruimte and add the Jaarruimte of previous years you calculated.

Tax Deduction and Deferred Tax

Tax Deductible Contributions: When you contribute to a third-pillar pension product within your vrije ruimte or reserveringsruimte, you can deduct this contribution from your taxable income. This reduces your current income tax burden. If your income falls in the highest bracket, you can get 49.5% of the money you invested back.

Deferred Tax: The money inside your pension grows tax-free (no wealth tax or capital gains tax). However, when you retire and start receiving payouts, those amounts are taxed as income. The advantage is that your tax rate is often lower in retirement compared to your working years.

Liquidity considerations

Pension products within the third pillar are highly regulated and cannot be accessed freely before the official pension age. This illiquidity is both a protection mechanism and a restriction.

Early Withdrawal Penalties

If you withdraw money before the designated pension age (typically the AOW age), it is considered a forbidden withdrawal. In such cases:

1. The full withdrawal amount becomes fully taxable as income in Box 1 in the year of withdrawal.

2. An additional 20% penalty tax (revisierente) is applied by the Belastingdienst (Dutch Tax Authority). This 20% penalty however is counteracted with Box 3 tax savings if you stay invested for at least 11 years.

Withdrawal at 60 vs. at Pension Age

Some lijfrente products allow flexibility in starting payouts earlier—generally from age 60 onwards, depending on the product terms and tax regulations. The key rules include:

• You may start receiving lijfrente payments at age 60 if the product contract permits and the minimum payout duration is met (typically 20 years for early retirement).

• If you wait until your official AOW age, you may structure shorter payout periods, often between 5 and 20 years, depending on your total pension capital.

• Starting payouts earlier reduces the total investment growth potential but can provide flexibility for those retiring early.

How Withdrawals Work (Lijfrente Uitkeringen)

At retirement, your accumulated lijfrente capital must be converted into periodic annuity payments (uitkeringen). This is done by purchasing a lijfrente uitkeringsproduct from an insurer or bank. You cannot take a lump sum withdrawal (except under strict conditions, such as very small balances).

Once payouts begin, the capital is gradually distributed and taxed, completing the cycle of tax deferral that began when you made your initial contributions.

Pension providers

Here are some pension providers you can go with:

Degiro Pension account

You can use Degiro Pension account and invest in assets(stocks, ETFs, bonds) of your choice. This is what I personally use at the moment. The costs are a bit higher than non pension account though.

Other providers

These are some other providers that I don’t have personal experience with:

• Bright pensioen

• Meesman

• Brand new day

Conclusion

The Dutch pension system is a finely balanced framework that rewards long-term planning and disciplined saving. Its combination of state support, employer participation, and individual flexibility allows residents to build a reliable income stream for retirement. However, it also demands awareness—understanding how the pillars interact, how tax advantages work, and how restrictions like illiquidity can affect access to funds.

By strategically using the third pillar’s tax benefits, maintaining diversification through personal savings in the fourth pillar, and planning around life events and retirement goals, individuals can achieve both security and flexibility. In short, the Dutch system works best for those who actively engage with it—monitoring contributions, adjusting as life changes, and optimizing within the rules to ensure a comfortable and sustainable retirement.

Why amazon.com? As of writing this article, Amazon has a lighthouse score of 97 on performance. Also e-commerce websites are more sensitive to conversion and retention metrics so I thought this was a good example for other websites in the same domain.

Disclaimer: I do not work at amazon and am not aware of their internals, this is the information I gathered by auditing their website.

Why is performance important?

• Conversion and retention: Multiple studies have shown how bad page performance negatively affect conversion and retention rates. This is especially noticeable with users with older mobile phones.

• SEO: Google has started tracking Core web vitals metrics and penalizing websites that score poorly

• Caring about your users: Having a page that loads fast shows that you care about the user experience.

• Brand value: A website with a smooth experience that loads fast creates a perception of quality

• Environment: A page that loads fast consumes less resources (low energy consumption, support for older hardware, less server cost).

The methodology

I use Google Chrome dev tools for everything I’m demonstrating in this article. I’ll go over techniques to optimize for the following metrics:

• Time to first byte (TTFB)

• First contentful paint (FCP)

• Largest contentful paint (LCP)

• Cumulative Layout Shift (CLS)

Time to first byte (TTFB)

This is the time from when a user first requests a page (clicks on a link or types in the URL) to when the first byte of data returns to the browser from the server.

How to measure?

An easy way to do this is to go to the chrome network tab, click on the entry for the document (html) of the page and go to the timing tab.

Here you will see how much time was spent waiting for server response before the content started to download.

There could be other entries here as well like DNS lookup, initial connection, SSL, etc.

Strategies to reduce TTFB

Reducing TTFB is mostly a matter of getting your server to return the HTML document as fast as possible.

• Minimal amount of data calls

  For your server rendered HTML, keep the backend data calls as few as possible. You can render a skeleton of your page and fetch the rest of the data on the client side. We will dive deeper into progressive loading later

• Compression

  Use gzip or brotli for compressing your HTML so fewer bytes have to be transferred over the network. Your web server mostly supports this already, you would just have to enable this

  

  the response header of html would have Content-Encoding: gzip when compression is enabled

• Caching

  This would not apply to websites where the content changes frequently or is personalized per user. If your content remains stable for at least 10 minutes then there might be value for you in enabling caching at HTML level.

First contentful paint (FCP)

This is TTFB plus time taken until the first content (text, image, or non-white canvas or SVG) is rendered on the page. In this section we will focus on the time from TTFB until when the first content is rendered on the page.

Before we get into strategies on how to reduce FCP, it would help to familiarize ourselves on the critical rendering path. On a high level keep the following in mind:

• HTML document is processed and rendered in a streaming fashion. The content received is immediately displayed

• CSS and JS are render blocking resources (by default). When a browser encounters these, rendering is stopped until this resource is downloaded, parsed and executed.

• JS is parser blocking (by default). When a browser encounters JS, it parses and executes it and is not able to parse any other resource at the same time. Render is also blocked during this phase.

How to measure?

For this we would have to look at the Performance tab in chrome dev tools and manually look at the frames section.

1. In performance tool hit the “Record and reload” button on top.

2. Make sure you enable screenshots

3. You can open the frames section and you can select the frame you consider to be the FCP for your users

4. In the summary section at the bottom you can see the frame and the time it took to show it (in Amazon’s case it is 583ms)

Strategies to reduce FCP

• Resource hints

  Add dns-prefetch for resources on cross domain resources (css, fonts, analytics api). You can also explore other resource hints like preconnect, preload and prefetch

  

  you can see here that dns-prefetch is being used at the beginning of the document before loading resources from those domains

• Lean head tag

  The content usually would live in the <body> section of the page. The <head> section should only contain metadata, critical CSS and JS. Keep this as lean as possible. If you have a lot of CSS and JS here then it would block the rendering before content in <body> can be displayed.

• Server side rendering

  If you rely on content to be rendered only on client side then this the user will need to wait until the JS is downloaded, parsed and executed.

• Asset optimization

  By assets here I primarily mean JS and CSS. But you could also apply some of these strategies for fonts and images as well. There are a bunch of strategies here. I would just mention them at a high level without going into too much detail.

  • Leverage CDN for hosting

  • Caching your assets

  • Minification

  • Compression (gzip or brotli). In case of assets, do this at build time as opposed to runtime

  • Only loading the data you need (dead code elimination, remove unused css, etc)

How amazon uses CDN, compression and caching for its assets

• Progressive loading

  You can load a placeholder first and progressively load your page. Amazon first loads a skeleton of the page, then it progressively loads more frames.

  new

  • 

    we can see how amazon first loads a skeleton then proceeds to populate the contents of the page. (The video is taken from the frames section of the performance tab in dev tools.)

• Async and Defer attributes

  Use this to prevent non-critical javascript from blocking the rendering of the page. More details

  

Largest Contentful Paint (LCP)

LCP measures when the largest content element in the viewport becomes visible to the user. This metric is important because it represents when the main content of a page is likely visible to users, directly affecting their perception of site speed.

How to measure?

You can measure LCP in Chrome DevTools by looking at the Performance tab. The LCP is marked in the experience section, typically showing the largest image or text block on your page.

you can see how LCP < 0.58s here

Strategies to reduce LCP

• Prioritize above-the-fold content

  Ensure the largest content element (often hero images) loads as quickly as possible by optimizing and prioritizing it.

• Image optimization

  There are multiple strategies here:

  • Image size matching: display the image at its original size (so the browser doesn’t have to resize)

  • Use srcset attribute to fetch different resolutions for different devices

  • Use webp images else png since they’re more optimized for web

  • Compression: Tools like Squoosh and ImageOptim can help here

• Lazy loading

  Only load images that appear below the fold when the user scrolls down to them. Note that you should NOT lazy load LCP elements.

Cumulative Layout Shift (CLS)

This measures visual stability. It quantifies how much elements on a page unexpectedly shift during loading, which can lead to a frustrating user experience when content moves just as users try to interact with it.

How to measure?

CLS can be measured in Chrome DevTools under the Performance tab.

You can explore layout shifts in the experience section.

Strategies to reduce CLS

• Reserve space for dynamic content

  Amazon pre-allocates space for images, ads, and other dynamic elements to prevent layout shifts as these elements load.

• Use width and height attributes

  Always specify dimensions for images, videos, and other media to help the browser allocate the correct amount of space before they load.

• Avoid inserting content above existing content

  Place new elements at the bottom of the viewport instead of pushing existing content down, which creates disruptive layout shifts.

Final thoughts

Help make web leaner and better. Using the above techniques, you should strive for these targets:

• TTFB <0.8s

• FCP <1.8s

• LCP <2.5s

• CLS <0.1

I also offer a Performance Optimization service. If you’re interested you can contact me here.

Before storing the data in memory, Apollo InMemoryCache processes the data using a technique called normalization. In this article we would look at what normalization means and what it means in the context of Apollo and GraphQL.

What is normalization anyway?

Normalization is an approach of eliminating data redundancy. It is an approach to make sure that there is only 1 record of 1 data. It is a concept originally from databases and is being ported to frontend. normalizr was the first library that popularized using normalization for data management in frontend. It was used mostly with redux. Now it is also being used in Apollo with InMemoryCache.

Let us try looking at an example to understand what is normalization better. Consider a query Product in an e-commerce site that has the fields name, seller and brand.

This would look like this in a table

As we can see here that the seller T-Mobile and brand Apple are being repeated.

Having these duplicate instances of the same data can lead to the following problems:

• Suppose each seller has a verified status next to their account. And for products with verified sellers we show an icon next to it. If for example T-Mobile became a verified seller. Then we would need to update all the products with this information. This is also called Updation anomaly
• By normalizing data and preventing redundancy, we save a lot of memory space. If your app is being server side rendered, this would also mean fewer bytes transferred over the network.

We can prevent this duplication by having only a reference to the seller/brand. This would look like the following in a table. Instead of storing duplicates of the same data, we just store a reference to the data. In databases this concept is called foreign keys.

Normalization in apollo

Let us now see how this looks like in apollo. If we want to fetch products we would have a query like this:

Product {
    id
    name
    seller {
        id
        name
    }
    brand {
        id
        name
    }
}

When we fetch this data, the contents of InMemoryCache looks like this: (Apollo DevTools: Firefox | Chrome)

In the above image you can see how apollo cache stores the query data it receives internally. The cache has an entry for each Product. It also makes a separate entry for each Seller and Brand.

Note at the root level, it has a reference to all the products. Not the actual product itself.

This is how the Product, Seller and Brand look like

Note how the Product has a reference to Seller and Brand.

Now if any information about a Seller or Brand is updated; it is automatically available to all queries that are using it. This is the benefit of normalization since there are no duplicate references of the same data.

Caveat

This only works if you query for the id of Seller and Brand. Consider you query for the data like this without ids:

Product {
    name
    seller {
        name
    }
    brand {
        name
    }
}

For the above query notice how the data is not normalized. You can see how each there is only a ROOT_QUERY and all data are stored in a large JSON.

What to do if id is not present?

You should always try to query an id if it is available in the server. You can try enforcing it by using graphql/required-fields eslint rule.

It can happen that your server doesn't send a unique id for a field or it sends it with a different name. In that case always try to first see if an id can be first sent from the server. If this is not possible, you can generate one on the client side by customizing identifier generation by type. You can use a field with a different name than the default id or _id. You can also generate the identifiers using 1 or more fields. If you want to know how to do this at runtime check out my other article on defining type policies during runtime in apollo

Conclusion

I hope you got a better idea about how apollo cache works under the hood, what is normalization and why it is useful. You can use apollo dev tools to make sure that the data you are fetching in your application is normalized. If it is not, you only have to make sure that the fields have a unique id field. For more information check out the references below

References

• Demystifying Cache Normalization by Khalil Stemmler
• How Data normalization works

Preact is lighter mostly because it doesn't ship synthetic events that are bundled into react-dom. It tries to be as close to browser features as possible. These are all the differences between react and preact.

Aliasing

Aliasing with preact/compat is a good way to migrate your react app to start using preact without changing the source code. All you have to do is add a new alias like this to your webpack config

// webpack.config.js

const webpackConfig = { 
  ...
  "resolve": { 
    "alias": { 
      "react": "preact/compat",
      "react-dom/test-utils": "preact/test-utils",
      "react-dom": "preact/compat",
      // Must be below test-utils
    }
  }
}

During bundling, whenever webpack encounters a file with import ... from 'react', it swaps react to preact/compat. So import React from 'react' becomes import React from 'preact/compat' in the generated bundles. Note that this substitution happens not only for your code but also for the libraries that you're using. So for instance if you're using react-redux, all react imports in the library are swapped to use preact.

If you're using another bundler you can check the official docs here

Server side rendering

The above mentioned technique works well with client but you might face some problems if you're using server side rendering. This is especially true if you have any kind of an externals setup in your webpack config. Externals allows for specifying specific libraries that you don't want included in your generated bundles. Webpack assumes that these would be available at runtime.

Server side rendered applications usually have a different bundling flow for the server than for the client. Thus different bundle(s) is generated for the server than the client. With server side rendered applications, it is a common practice to use node externals which tells webpack not to include bundles in node_modules for the server bundles. These are replaced with require statements which are then resolved by node's module resolution system at runtime.

This brings us a problem if we're aliasing with preact/compat. While aliasing client side modules, we're able to swap react with preact/compat for all dependencies. But when these modules are externalized, webpack no longer go through the dependencies and thus doesn't alias preact/compat. Whenever it encounters a dependency, it says its not my responsibility, let node handle it.

And node has no idea that it needs to swap react with preact/compat. We need to tell it how to correctly resolve react.

Enter module-alias

module-alias is a handy package that allows us to tell node to use preact/compat. It hooks into node's module resolution system and changes it according to our needs. We need to add this code to our application

const moduleAlias = require('module-alias');
moduleAlias.addAlias('react', 'preact/compat/dist/compat.js');
moduleAlias.addAlias('react-dom', 'preact/compat/dist/compat.js');

Note that moduleAlias has to be added with require statement and not an import. This is because imports are not resolved synchronously. And we want moduleAlias to be executed synchronously before the rest of the code that references the aliased modules.

Also note that this has to be at the very beginning of your server execution for it to work.

The standard way of doing this is by defining the type policies during initialization of apollo client like this:

const apolloClient = new ApolloClient({
    ...
    cache: new InMemoryCache({
        typePolicies: {
            // defining field policy for local state
            Article: {
             // Field policy map for the Article type
                fields: {
                    // Field policy for the isBookmarked field
                    isBookmarked: {
                        // The read function for the isBookmarked field
                        read(_, { variables }) {
                            return localStorage
                              .getItem('BOOKMARKS')
                              .includes(
                                 variables.articleId
                              );
                        }
                    }
                }
            },

            // customizing identifier generation
            Book: {
                keyFields: ["isbn"],
            }


            // defining custom merge function
            SearchResults: {
                fields: {
                    results: {
                        merge(existing = [], incoming: any[]) {
                            return [...existing, ...incoming];
                        },
                    }
                }
            }
        },
    });
})

This might not always be possible. You might want to do this at runtime instead. Some of these scenarios:

1. If you are loading different chunks at runtime based on user interaction
2. You have a microfrontends architecture (like in our case).

To do this you can follow these steps:

1. Get an instance of the cache

const { loading, error, data, client } = useQuery(QUERY);

const cache = client.cache

2. Add policies to the cache

To specify key fields for custom identifier generation

cache.policies.addTypePolicies({
    // customizing identifier generation
    Book: {
        keyFields: ["isbn"],
    }
})

Or to define field policy for local storage

cache.policies.addTypePolicies({
    Article: {
        fields: { 
            isBookmarked: { 
                read(_, { variables }) { 
                    return localStorage
                      .getItem('BOOKMARKS')
                      .includes(
                        variables.articleId
                      );
                }
            }
        }
    },
})

Caveat

The reason why it is recommended to configure these at build time is because that way apollo can ensure that the data is not accessed before the type policies are defined. If you want to do this at runtime, you need to make sure that you call addTypePolicies before you call useQuery with the query that uses the type whose policy you are modifying

There are several forms of dead code in javascript

• Unused source files
• Environment specific code
• Unused code in same file

Unused source files

In the early days of javascript this used to be a real problem since unused source files had to be manually cleaned up. But with modern bundlers this becomes a really easy process. If a file is not imported anywhere then it is automatically excluded from the resulting bundle. There are also some plugins like this one which also help us to remove these from the codebase.

Environment specific code

In a real world app we have several environment specific code. These can be production, staging and development, mobile vs desktop or even domain specific logic. So when we build an app for production, we don't want to serve code to the user which is only used during development.

We can do this by using define-plugin in webpack or plugin-replace in rollup.

// webpack.config.js
new webpack.DefinePlugin({
  'process.env.NODE_ENV': JSON.stringify(process.env.NODE_ENV)
});

(webpack 4 does this automatically. this is just for showing what happens under the hood)

// rollup.config.js
plugins: [
  replace({ "process.env.NODE_ENV": JSON.stringify(process.env.NODE_ENV) })
]

What this does is if you have code that looks like the following

let API_HOST;
if (process.env.NODE_ENV === 'production') {
    API_HOST = 'production-host.mycompany.com';
} else {
    API_HOST = 'localhost:9000';
}

Given NODE_ENV=production, it converts it to the following

if ('production' === 'production') {
    API_HOST = 'production-host.mycompany.com';
} else {
    API_HOST = 'localhost:9000';
}

Then the minifier removes the unreachable code, reducing it down to the following,

API_HOST = 'production-host.mycompany.com';

Caveat

This only works if you don't reassign the variable defined in the bundler config. In this case process.env.NODE_ENV.

So if we change the code like the following

let API_HOST;
const IS_PROD = process.env.NODE_ENV === 'production';
if (IS_PROD) {
    API_HOST = 'production-host.mycompany.com';
} else {
    API_HOST = 'localhost:9000';
}

Then the bundler will not be able to eliminate the dead code because it cannot know for sure the correct value of IS_PROD inside the if statement. Since the value could have changed after assignment of the variable and the if statement.

If you do want to use IS_PROD as a variable and have dead code elimination available then you can declare it in the plugin config like this:

// webpack.config.js
new webpack.DefinePlugin({
  'IS_PROD': process.env.NODE_ENV === 'production'
});

// rollup.config.js
plugins: [
  replace({ 'IS_PROD': process.env.NODE_ENV === 'production' })
]

Unused code in same file

There are 2 kinds of unused code that can be part of the same file.

• Unused exports
• Side effects

This is the most difficult type of code to dead code eliminate because Javascript is not a compiled language. However modern bundlers are finding smart ways to do it. They use a technique called as tree shaking where they rely on static structure of ES Modules to achieve it.

Unused Exports

In modern web development, we use various libraries to get the job done. The problem however is that we don't need all the code that the library ships.

Consider a file like the following

// math.js
function add (x, y) {
    return x + y;
}

function subtract (x, y) {
    return x - y;
}

If we have another file where we import only one of the functions like

import { subtract } from './math';

console.log(subtract(3, 2));

Then in the final resulting bundle only the subtract function is included. Add is excluded.

We can also combine this with Environment specific code which was highlighted in the previous section.

import { subtract } from './math';

if (process.env.NODE_ENV === 'production') {
    console.log('This is production');
} else {
    console.log('Subtraction in dev mode only ' + subtract(1, 3));
}

Here we are calling subtract function only in development. In cases like this, subtract is bundled only in development mode. In production mode, neither add nor subtract functions are bundled.

This is possible because ES modules are static in nature as opposed to commonjs modules which due to their dynamic nature makes it impossible for the bundler to determine which modules to tree shake.

if (process.env.NODE_ENV === 'production') {
    require('./math.js').add(1, 2);
} else {
    require('./math.js').subtract(2, 3)
}

This is the main reason why lodash which was based on commonjs modules created a new package lodash-es which is based on ES modules. This means that if we use only 1 function from lodash-es only that function will be bundled into our main bundle.

import { reverse } from 'lodash-es';

console.log(reverse([1, 2, 3]));

In the above example only the reverse function will be bundled into the code.

Side Effects

There is a caveat to tree shaking and that is side effects. Side effects in terms of tree shaking is any code that changes global state or environment in some way. Examples can be polyfills and code in which css files are added.

Consider a polyfill for fetch like this

// fetchPolyfill.js

window.fetch = function(...) { ... }

In the above file, fetch is being added to window object but its not being exported or imported from anywhere. Hence the bundler cannot know that this is used. For these files where side effects are present, we need to explicitly specify them in package.json

"sideEffects": [
    './fetchPolyfill.js'
]

It is then bundled in the application like this:

__webpack_require__.r(__webpack_exports__),(window.fetch = function() ... )

Vendor dependencies

Before using any open source library in your package, you can go to bundlephobia to verify if the package you are using is side effect free and tree shakeable.

References

• Google blog reduce js payload with tree shaking