How I fixed a 30-point Lighthouse score without touching a single asset

Key takeaways

• Performance isn't always about file size; timing and load sequencing can have a bigger impact than compression or asset optimization.
• 3D assets like Spline embeds block the main thread during rendering, even when files are relatively small, causing severe interactivity delays.
• Standard auditing tools have blind spots. Lighthouse often categorizes 3D rendering issues as generic JavaScript execution problems.
• Lazy-loading with IntersectionObserver allows you to defer heavy interactive elements until users actually need them, dramatically improving initial load metrics.
• Placeholder containers prevent layout shift and maintain visual stability when delayed assets finally load into view.

We ran into a problem recently while building a client site on Webflow. Everything looked beautiful. The design was sharp, the interactions felt right, and the client was excited. But the site was painfully slow.

The numbers told a brutal story: initial load time clocked in at over 6 seconds, Time To Interactive dragged past 5 seconds, and Lighthouse gave us a dismal 30 out of 100. The real frustration? Lighthouse didn't actually tell us what was causing it. We had to dig deeper ourselves.

After extensive investigation, we finally found the culprit. The site was loading Spline assets immediately on page load, long before users needed them, and they were blocking the main thread.

Lazy-loading those assets changed everything:

• Initial Load Time: 6.5s → 1.2s
• Time to Interactive: 5.3s → 0.8s
• Largest Contentful Paint: 5.7s → 0.6s
• Lighthouse Score: 30 → 90

All without changing the design or resorting to compression hacks.

Context: The Build was visually-heavy

The project was built using multiple 3D spline embeds to create an immersive experience. Spline is great for this because it renders scalable 3D vector scenes. It's also lighter than video or traditional 3D assets and allows live interaction. But it comes at the cost of having the file load immediately unless you do something about it.

That means:

• The Spline script executes before the page is interactive
• The model downloads before the user scrolls to it
• The browser treats it like a high-priority resource
• Main thread execution stalls

The problem: Lighthouse didn't flag the bottleneck

Lighthouse gave us red flags about "render-blocking resources" and "heavy JavaScript execution", but no mention of Spline directly.

It was difficult to spot because the asset didn't show as an image or a large file. It came up as JavaScript execution time buried under other events.

• Spline script was loaded in
• Execution started before anything else rendered
• The main thread was blocked for hundreds of milliseconds
• All meaningful content waited behind it

The page wasn't slow because the assets were too large. It was slow because they loaded too early.

The fix: lazy-loading the spline elements

We already lazy-load images, so we applied the same logic to Spline. Basically, don't load it until the user is close to seeing it.

Spline Lazy Loading Pattern

‍

function lazyLoadSpline(container) {

  const observer = new IntersectionObserver(entries => {

    entries.forEach(entry => {

      if (entry.isIntersecting) {

        entry.target.loadSplineAsset();

        observer.unobserve(entry.target);

      }

    });

  });

‍

  observer.observe(container);

}

‍

Placeholder strategy

We used a reserved container height to stop the layout from shifting. All these stopped the layout from jumping when the embed initialized.

We used a reserved container height to stop the layout from shifting. All these stopped the layout from jumping when the embed initialized.

Why spline flies under the radar in audits

Spline assets don't behave like images, video, or fonts, which means they don't show up under "Large Media" or "Unused JS". They also don't trigger obvious Lighthouse warnings. Instead, they work like a hybrid of script execution, asset streaming, and GPU rendering.

This means you can only catch the issue by looking at:

• DevTools
• Main thread
• CPU/JS execution timeline

In the end, we didn't have to modify the Spline assets themselves or reduce resolution. We solved what seemed like a serious problem just by delaying when the Spline assets loaded.

Lessons learned

Performance issues are often timing-based, not just about file size. Lighthouse is a helpful tool, but it's not a full diagnostic solution. Always investigate manually. Lightweight assets can still block the main thread because rendering work matters just as much as file weight. Heavy visuals should never load before above-the-fold content. And lazy loading isn't just a UX feature; it's a performance technique that frees up CPU and bandwidth.

Practical checklist for future builds

Based on the lessons learnt from the problem, we've created a checklist for future builds.

• Audit runtime-based assets, not just file sizes.
• Treat 3D embeds like video: load only when needed.
• Use IntersectionObserver for scroll-based activation.
• Test on mid-range real devices, not just desktop throttling.
• Use placeholders to prevent layout shift.
• Don't assume Lighthouse tells the whole story.

Final thoughts

Having smaller files isn't the only thing to aim for if you want a faster website. You also have to make sure the right things load at the right time. Spline is a reliable, powerful tool for interactive web experiences, but you need to integrate it thoughtfully, especially in platforms like Webflow.

All this site needed to become faster was moving from "load immediately" to "load when needed." We didn't have to sacrifice visuals or compromise the design vision. If Lighthouse isn't showing you the real performance issue, it doesn't mean there isn't one. Sometimes the answer is hiding in plain sight, waiting for you to look at the problem from a different angle.