DEV Community: Raj

Phantom CLS in Lighthouse: How to Hunt Down and Fix Invisible Layout Shifts

Raj — Mon, 06 Jul 2026 03:15:07 +0000

Phantom CLS in Lighthouse: How to Hunt Down and Fix Invisible Layout Shifts

Published on June 29, 2026 · 5 min read

By Raj Pawan Shukla

You run Google Lighthouse expecting a great performance score.

Everything looks visually stable.

Yet Lighthouse reports:

"Avoid large layout shifts."

You reload the page several times, carefully watching every element. Nothing appears to move.

So what's causing the poor Cumulative Layout Shift (CLS) score?

This is what I like to call Phantom CLS—layout shifts that happen so quickly they're almost impossible to notice with the naked eye, yet Chrome and Lighthouse still detect them.

While optimizing the Newport Fasteners ecommerce platform, I encountered exactly this problem. Here's how I tracked it down and fixed it.

What Causes Phantom CLS?

The two most common culprits are:

Lazy-loaded images above the fold – Images that should be visible immediately are unnecessarily deferred.
Client-side injected UI components – JavaScript renders elements slightly after the initial HTML has already been painted, causing nearby content to shift.

Both of these appeared during my investigation.

Case 1: The Lazy-Loaded Hero Banner

The homepage featured a large promotional banner that was being lazy-loaded.

On a fast internet connection, the image appeared almost instantly, so the layout shift was practically impossible to notice. However, Lighthouse consistently flagged it as a contributor to CLS.

The underlying issue was simple:

The browser didn't know how much space to reserve before the image loaded. When the image finally appeared, it pushed surrounding content just enough for Lighthouse to record a layout shift.

The Fix

For images that appear above the fold:

Remove loading="lazy"
Add fetchpriority="high"
Preload the image
Always specify explicit width and height

Before

<img src="hero-banner.jpg" loading="lazy" alt="Promo">

After

<link rel="preload" as="image" href="hero-banner.jpg">

<img
    src="hero-banner.jpg"
    fetchpriority="high"
    width="1200"
    height="400"
    alt="Promo"
/>

After these changes, the layout shift for the hero banner disappeared completely.

Case 2: Render-Blocking UI Scripts

The product pages still showed tiny layout shifts during the initial render.

Using Chrome DevTools, I traced them to two JavaScript files:

df_add_to_cart_hyva.min.js
nouislider.min.js

These scripts initialized the Add to Cart section and the price range slider shortly after the browser painted the initial HTML.

Although the delay lasted only a fraction of a second, the components expanded after JavaScript execution, causing nearby elements to move.

The movement was almost invisible to users—but Lighthouse still recorded it.

The Fix

The solution required two changes together.

1. Reserve Layout Space

Even before JavaScript executes, reserve enough space for the components.

.price-slider-container {
    min-height: 60px;
}

.add-to-cart-wrapper {
    min-height: 48px;
}

2. Defer Non-Critical JavaScript

Instead of blocking HTML parsing, allow the browser to continue rendering while downloading JavaScript.

Before

<script src="df_add_to_cart_hyva.min.js"></script>
<script src="nouislider.min.js"></script>

After

<script src="df_add_to_cart_hyva.min.js" defer></script>
<script src="nouislider.min.js" defer></script>

Important: Using defer alone does not eliminate CLS. In fact, it can make layout gaps more noticeable if no space has been reserved. Stable layouts require both reserved space and deferred script loading.

How to Debug Phantom CLS

Don't trust your eyes—trust the tools.

1. Chrome DevTools Performance Panel

Record a page load and inspect the Experience track.

Chrome highlights exactly:

Which DOM elements shifted
When the shift occurred
How much they contributed to CLS

This is the fastest way to locate invisible layout shifts.

2. Web Vitals Extension

Install the Web Vitals browser extension to log layout shifts in real time while interacting with your website.

It makes identifying problematic components much easier during development.

3. Test on Throttled Connections

Phantom CLS often hides behind fast hardware and local development environments.

Switch Chrome DevTools to Fast 3G or Slow 4G.

Many layout shifts that are invisible on broadband become immediately obvious under realistic network conditions.

The Takeaway

Core Web Vitals measure real user experience—not just what your page looks like after everything finishes loading.

Even movements that last only a few milliseconds can make a page feel unstable and negatively impact your Lighthouse score.

Fixing Phantom CLS requires changing how you think about rendering.

Instead of focusing only on the final appearance of a page, think about the browser's journey from the very first paint to the fully interactive state.

A few simple practices can prevent most layout shifts:

Reserve space before dynamic content loads.
Avoid lazy-loading above-the-fold images.
Prioritize hero assets using fetchpriority and preload.
Defer non-critical JavaScript.
Always verify improvements using Chrome DevTools and Lighthouse.

Performance optimization isn't always about making pages faster—it's also about making them feel stable.

Sometimes the hardest performance bugs are the ones users never consciously notice.

Have you encountered Phantom CLS?

I'd love to hear about the trickiest layout shift issues you've debugged. Share your experience in the comments, and let's learn from each other's performance wins and challenges.

