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.
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?
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?
UPDATE with what I have found out since my last post, in case it helps anyone else:
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?
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.
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.
@LewisKoch8
No progress to speak of. I think the sages of the forum are losing their enthusiasm due to Webflowās flailing roadmap decisions.
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.
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.
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.
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!
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.
This is bonkers. There are no controls to add lazy load scripts on a page. Itās poor from Webflow. I have the same issue. Stripe is causing very slow loading on product pages. If it was on the checkout page checkout page I could live with it. I might trial a period and turn off stripe. But thatās not a solution is it?
2024 and this is still a significant issue! Iām becoming more and more disillusioned with Webflow, the longer I use it. It seems āthe powers that beā have their own roadmap based around what will impress the future ābuyersā of their platform, rather than their users. Thereās no denying, it is a fantastic platform for no coders like myself, but the number of issues that crop up (such as this one), that seem to be handled with ease elsewhere, means that I too am seriously looking at moving my client sites to another platform. Webflow need to listen to ALL issues raised and not just cherry pick those that they feel comfortable with. Rant over, peace, out!
