ā–¼
Streaming live at 10am (PST)

Defer loading of e-commerce scripts and other optimisations

Design help Ecommerce
#1

Hello everyone,

  1. Is there a way to defer the loading of the cart of an e-commerce store, until the page has been painted?
    Would such a thing be advisable?
    The external scripts of stripe and paypal seem to be causing somewhat of a bottleneck.

  2. I am using 2 Google fonts on my site (Josefin Sans and Teko), causing 12 requests in total.
    Would it be advisable to download the fonts and upload them as a custom font?

  3. On my homepage, past the fold, I have a Collection of all my products, populated with inline img elements with custom attribute loading="lazy".
    I additionally implemented pagination and infinite scroll.
    This last step didnā€™t significantly improve my performance score, and in fact it seems that the extra script may cause small delays from time to time. Is that because images were set to lazyload already? Is it worth having the infinite scroll?

Is there any other optimisations I should be aware of, besides compressing images to death?

Here are my links:
published: https://www.milkshaken.net/
read only: https://preview.webflow.com/preview/milkshaken?utm_medium=preview_link&utm_source=dashboard&utm_content=milkshaken&preview=239060f8817d66eb084e4bc18c6da8cd&mode=preview

Thank you in advance for your help!

#2

UPDATE with what I have found out since my last post, in case it helps anyone else:

  1. Self hosting the fonts definitely offered me a significant speed advantage. I am next going to look into adding WOFF2 as a preferential file type with WOFF as a fallback to see if that will offer a significant boost. Does anyone have insights/ how-to advice on that?

  2. It turns out that the infinite scroll solution I was using was too laggy and clunky. Since upgrading to @Finseetā€™s free cms library component and playing with the pagination settings a bit, my performance shot up a good 15%. So that one is definitely a go-er, and highly recommended solution.

#3

As to issue 1:

I am still looking for information about deferring e-commerce specific payment scripts.
Stripe & Paypal scripts represent 20% of assets by size for my site, and they load right in the beginning.
Yet no one is likely to add anything to cart/proceed to pay while the page is still painting.
Is this really necessary?
This is the case even in pages of the site with no specific e-commerce features, such as the blog.
Seems pointless to have these often bloated error ridden scripts have such high priority.

I am definitely not an expert, so I coulb talkin sh*t.
Please do let me know if that would be not advisable and why, and if itā€™s possible to remedy on my end.

2 Likes
#4

Hi there, did you get anywhere with this? Having the same issue :slight_smile:

#5

@LewisKoch8
No progress to speak of. I think the sages of the forum are losing their enthusiasm due to Webflowā€™s flailing roadmap decisions. :cry:

I did send an email to support, asking if/how I could defer the scripts.
They unfortunately side-stepped the issue by letting me know that the scripts are necessary on all pages due to compliance with security considerations set by the payment providers.

Here is the answer:

I am here to help you with your question regarding the deferment of ecommerce payment scripts.

Unfortunately, this is not possible as they are crucial to ecommerce functionality, even on pages that might not seem like ecommerce. ā€œDirect quote from one of our ecom engineersā€ For example, any page that could have the ā€˜cartā€™ on it would require them.

You can refer to this post on Stripeā€™s site in regards to fraud detection: Advanced fraud detection

Which wasnā€™t quite what I asked.
Clicking through to the link provided reveals that Stripeā€™s anti-fraud scripts are needed to record user behaviour that might be suspicious, but that does not seem to be incongruent with making them load last. At the very least, a more in depth explanation may have been a little more appeasing.

To be honest, I donā€™t think there is anything we can do about this issue while hosting on Webflow as it sounds like a server side optimisation. I was bringing it to their attention as it seemed to me like a valid point that could improve lots of peoples load time.

Maybe you can try messaging support too, see what they say.

#6

Your point is a valid one. The problem is we have ZERO control over the loading of core (Webflow) scripts. With the new Google Page Experience and Core Web Vitals playing a new role in SEO, I am busy building new replacements for existing sites off WF where I can drive. Speed does matter.

#7

Thank you very much for your reply, it feels very good to know I was on to something after that blazƩ response I got from Support.

It is also very helpful to definitively know that I cannot do anything about it, so that at least I can stop barking up that tree now. Thank you for that.

I wish your answer had come directly from them, to be honest.
I would not view a precise delineation of limitations of WF as a failure, but as I tool that I can use to best work within them. Then I can focus on things I do have control over to improve speed.
Given the target market of WF, I think a lot of people would benefit from clear answers/ list of things that they cannot do on it.

@webdev I do hope you will not entirely leave this forum, as it will definitely be a poorer place without your expertise!

1 Like
#8

Iā€™m in the same boat currently, trying to work on optimizing multiple sites, but there is only so much you can do before you reach the limitations of Webflow. Iā€™d really appreciate more choices regarding the loading of scripts.

1 Like