Adyen / adyen-web

Adyen Web Drop-in and Components
https://docs.adyen.com/online-payments
MIT License
174 stars 128 forks source link

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

Closed JStonevalley closed 1 week ago

JStonevalley commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

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

steffenmllr commented 3 years ago

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

matsinfiltratingvy commented 3 years ago
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 commented 3 years ago

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 commented 3 years ago

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 commented 3 years ago

@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 commented 3 years ago

@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 commented 2 years ago

@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 commented 2 years ago

@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 commented 2 years ago

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

image
m1aw commented 2 years ago

@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 commented 2 years ago

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.

image

m1aw commented 2 years ago

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

kholiavko-roman commented 2 years ago

@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 commented 2 years ago

@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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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

aralroca commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 1 year ago

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 commented 9 months ago

@sponglord Is there a timeline for v6?

sponglord commented 9 months ago

@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 commented 9 months ago

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

Screenshot 2023-11-03 at 23 13 23
carly-cloud commented 6 months ago

any news here?

ribeiroguilherme commented 6 months ago

Hey @carly-cloud ,

We are currently working on the new major version which will reduce the bundle size. There are some details to wrap up still, but we are aiming for the end of February hopefully.

fahu commented 5 months ago

@ribeiroguilherme Any updates on this already? :)

ribeiroguilherme commented 4 months ago

Hey @fahu ,

We do have some updates 😄 we are working on it and wrapping up the final details. We also released an alpha version on npm, but that is mainly for our internal teams to test the changes. There is no migration guide nor tutorial explaining how to try the alpha in case you are interested, although our team is also working on that.

In the upcoming weeks we will do a release candidate along with the migration guide/documentation 🙏

As we are performing tests now, could you (and also the other people that are following this thread) share more about your web app tech stack? Ex: webpack 4 or 5; vite; UI framework (react, svelte, etc); Nextjs, Nuxtjs, etc. These details can help us make sure we will test for different use-cases.

fahu commented 4 months ago

Thanks for the update @ribeiroguilherme :) Looking forward to try it out! Tech stack is Angular 16 (probably 17 soonish) + Webpack 5.

juliavanmourik commented 3 months ago

Thanks @ribeiroguilherme ! I've been checking this thread for a while now. Looking forward to the release as well. We're on nuxt3/vite

jorgenboganes commented 3 months ago

We are using Next.js 13.0.7 and whichever module bundler that entails.

ribeiroguilherme commented 3 months ago

Thanks for sharing guys - we will make sure to test the alpha version on these setups 🙏

brunolopesr-dft commented 2 months ago

Here we are using Vite to bundle a React app for our checkout

image

It's a huge bundle size included in our app to use only the secured fields component and pt-BR locale.

Waiting for 6.0.0 stable release to land, hopes this will fix the problem.

camil-adyen commented 1 month ago

Hi all!

A BETA version of Web v6 is now available on Github. Feel free to take a look and give us feedback! We aim to release the official v6 in the coming weeks. More information can be found here.

sponglord commented 1 week ago

The major release, v6.0.0, was launched today! See the documentation here:

Specifically, you'll be interested in the section on treeshaking: Import Drop-in with individual payment methods