Reduce Bundle Size (excluding unused i18n and payment methods?)

[JStonevalley]

Is your feature request related to a problem? Please describe. The bundle size of the SDK is huge. There seems to be lots of i18n in the bundle that I will never use. As well as functionality for unused payment methods.

Describe the solution you'd like It would be great if it was possible to include only the languages and paymentmethods that you need in the bundle to reduce the size.

Describe alternatives you've considered Same as above

Additional context

[marcperez]

Hi @JStonevalley,

Thanks for reaching! That's indeed something we want to improve and is in our roadmap and will be part of an upcoming major release.

[JStonevalley]

Ok so there are no such options available at the moment? Is it part of the next major release or is it further down the road?

[marcperez]

Hi @JStonevalley,

Unfortunately, we don't have a timeline at this point, but it's something we are prioritizing for the next major version.

[nachogarcia]

It might be great to have also a ES6 build so we can use it for modern browsers and reduze some size.

[steffenmllr]

121.5kB Minified + Gzipped is more than all our other vendor packages combined https://bundlephobia.com/result?p=@adyen/[email protected] - would be great if you could prioritize this.

[matsinfiltratingvy]

Bundle without adyen: 232 KB (76 KB gzipped)
Bundle with adyen: 856 KB (227 KB gzipped)

So our entire webapp is about 200 KB with all code, css, libraries etc. Until we import adyen-web and it explodes in size. Given the millions of times this code is downloaded each day, you really should spend some effort on making it smaller (or allowing us to only pull in the needed parts)

[marcperez]

Hi @matsinfiltratingvy,

Thank you for your comment. We're aware of this and currently working on a solution. The first step will include dynamically loading the language translation files and it will be released as part of our next major version (v4.0.0, which is planned for release in the next few weeks). After that, we're also planning on a similar solution for the different payment methods included in the library.

Please, let us know if you have any specific suggestions or feedback on this. Hope this helps!

[matsinfiltratingvy]

Hi, thanks for getting back to me.

One thing could be to write it in such a way that it's easier to tree-shake/only include what's being used. Right now one passes in a string for which component to be rendered, which means you have to look it up dynamically and thus have everything in the bundle.

Instead, if we had to pass in the specific component, we could make sure to only include the needed ones in our bundle. Of course, this makes the outward facing API not as smooth to use since not everything is included by default.

// Now:
import AdyenCheckout from '@adyen/adyen-web'
const config = {...}
const adyenCheckout = new AdyenCheckout(config);
adyenCheckout.create('card', {....}).mount("#id");

// ===================
// vs maybe something like this
import AdyenCheckout from '@adyen/adyen-web/checkout'
import Card from '@adyen/adyen-web/components/card'
import PayPal from '@adyen/adyen-web/components/paypal'

const config = {...}
const adyenCheckout = new AdyenCheckout(config);
if (selection === 'card') {
    adyenCheckout.create(Card, {....}).mount("#id");
} else if (selection == 'paypal') {
    adyenCheckout.create(PayPal, {....}).mount("#id");
}

// or maybe some changes to the API when it's not stringly typed, like
new Card(adyenCheckout, {...}).mount('#id');

// ===============
// or instead if you still want the API to be mostly the same, maybe one could pass in the available components in the config,
// and then it's up to us to load the needed components.
// Here one could also maybe have a "import AllComponents from @adyen/adyen-web/components", such that people not caring about bundle size or just want it up and running have an easier way
import AdyenCheckout from '@adyen/adyen-web/checkout'
import Card from '@adyen/adyen-web/components/card'
import PayPal from '@adyen/adyen-web/components/paypal'

const config = {
   ...,
  availableComponents: [Card, PayPal]
}
const adyenCheckout = new AdyenCheckout(config);
adyenCheckout.create('card', {....}).mount("#id");

Just some suggestions, details aren't so important, the point is to be able to import only what's needed. Same goes for locales. Instead of you bundling everything and choosing texts based on a parameter, one could just provide the texts directly. So something similar to this: https://docs.adyen.com/online-payments/components-web/localization-components#customize-localization But instead of making a custom, one just pulls in the wanted texts.

import AdyenCheckout from '@adyen/adyen-web/checkout'
import English from '@adyen/adyen-web/types//language/locales/en_En'
import Norwegian from '@adyen/adyen-web/types//language/locales/no_NO'

const config = {
   ....,
   translation: lang == 'no' ? Norwegian : English;
}
etc

Just some thoughts on how to make it more modular.

[herecydev]

@marcperez any further update on this, Adyen is by far the biggest offender for us right now. @matsinfiltratingvy suggestion would work well for us!

[marcperez]

@marcperez any further update on this, Adyen is by far the biggest offender for us right now. @matsinfiltratingvy suggestion would work well for us!

Hi @herecydev,

Thanks for bumping this. From v4.0.0, when using the ES Module version (through NPM), we currently dynamically load the language files. This should reduce the size of the library from the original 140KB to around 80KB. We understand size is an important point of improvement and we will continue our efforts in this direction, for example, exploring how we can dynamically load payment methods as well in the future.

