I’d like to bring up the ongoing issue of low site performance I’ve been experiencing on Google PageSpeed Insights. Despite extensive optimizations, the performance score for the mobile version stubbornly remains below 80. I’ve followed all recommendations from both the community and Webflow’s official support. Unfortunately, Webflow’s advice often seems inadequate for a platform that prides itself on being low-code and claims to facilitate website creation without coding expertise. Moreover, their suggestion to disregard Google’s analysis in favor of Pingdom strikes me as peculiar, especially since Webflow’s own site performs well on Google PageSpeed Insights, suggesting that other sites built on Webflow should be capable of similar achievements. However, Pingdom has its own set of limitations, such as not assessing mobile performance and geographic restrictions on its page speed monitoring service in its paid version.
Despite these efforts, none of the strategies have effectively addressed my main issues highlighted by Google: the First Contentful Paint (FCP) and Time to First Byte (TTFB). These challenges seem deeply connected to server, DNS, CDN, and related factors. It’s worth noting that the difference between the Largest Contentful Paint (LCP) and the FCP is less than 0.2 seconds, which suggests rapid loading once the process begins.
Given this situation, I’m keen to receive any advice or insights you might have. Maybe there’s something I’ve missed. Although I don’t claim to be the best developer out there, I consider myself competent and have implemented several optimized, minified custom codes. For example, one script delays the Google Tag Manager (GTM) to speed up site loading and mitigate script blockages. Contrary to Google’s recommendation, I’ve also experimented with placing the GTM code just above the footer, along with other codes, to gauge its actual impact, which appears to be minimal. The core issues seem to indeed revolve around FCP and TTFB. As a user of the Webflow Business plan, I find this level of performance highly disappointing.
An additional point to consider is my location in São Paulo, Brazil, which should be taken into account when assessing performance.
I’m hopeful for any insights that might help improve the situation.
It’s incredibly difficult to get a high mobile score in Google PageSpeed Insights as they are emulating an old-fashioned device on a slow connection. You’d be better off looking at the Core Web Vitals metrics above, which are based on real-world use and are actually what Google is judging you on.
All the answers to why your site isn’t doing too well are in the report. You need to optimise your site in order to get it to perform. Apparently, you have an excessive dom size. Make sure you optimise your stylesheet so that you’re not repeating yourself with classes to reduce your CSS file size. Global classes applied on top of another class can be more efficient than making many repetitive combo classes. Defer any third-party code or stylesheets so they’re not blocking the loading.
Just remember that the majority of mobile devices now have chips far faster than a Moto G and that internet speeds are getting faster and faster; therefore, slow 4G throttling isn’t really a real-life conditioned test. Either concentrate on the Core Web Vitals, which has real-world results, or run your own lighthouse reports in Chrome with more realistic throttling and conditions.
I’ve been putting a lot of effort into improving performance across various evaluation sites, and I’m happy to report that I’m now seeing higher numbers than I did 15 days ago.
Most of my efforts have been focused on cleaning up the CSS by reducing redundancy in some classes and applying more grid and flex layouts instead of creating classes for adding “more padding on the right/less padding on top,” etc.
Additionally, I’ve reviewed some of my scripts, tested a bunch of things, and achieved better performance in this area as well.
I’ve also optimized a lot of images. Currently, the images are very optimized. All of them are strictly the minimum size necessary, with the correct height and width for the layout. And, of course, they are now in WebP or SVG format.
Now, I’m trying to improve other aspects of the analysis, such as accessibility, SEO, etc. Unfortunately, I’m not sure how to reduce the number of DOM elements on the page. I tried some scripts to load only the visible elements, but it didn’t work well—especially since some scripts rely on the hidden elements to build parts of the pages.
Anyway, if you have any more thoughts about optimization, please let me know.
This is very interesting. I’m trying to work through ‘correcting’ all the recommendations in Core Web Vitals, but hit a complete stop. My homepage LCP is 4.6s and CLS 0.22. So as a test I tried a fresh page on the site with one small image and a rich text box. Tested again and my LCP is STILL 4.6 and CLS 0.2.
I tried a completely blank page on the site and get the same result. I’m on Webflow Business Hosting.
@ConnectCreativeDes - Webflow performance boils down to choices you make at the project level. This would include how large your stylesheet is, how many interactions, the amount of assets used on a page, and what additional scripts you are loading. So since this is project/page specific there is no way to tell you what is causing your performance problems without looking.
Hi, thanks for the swift response. As a test I tried removing any external scripts (only used x2: cookie and hubspot scrips) and any interactions used (of which there are hardly any). All images are Webp where possible and pretty tiny. Still getting really disappointing speed test results.
I don’t really understand what else I can do apart from rebuild from scratch, testing at every stage of the build. Would a sloppy approach to class naming conventions affect the score? I know that’s something I need to get better at.
@ConnectCreativeDes - Hubspot scripts have a large impact on loading/performance so test without it to see the impact. I have mitigated it for some clients by using custom code to load based on user behavior (click, scroll, etc). Second a published URL is where testing is done/inspected.
