Paypal-checkout-components: Figure out how we can minify and still be able to debug merchant sites

[bluepnume]

Especially on older browsers where source maps are a no go -- which coincidentally, are the browsers with all of the issues.

(more details in my reply to @slightlyoff below)

[bluepnume]

[bluepnume]

@slightlyoff,

Hope you don't mind me responding here -- saw your tweets and wanted to respond properly, but I can never really say anything meaningful in 140 chars, so wanted to get in touch this way instead. Appreciate your comments.

To give you some background: checkout.js has been around for 2-3 years now, and has accumulated a lot of code, and a lot of technical debt. My team and I came in 3-4 months ago to take it over and overhaul it, and we're in the middle of that process right now.

The open source modules we've released so far -- xcomponent, post-robot, beaver-logger -- all represent our efforts to split out the reusable/non-paypal parts of checkout.js into small, open source modules, which we're trying to keep as lean as possible. The next step for us is to figure out how we can slim down the paypal specific parts of checkout.js

---

Firstly, on the file size. We definitely know it's a problem, and we have a plan to reduce it:

• There's a lot of legacy code that we need to factor out.
• There's also a lot of static content that we need to split out and lazy-load.
• xcomponent alone is 130kb / 32kb gzipped, which is at least manageable for anyone hoping to build similar components.
• Our larger / more advanced merchants we expect to pull the script from github or npm, and use the published minified versions.

There are challenges though:

• Smaller merchants have the most frequent integration issues, especially on older browsers without source-map support. We get a huge number of support requests from these merchants, on an almost daily basis.
• We have those guys using checkout.js by default, because being able to debug unminified code with proper stack-traces etc. is often the only way we can support these merchants.
• Our end-game is to have the checkout.js url minified by default, and be able to switch off minification on a per-merchant / per-user-agent / per-cookie basis so we can debug. This is a work in progress, and we're having to work with our CDN provider to get there.

So, just so you know we didn't forget to minify the script. :) It's a trade-off between speeding up our merchants' sites, and being able to support them, and it's a problem we're actively working on fixing.

---

On the web component thing: sorry for being misleading here. You're right, xcomponent doesn't use web components (yet), mainly because of the lack of browser support.

The way xcomponent works is to let you set up a spec for the component, then it auto-generates bindings for you in popular frameworks like React, Angular, etc. so people can drop-in the components you write. The plan is to create bindings for web-components too. So we're set up to be able to support these, it's just not the biggest priority at the moment.

I've edited the title of the article to just read "components" rather than "web components". I was really just going for "cross domain components for the web" rather than specifically "cross domain web-components".

---

Sorry for the lengthy response, happy to take any advice you have on any of the above!

Best,
Daniel

[slightlyoff]

Heya,

Thanks for taking the time! Happy to engage anywhere that makes sense for y'all = )

First, happy to hear that you've got size reductions planned and good to know that you're working to get the minified sources to more users. That'll have a huge impact.

I have some questions!

• What's the browser support matrix for checkout.js?
• Is that matrix any different for mobile vs. desktop?
• How tightly do you control the the CDN infrastructure that served checkout.js? Can you serve different versions to different UAs?
• I noticed that a meaningful % of the total byte count is translations. Any chance those can be lazy-loaded or included based on headers and not baked into the default binary?
• Related to the browser support question (and contingent on it), have you looked at using raw Web Components for your component model and polyfilling where that's not possible? Might get you some nice savings and a clean way to integrate with embedders.
• Do you have a size/perf budget for the project?

Thanks again for engaging and apologies for the tone of my tweets.

Regards

[bluepnume]

Hey,

What's the browser support matrix for checkout.js?

        Chrome: 27,
        MSIE: 9,
        Firefox: 30,
        Safari: 5.1,
        Opera: 23

Is that matrix any different for mobile vs. desktop?

Right now for mobile users, checkout.js doesn't do much other than a full-page redirect to PayPal. That's changing though; we're about to start ramping up mobile users, so we'll be defining that matrix soon based on the spectrum of traffic we have right now.

How tightly do you control the the CDN infrastructure that served checkout.js? Can you serve different versions to different UAs?

In theory yes, but in practice the infrastructure is a little inflexible, and it takes time to get things pushed through, especially during the holiday season. Depending on what the estimate is from those guys, I may just enable minification / source maps across the board, in the short term.

I noticed that a meaningful % of the total byte count is translations. Any chance those can be lazy-loaded or included based on headers and not baked into the default binary?

Yep. Those are some of the static resources mentioned above. We absolutely plan to lazy load them. This is being tracked here: https://github.com/paypal/paypal-checkout/issues/90

Related to the browser support question (and contingent on it), have you looked at using raw Web Components for your component model and polyfilling where that's not possible? Might get you some nice savings and a clean way to integrate with embedders.

The problem is, we support three different flavours of component:

1. Inline iframes
2. "Lightbox" style iframes, which are fixed position and outside of the normal document flow
3. Popup windows, which are visually similar to lightbox iframes but obviously totally outside the DOM.

Web components (along with those React/Angular bindings I mentioned) seem to only really make sense as a means of using inline iframes. That's why we were thinking about adding them as another driver for inline frames, alongside the React/Angular bindings.

Also -- and I might be betraying my lack of knowledge about web components here -- do they provide any way to pass down data types like functions, objects etc? Callbacks are an important part of xcomponent's props.

Do you have a size/perf budget for the project?

Nothing formalized. The plan is just to make it as streamlined as possible, given the myriad of features we have to support.

Thanks!
Daniel

[carlosds730]

Any news with this?

[albv]

@bluepnume as you said here https://github.com/paypal/paypal-checkout/issues/443

There's a minified version at https://www.paypalobjects.com/api/checkout.min.js which clocks in at 98kb.

Now it's 893KB and non-minified version (that we supposed to use if we want benefit from cashing) is 1.5MB! I am sorry but this size is just ridiculous, it's bigger than my entire SPA with Angular 5, RxJs, and bunch of other dependencies. And our users need to download all this code just to render the button which they may never ever click.
Can I somehow render the PayPal button by myself so all the heavy downloading starts only when user clicks it? This way it won't affect all our users at least.

[ryanrca]

Is there any movement on this? We committed to vue-paypal-checkout months ago. Because the vendor bundle that incorporates paypal-checkout is 1.5 megs of javascript, we are getting severely punished by google speed test.

When I remove paypal-checkout from our build, the bundle size goes below 300k.

Without an alternative solution, we are considering completely removing support for paypal from our store.

As @albv pointed out, the "minified" version is huge (just downloaded today, it's 962K).

I'm all ears for better ideas...

[alvipeo]

Elon Musk is busy with submarine.

[albv]

@ryanrca I think for now your best option is to load checkout.js asynchronously when user somehow selects PayPal as a payment method. Something like this https://github.com/paypal/paypal-checkout/blob/master/docs/performance.md#delayed-render should work but maybe you will have to drop vue-paypal-checkout wrapper

[bluepnume]

Solved for new payments sdk, in pilot. Solution was to add a &debug=true param which spits out unminified code. In the mean time please feel free to use checkout.min.js.

[github-actions[bot]]

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new issue for related bugs.