We are currently working on enhancing the performance of our website, and one area we’ve identified for improvement is the size of the main document that loads upon accessing our site.
The current document size appears to be significantly larger (247kb) compared to other websites, and we believe that optimizing it could contribute to a smoother and faster user experience.
Could you please provide guidance on how we can reduce the size of this main document?
Thank you in advance for your prompt attention to this request.
Hi @ARamanovich I ran your website through Google Lighthouse for mobile and desktop and there’s a lot of opportunity to improve (FCP on mobile is hit hard by your hero image, creating a media query to serve a smaller version of the image would go a long way).
For your main question though, your website can’t be prerendered, which is likely the biggest culprit for the file size. (HubSpot Prerendering docu)
The most common cause for this is when you have smart content - this prevents the code from being cached server-side which increases load time as it has to load everything new each time.
It looks like you’re trying to customize content based on IP country:
"- This page uses an uncacheable expression. ([contact.ip_country])",
"- This page uses an uncachable value. ([value contact])"
Since you have a language switcher for multiple countries/languages, my guess is that you have a script running to check the country IP to serve the corresponding language content.
Depending on how visitors are arriving at your site (what channels and if they’re regionalized) and if you’ve optimized content for each country/language (regional SEO), Google should serve the correct language in the SERPs so this shouldn’t be necessary.
Hi @Jnix284
Thank you very much for providing the information; it’s indeed very helpful. I’ve reviewed the errors indicated in the hsDebugOnly mode and disabled the modules on the test page where those errors occurred. However, I still see the message “This page can be prerendered!”
Yes, you are right.
I fixed it on the leverx.com page. But the file size remains the same and page speed indicators too. Maybe you can look at them again and advise what can be improved (desctop interested). As I noticed, due to the size above 200 kb, the best practices indicator does not work.
This is very important for our project now. Thanks in advance
2 - FCP/LCP - nearly all of this has to do with the way the theme is coded and the amount of CSS you’re loading - loading asyncronously for modules not visible in the viewport will help a lot here
4 - TBT - third party code is hitting you pretty hard with GTM and Clarity, you might want to check your GTM isn’t executing more than once and that your tags are properly configured
5 - TBT - exessive DOM size is being caused by the form, especially since you have the phone country dropdown.
I would move your form to a dedicated landing page for conversions, update the home page to have a CTA section that drives visitors to the form page.
I’m not sure what your conversion rate is on your home page form, I would bet that it is really low for first time visitors and if it’s high for return sessions then it’s because you don’t have a clearly defined conversion path.
If you keep the form, there won’t be anything you can do to optimize this issue.
In general, your images aren’t being deferred (lazy loaded) when they are out of the viewport, this will help across all pages.
How the custom theme is coded plays a huge part in how you can optimize, I don’t know the ins and outs of your theme to make specific code recommendations.
It looks like the main document is around 247 KB, so I’d focus on finding what is contributing most to the HTML size rather than just trying to minify the entire document.
A few things I’d check next:
Review the page source for large sections of repeated or unnecessary HTML, especially navigation, mega menus, hidden sections, and duplicated components.
Check for large inline CSS, JavaScript, JSON/data blocks, or embedded configuration being included directly in the document.
Look at the DOM structure and remove unnecessary elements or deeply nested containers that aren’t required for the initial page.
Check whether content that isn’t needed immediately can be loaded later instead of being included in the initial document.
Also compare the actual HTML size vs. transferred size in Chrome DevTools, since compression can significantly reduce what is transferred over the network.
The goal would be to keep the initial document focused on the content needed for the first render and move non-critical content out of the critical loading path.
If you prefer a quicker approach for some performance improvements, tools like Website Speedy can help with areas like asset optimization and frontend performance improvements. It’s optional to use.