Hope this helps and we're always happy to hear of any idea or feedback, thanks!

Also, thanks @matsinfiltratingvy for the great ideas above!

[herecydev]

@marcperez I've also notice that there is a dependency on preact. That's somewhat weird, as we are running within the context of React, so we're now having to use 2 frontend libraries.

However if you just relied on react, then consumers can make the decision whether to use preact/compat and switch to using preact. This is the only library where I've seen a reliance on preact like this.

[marcperez]

@marcperez I've also notice that there is a dependency on preact. That's somewhat weird, as we are running within the context of React, so we're now having to use 2 frontend libraries.

However if you just relied on react, then consumers can make the decision whether to use preact/compat and switch to using preact. This is the only library where I've seen a reliance on preact like this.

Hi @herecydev. Thanks for your comment. Indeed, we do use preact for our components (and not React). One of the considerations on this choice is the small size of the preact dependency (around 3KB). Since this library should work independently of the framework used on the application where it runs, we can't rely on the consumer using React (it could be Vue, Angular, or no framework at all).

Hope this clarifies and thanks again for the feedback!

[kholiavko-roman]

The bundle size was increased even more in the last versions 😔

[m1aw]

@kholiavko-roman which version are you using? Has mentioned in #1343 we now provide a modern version for everyone that doesn't need to rely on polyfills for browser compatibility.

[aralroca]

E-commerce has to go fast, Adyen slows us down, it is currently the largest piece of JavaScript in our project, would it be possible to dedicate to reduce this size? Thank you.

[m1aw]

@aralroca have you tried using the bundle available in lib/dist/es.modern/?

[kholiavko-roman]

@m1aw I am using 5.15.0 How we can use a lib/dist/es.modern/ version of lib if we just using just the npm package?

[m1aw]

@kholiavko-roman Depends a bit on the bundler that you are using, some version of webpack/rollup support different ways of doing this. In principal you should be able to just prefix your imports with modern, like:

import AdyenCheckout from '@adyen/adyen-web/modern/';

If this doesn't work you can try to point to the full path: ./dist/es.modern/index.js

WARNING: This version doesn't come with polyfills. So if you targeting specific browsers versions like IE11 you will need to provide your own polyfills.

[fahu]

We are also struggling with huge bundle size caused by the Adyen dependency. Especially with payments user loading time is super important and is right now our biggest pain point with the Adyen web components.

[RyanONeill1970]

Apologies for the off topic point, @aralroca can you tell me how you prepped the js file size / names to go into that Voronei map?

[m1aw]

@RyanONeill1970 it's part of webpack-bundle-analyzer, hope that helps.

[aralroca]

Apologies for the off topic point, @aralroca can you tell me how you prepped the js file size / names to go into that Voronei map?

I use Webpack bundle analyzer: https://github.com/webpack-contrib/webpack-bundle-analyzer. The bundles are mounted by Next.js Webpack logic, I don't know internally how they organize dependencies and page code, but normally looks good.

[welschmoor]

Any updates on this? It's 267kByte now.

I don't think it's a huge issue, since the code does not seem to be bundled on initial load but only when I go to checkout. So, things are not as scary as the bundle analyzer makes it out to be.

[holgerh]

This is very important for us. The modern version adds 216KB (gzipped) to our checkout. That is by far the greatest download and we would very, very much appreciate to be able to exclude not needed payment-methods and languages from the bundle.

[jorgenboganes]

This is also very important to us. Adyen is 50% of our page load due to a ton of payment methods and languages being loaded for no reason. It would be very nice to have the option to exclude languages and payment methods.

[sponglord]

Closing this issue. FYI - we are in the process of planning adyen-web v6. One of the man features of this will be a reduced bundle size (including a rethink on how we include the language files)

[MakChan]

@sponglord Is there a timeline for v6?

[sponglord]

@MakChan - we are aiming for the end of November / first week of December. However this is a loose deadline and could be subject to change, particularly as the end of the year represents Peak season, which can affect our release schedule.

[gorkemcnr]

I have also experienced the same issue. To avoid to load unused locales, I have come up with following workaround with using Webpack IgnorePlugin which works pretty decent.

Add the following code part into your webpack.config.js with adding locales to AdyenWebExcludedLocales that you want to exclude them from bundle

//webpack.config.js

const webpack = require("webpack");

const AdyenWebExcludedLocales = new Set([
    'cs-CZ',
    'el-GR',
    'es-ES',
]);

const adyenIgnorePluginConfig = new webpack.IgnorePlugin({
    checkResource(resource, context) {
        if (!/@adyen\/adyen-web\/dist\/es/.test(context)) return false

        // Extract the filename from the resource path
        const parts = resource.split('/')
        const filenameWithExtension = parts[parts.length - 1]

        // Remove the file extension
        const filename = filenameWithExtension.replace(/\.[^/.]+$/, '')

        return AdyenWebExcludedLocales.has(filename)
    },
});

module.exports = {
  plugins: [adyenIgnorePluginConfig],
};

In bundle analyzer, it looks as follows now

[carly-cloud]

any news here?