Optimize Speed Index

Ask the community
, ,
1

I’m having trouble with
My Wix Studio website is loading very slowly on mobile according to Google PageSpeed Insights. The mobile performance score is very low (37), with a Speed Index of 11.6 s and Largest Contentful Paint (LCP) of 12.7 s. I want to optimize the loading performance, especially above-the-fold rendering, but haven’t seen improvements despite optimizations.

Working in
Wix Studio Editor (Dev Mode enabled)

Site link

What I’m trying to do
I want to optimize the page loading performance, specifically:

  1. Improve overall mobile performance score to 80+
  2. Minimize LCP and Speed Index
  3. Optimize First Contentful Paint time
  4. Ensure content loads progressively without layout shift
  5. Implement efficient lazy loading for below-the-fold sections

What I’ve tried so far
Used lazy loading with Velo on lower sections of the page.

  1. Added lazy loading with Velo on all lower sections using Box wrappers and onViewportEnter()
  2. Compressed and converted all images to WebP format
  3. Minimized animations and heavy visual assets
  4. Used Wix Studio’s built-in optimization options where possible

Extra context
PageSpeed Insights metrics:

  • First Contentful Paint: 4.6 s

  • Largest Contentful Paint: 12.7 s

  • Total Blocking Time: 820 ms

  • Speed Index: 11.6 s

  1. Mobile score is much worse than desktop.
  2. Hero section contains image + text + call-to-action buttons.
  3. Using lazy loading for below-the-fold sections / Lazy loading is working for lower sections, but LCP is still very high.

image
image1081×898 84.8 KB

2

Hey!

Taking a quick look, there are a few things that can be done, that will likely help :slight_smile:

A few notes:

The “lazy loading” isn’t actually lazy loading, and is unlikely to make much, if any difference to the speed. The elements are still loaded in to the DOM, but hidden. There’s not much difference between them being hidden vs not as they still have to be loaded into the DOM.

I noticed you have a number of different fonts on the site - it’s best to limit yourself to 2 or 3 at most. Here’s just a few that I noticed:

  • Poppins semi-bold
  • Poppins extra-light
  • syne
  • Wix Madefor Medium Bold
  • sora
  • poppins-v2

Each is having to load the font file into the browser which contributes to overall loading speed.

I saw you also have code added via the Custom Code in the site dashboard. This is often a bottleneck if you have multiple scripts etc. It’s always worth asking “Do I need this?”

There’s a lot of images being loaded above the fold (the image carousels), slideshow of the people, background image etc. It might be worth considering a static row with SVGs of the logos?

As a general rule of thumb, you should prioritize real world usage over simulated tests. When you open on an actual phone, does it load quickly, or not?

2 Likes
3

Hii, @Abhijeet_Rawat

I understand your desktop is fine but mobile LCP/SI are high. You can do a few things that move your mobile into the 80s.

Focus on the Hero Section

The biggest delay is usually from the first big visual, the banner, image, and video at the top.

Make sure your hero image isn’t too large. Export it close to 1200 px width for mobile and save it as WebP.
In the Wix Studio Editor, select that image → Settings → Load behavior → Load immediately.
If it’s a video, switch it to a still image preview with a ‘play’ button. Videos really slow things down on first load.

Cut Down What Loads at the Start

When a page opens, browsers try to load everything at once: scripts, widgets, fonts. We need to delay a few like

In Dev Mode, move optional scripts (chat widgets, popups, analytics) to load after user interaction or on scroll.
In Fonts, keep only one or two font families and weights. Extra fonts block rendering.
Disable any apps or embeds that aren’t critical on the homepage social feeds, review badges.

Lazy-Load Everything Below the Fold

Make sure each lower section testimonials, footer, blog feed is wrapped in a container with lazy load active.
Set images in those sections to ‘Load when visible’ inside their properties.

Check Caching and Duplicates Sometimes the same JavaScript runs twice, or caching isn’t set up right.

Delete any duplicate scripts in Tracking and Analytics.
In your Site Settings → Performance, turn on ‘Cache for returning visitors’.

Test Again on Mobile Clear your phone browser cache.
Run your site again through PageSpeed Insights.
Focus on the ‘LCP’ number that should drop first.

With these small updates, your site will feel lighter and load much faster. If you’d like an easy way to handle ongoing optimizations image compression, code cleanup, script delay etc. You can also look into the Website Speedy App which automatically improves site loading without changing your design.

4

Now i understand what for you asked about –> LAZY-LOADING ←

Well in Wix it will be a little bit more complicated and difficult to create real –> LAZY-LOADINGS ←

Why? –> Noahlovell alreade answered you why.

Adding elements right from the start and hiding them won’t really help, instead you always should go the coding way.

If you really want to create –> LAZY-LOADINGS ← and generate a real fast WEBSITE –> you will need to work completely different (in most cases not even touching one single element provided by wix) –> Waaaaaaaaaaaahhhhhhhhtttttttttt???

Yepp!!! The more elements you use –> the slower will become your website!

Ok, just a view elements can be addded (the more elements you add –> the slower will get your website).

Instead you start to work fully –> DATA-DRIVEN ← & –> DYNAMIC ←, but this for you need CODING skills, since your whole setup will be driven mainly by –> CODE & DATA.

So what would be a real solution?

–> CUSTOM-ELEMENTS + DYNAMIC-CODE + DATA-DRIVEN-SETUP

By using custom elements you have the absolute FREEDOM to generate new ELEMENTS on the fly –> meaning now you have full control of …

a) at which time you want to generate the element (dynamically)

b) which element you want to generate

c) how you want to generate the element

d) let the element be generated –> DATA-DRIVEN

e) and everything is just some CODE-LINE –> no real (already) loaded elements needed right from the beginning of your page.

So you did choose the wrong way to achieve a real lazy loading.

And i provided you even 2 different ways –> THE CODING ONE and the cheap WORKAROUND –> you choosed the wrong one.

Additional info…

Aspect Preloaded + Hidden Dynamic / Lazy Loaded
Initial Load Time :no_entry: Slower — all elements are parsed, styled, and added to the DOM even if hidden. :white_check_mark: Faster — only what’s visible or needed immediately is loaded.
Memory Usage :no_entry: Higher — the browser keeps hidden elements in memory, including images, fonts, event listeners, etc. :white_check_mark: Lower — only active elements occupy memory.
First Paint / LCP (Largest Contentful Paint) :no_entry: Can delay visible rendering if too much HTML/CSS is loaded at once. :white_check_mark: Usually better for initial render performance.
Interactivity :white_check_mark: Faster switching between views (already in DOM, just toggle visibility). :no_entry: Slight delay when creating elements dynamically (depends on complexity).
SEO (for static content) :white_check_mark: Search engines can index preloaded hidden content (if visible in DOM). :warning: Lazy-loaded or JS-generated content may not be indexed unless handled carefully.
Network Requests :no_entry: All data/resources loaded upfront. :white_check_mark: Can defer or batch requests (e.g., load images on scroll).

So real –> LAZY-LOADING can be achieved only by DYNAMIC and DATA or EVENT DRIVEN SETUP!!!