How a Magento 2 Upgrade Broke Our Multi-Website Setup (And Why the Problem Wasn't Magento)

Raj — Thu, 11 Jun 2026 02:36:57 +0000

A few weeks ago, I was working on a Magento 2 upgrade for a project that hosts multiple websites under a single Magento installation.

The upgrade itself went smoothly. Deployment completed successfully, Magento commands ran without errors, and our initial testing didn't reveal any major issues.

A little later, however, we discovered that the secondary website was redirecting to the default website.

What made this issue particularly interesting was that the root cause wasn't inside Magento at all.

Project Setup

The project contained two websites:

Default Website
Secondary Website

Before the upgrade, both websites were serving different storefronts correctly.

After the upgrade, the default website continued to work as expected, but requests to the secondary domain eventually started redirecting to the default website.

Why the Issue Was Confusing

What made this issue difficult to troubleshoot was that our initial testing passed.

We didn't miss testing the secondary website. As part of our deployment verification, we tested both websites and both appeared to be working correctly.

The redirect issue only surfaced later during additional testing.

Because of this, we suspected that some form of caching might have been masking the problem during the first round of verification. It could have been browser cache, Cloudflare cache, or another layer serving cached responses.

While we never conclusively identified which cache layer was involved, the delayed appearance of the issue created the impression that the deployment had been successful and that both websites were functioning normally.

As a result, our investigation initially focused on whether something had changed after deployment rather than on the deployment itself.

Checking Magento Configuration

Since the issue involved website routing, Magento configuration became our first suspect.

We reviewed:

Websites
Store Groups
Store Views
Base URLs
Store configurations

Everything looked correct.

The secondary website still existed, the domains were configured properly, and the store hierarchy matched what we expected.

We also considered whether a configuration value had been changed accidentally after deployment, but nothing seemed out of place.

At this point, Magento wasn't giving us any useful clues.

Is the Redirect Really Coming From Magento?

Instead of continuing to search through Magento configuration, we decided to answer a simpler question:

Was the redirect actually happening inside Magento?

To test this, we created a simple HTML file inside the "pub" directory:

test.html

When we accessed the file through both domains, it loaded successfully.

This immediately told us that:

DNS was working
Domains were resolving correctly
Nginx was serving requests correctly
Requests were reaching the Magento "pub" directory

Nothing pointed to a DNS or web server routing issue.

The PHP Test

Next, we created a simple PHP file:

<?php
echo "PHP Test";

This was where things became interesting.

The behavior changed once PHP execution became involved.

Static HTML files worked, but PHP-driven requests did not.

That observation narrowed the investigation significantly. Since Magento relies on PHP, the issue appeared to be somewhere between PHP execution and Magento's website resolution process.

Looking Beyond Magento

At this point, Magento's configuration still looked correct, yet the behavior didn't make sense.

We shifted our focus to the web server configuration and started reviewing how requests were being passed to Magento.

One useful command during the investigation was:

nginx -T

This allowed us to inspect the final configuration Nginx was actually using.

While reviewing the active configuration, we noticed that the settings responsible for identifying the Magento website were missing.

One factor that delayed the investigation was that I didn't realize the project's "nginx.conf.sample" had been customized in the past.

The multi-website setup had been implemented before I worked on this area of the project, and the Nginx configuration was historically maintained by another developer. Because of that, I initially treated "nginx.conf.sample" as a standard Magento file rather than a file containing project-specific customizations.

That assumption turned out to be important.

The Real Root Cause

The breakthrough came when we compared the current configuration with what existed before the upgrade.

During the Magento upgrade, "nginx.conf.sample" had been updated.

The project previously contained custom multi-website configuration that relied on values such as:

MAGE_RUN_CODE
MAGE_RUN_TYPE

These parameters tell Magento which website should handle an incoming request.

Before the upgrade, Nginx correctly passed the website information to Magento.

After the upgrade, those custom settings were no longer present.

As a result, Magento could no longer identify the secondary website correctly and defaulted to the primary website instead, causing the unexpected redirects.

In hindsight, the behavior made perfect sense.

Magento wasn't broken.

Magento was simply receiving incomplete information from the web server.

The Fix

Once we identified the missing configuration, the solution was straightforward.

We restored the required parameters:

fastcgi_param MAGE_RUN_CODE secondary_website_code;
fastcgi_param MAGE_RUN_TYPE website;

Then we validated and reloaded Nginx:

sudo nginx -t
sudo systemctl reload nginx

The issue disappeared immediately.

The secondary website started loading correctly, and requests were no longer redirected to the default website.

Lessons Learned

Don't Assume the Upgrade Is the Root Cause

The problem appeared after the Magento upgrade, but Magento itself wasn't responsible.

The upgrade indirectly caused the issue by replacing a configuration file that contained project-specific customizations.

Isolate Components

The HTML and PHP tests were extremely valuable.

By testing outside Magento, we were able to determine where the problem started and avoid spending even more time looking in the wrong place.

Multi-Website Setups Depend on Server Configuration

In Magento multi-website environments, web server configuration is just as important as Magento configuration.

Even with a perfectly configured Magento instance, missing "MAGE_RUN_CODE" and "MAGE_RUN_TYPE" values can break website routing.

Review Customized Files During Upgrades

It's easy to focus on code and database changes during an upgrade.

However, projects often contain customized versions of files that ship with Magento. Those customizations should always be identified, documented, and reviewed during upgrade work.

Conclusion

What initially looked like a Magento website configuration issue turned out to be a web server configuration problem caused by changes to a customized "nginx.conf.sample" file during the upgrade process.

The investigation moved from Magento configuration checks to HTML testing, PHP testing, and finally Nginx configuration review before the actual cause became clear.

In the end, the fix was only a few lines of configuration, but finding those lines required understanding exactly where the request flow was breaking.

Sometimes the fastest way to solve a Magento problem is to stop looking at Magento and start looking at everything around it.