DEV Community: GIRIDHAR DEV

Modern CSS & Rendering Performance in Shopify

GIRIDHAR DEV — Sun, 29 Mar 2026 14:25:08 +0000

What Actually Improves Rendering (and What Doesn’t)

This article is part of my Shopify Performance Engineering Series.

In previous articles, I covered:

In this post, I’ll focus on something deeper:

👉 Rendering performance — what the browser actually does after loading resources

Why Rendering Performance Matters?

Even if:

images are optimized
JavaScript is deferred

your site can still feel slow because of:

layout calculations
style recalculations
paint work

Browsers don’t just “load” pages — they:

parse HTML
build DOM
calculate styles
calculate layout
paint pixels

👉 Performance issues often come from steps 3–5, not just network.

Ever wondered if we could improve page performance using CSS?

The Biggest Misconception

Most developers think:

“If content is below the fold, it doesn’t affect performance”

❌ This is wrong.

By default, browsers still:

calculate layout
compute styles
sometimes paint

So, for off-screen content use:

content-visibility — What It Actually Does?

.section {
  content-visibility: auto;
}

This tells the browser:

“Skip rendering work for this subtree until it is needed”

Specifically, the browser can skip:

layout
style calculation
painting

Real Impact (Accurate)

When used correctly:

reduces initial rendering work
improves interaction readiness
improves metrics like INP and sometimes LCP

In some cases, rendering work can drop significantly (even multiple times faster)

When content-visibility Works Well

Use it when:

content is below-the-fold
sections are independent (no layout dependency)
large DOM trees exist

Avoid when:

content affects layout above
you rely heavily on DOM measurements (important!)
The Hidden Problem: Layout Shift (CLS)

When you apply:

content-visibility: auto;

The browser may treat the element as:

👉 having no intrinsic size initially

This can cause layout jumps.

Correct Fix: contain-intrinsic-size

.section {
  content-visibility: auto;
  contain-intrinsic-size: auto 500px;
}

This:

provides a placeholder size
prevents layout shifts
stabilizes rendering

👉 Without this, CLS issues are very likely

Important Correction: content-visibility is NOT free

If you use APIs like:

getBoundingClientRect()
offsetWidth
scrollHeight

on those elements:

👉 browser is forced to render them anyway

So you lose the benefit.

This is explicitly warned in browser docs.

Forced Reflow — What Actually Happens

Forced reflow happens when JS asks:

“Give me layout info NOW”

Examples:

element.offsetWidth
element.offsetHeight
element.getBoundingClientRect()

👉 All of these can trigger layout calculation

So what should you do?

❌ Don’t avoid APIs blindly
✅ Avoid calling them frequently

Better Strategy (Real Answer)

Instead of:

for (let i = 0; i < 100; i++) {
  element.offsetWidth;
}

Do:

batch DOM reads
batch DOM writes
avoid interleaving them

ResizeObserver — Is it better?

✅ Yes, but with context.

ResizeObserver:

reacts to size changes asynchronously
avoids manual polling
reduces forced synchronous layout reads

BUT:

⚠️ It still depends on layout updates happening
⚠️ Overusing observers can also hurt performance

IntersectionObserver — When it helps?

const observer = new IntersectionObserver(...)

This is genuinely useful for:

lazy loading
triggering work only when visible

👉 Works very well with content-visibility

CSS Optimization — What Actually Matters?

1) Deep selectors (real impact)

Bad:

.container .wrapper .item .text span {}

Why bad:

increases selector matching cost
harder for browser to resolve

2) DOM depth (real impact)

Deep DOM:

<div><div><div><span>Text</span></div></div></div>

This increases:

layout complexity
style recalculation cost

3) CSS modularization (real benefit)

Separating:

layout styles
animation styles

helps:

reduce layout recalculation
improve maintainability

What Actually Improves Rendering Performance?

Based on real browser behavior:

✅ High impact:

reducing DOM size
using content-visibility correctly
avoiding unnecessary layout calculations
deferring off-screen rendering

⚠️ Medium impact:

CSS selector optimization
modular CSS

❌ Low / misunderstood impact:

blindly replacing offsetWidth
assuming one API is “faster” than another

Key Insight

Rendering performance is not about:

❌ using specific APIs
❌ micro-optimizing CSS

It is about:

reducing how much work the browser needs to do

Final Thought

The biggest performance gains come from skipping work — not optimizing it.

Question for Developers

Have you used content-visibility in production?
Did you face issues with layout shifts or unexpected rendering?

What’s Next?

In the next article, I’ll share:

👉 Performance-first Shopify development rules I follow while building themes

How Third-Party Apps Slow Down Shopify Stores

GIRIDHAR DEV — Sun, 29 Mar 2026 13:51:18 +0000

How Third-Party Apps Slow Down Shopify Stores

Reducing 1000ms of Total Blocking Time (TBT)

This article is part of my Shopify Performance Engineering Series.

In my previous articles:

I covered the overall optimization journey and LCP improvements.

In this post, we’ll focus on another critical metric:

👉 Total Blocking Time (TBT)

What is Total Blocking Time (TBT)

Total Blocking Time measures how long the browser’s main thread is blocked by JavaScript.

When the main thread is blocked:

user interactions are delayed
scrolling becomes janky
clicks feel unresponsive

Even if the page looks loaded, it doesn’t feel fast.

Identifying the Problem:

While analyzing performance using Lighthouse and DevTools, I noticed:

high Total Blocking Time
long JavaScript execution tasks
delayed interactivity

At first, I suspected Google Tag Manager (GTM).

But after deeper investigation, I found the real bottleneck.

The Real Bottleneck: Third-Party Apps

One Shopify app was responsible for:

loading a 4MB font file
injecting heavy JavaScript
triggering multiple network requests

As a result:

homepage size reached ~11MB
TBT increased by ~1000ms

Why Third-Party Apps Are Problematic?

Most Shopify apps:

inject scripts globally
run on every page
execute during initial load

This creates:

main thread blocking
delayed rendering
unnecessary work for the browser

Investigation Using DevTools

Using the Performance tab in Chrome DevTools, I observed:

long tasks (>50ms)
script execution blocking rendering
heavy main-thread activity

👉 The app scripts were clearly dominating execution time.

First Attempt: Let It Load Normally

Initially, the app was loading during page initialization.

This caused:

blocking during critical rendering phase
increased TBT
slower interactivity

Solution: Interaction-Based Loading

Instead of loading the app immediately, I changed the strategy.

👉 Load the app only when the user clicks the help icon

document.querySelector('.help-icon').addEventListener('click', () => {
  loadSupportIframe();
});

This ensures:

no app scripts during initial load
no unnecessary blocking
better main-thread availability

Why This Works?

Instead of:

Load everything → then render page
We do:
Render page → load features when needed

This reduces:

Total Blocking Time
network congestion
CPU workload
Result After Optimization

After applying interaction-based loading:

TBT reduced significantly
performance score improved
page became more responsive
Additional Improvements for TBT

Beyond third-party apps, I implemented several optimizations.

1. Deferring Non-Critical JavaScript

Scripts that were not required immediately were deferred.

<script defer src="script.js"></script>

This prevents blocking during HTML parsing.

2. Moving Scripts After Page Load

Some scripts were moved to run after:

window.addEventListener('load', () => {
  loadNonCriticalScripts();
});

This ensures:

critical rendering is not blocked
scripts run only after page is usable

3. Splitting Large JavaScript Files

Instead of loading one large file I:

broke scripts into smaller modules
loaded only what was needed

This reduced:

execution time
blocking duration

4. Removing Unused App Code

When apps were removed, I ensured:

leftover JS was deleted
unused CSS was removed
Liquid code was cleaned

This reduced unnecessary execution.

5. Avoiding Heavy Inline Scripts

Large inline scripts were:

moved out of <head>
placed near the end of <body>

This reduced blocking during initial render.

Important Insight

TBT optimization is not about writing faster code.
It is about:
reducing the amount of JavaScript that runs during page load, especially large bundles that create long tasks (>50ms) and block the main thread.

Common Mistakes in Shopify TBT Optimization:

Loading all apps on every page
Many apps are not needed globally.
Running scripts too early
Non-critical scripts should not run during initial render.
Keeping unused app code
Uninstalled apps often leave scripts behind.
Large JavaScript bundles
Big files increase execution time and blocking.

Real-World Impact

After reducing TBT:

page felt more responsive
interactions became smoother
perceived performance improved

Even without changing visual load speed, the site felt significantly faster.

Key Takeaways

If you're optimizing TBT in Shopify:

reduce third-party scripts
load apps only when needed
defer non-critical JavaScript
split large JS files
remove unused code

Most improvements come from:
removing unnecessary work rather than optimizing existing code

Final Thought

Performance is not just about how fast a page loads.
It’s about how quickly a user can interact with it.

Question for Developers

Have you faced performance issues due to third-party scripts?
What strategies have worked best for you in reducing TBT?

What’s Next

In the next article, I’ll explore:

👉 Modern CSS techniques like content-visibility and how they improve rendering performance

Optimizing Largest Contentful Paint (LCP) in Shopify

GIRIDHAR DEV — Sun, 29 Mar 2026 13:17:06 +0000

From Eager Loading to Image Preloading (Real Experiments):

This article is part of my Shopify Performance Engineering Series.

In my previous article - How I Improved a Shopify Store’s Performance from 30% to 62% - I explained the overall optimization journey.

One of the biggest contributors to that improvement was LCP.

In this post, we’ll go deeper into one of the most critical metrics: Largest Contentful Paint (LCP).

In this post, I’ll go deeper into how I optimized LCP through multiple experiments including what worked, what didn’t, and what actually made a measurable difference.

What is LCP (and why it matters)

Largest Contentful Paint (LCP) measures how long it takes for the main visible element on a page to load.

In most Shopify stores, this is usually:

hero banner image
featured product image
large above-the-fold section

If LCP is slow, users perceive the site as slow even if everything else loads fast.

Identifying the LCP Element:

Using Lighthouse and Chrome DevTools, I identified that:

👉 The LCP element on the homepage was the hero banner image

The issue was not the image size alone.

The real problem was:

The browser was discovering the image too late

Experiment 1: Default Behavior (Baseline)

Initially, the image was loaded normally with:
lazy loading in some cases
no priority hints

Result:
LCP was delayed
performance score ~30%

Experiment 2: Forcing Eager Loading

First improvement:

<img loading="eager">

Why this helps?
prevents lazy loading
ensures browser loads image immediately

Result:
slight LCP improvement
but still not optimal

👉 Problem: browser still needs to discover the image in DOM first

Experiment 3: Increasing Fetch Priority

Next, I used:

<img fetchpriority="high">

What this does?
signals browser: “this is important”
increases network priority

Result:
better LCP than eager loading alone
but still limited improvement

👉 Problem: request still starts after DOM parsing

Experiment 4: Image Preloading

To push further, I experimented with:

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

Why preload is powerful?
request starts in <head>
browser doesn’t wait for DOM
image loads earlier than render

Result:
significant improvement
performance increased to ~42–45%

In Shopify, images are often rendered like:

<img srcset="...">

This means:
browser chooses image size dynamically
exact URL is not fixed at build time

👉 Problem:

Preloading requires a specific image URL

Solution: Static Image Exposure

To solve this, I:
created a theme setting for hero image
exposed the image URL in <head>
used that for preloading

This allowed:
early fetch
correct resource prioritization

Experiment 5: Wrong Preload Size (Important Lesson)

Initially, I preloaded a large image (desktop size) for all devices.

This caused:
unnecessary data usage on mobile
slower load on weaker networks

👉 Lesson:

Preloading the wrong image can hurt performance

Final Optimization: Conditional Preloading

I implemented:
1280px image for desktop
375px image for mobile

This ensured:
correct image is loaded early
no unnecessary preload

Role of srcset and sizes:

To further optimize:
used proper srcset
defined accurate sizes

Example concept:

<img 
  srcset="image-375.jpg 375w, image-768.jpg 768w, image-1280.jpg 1280w"
  sizes="(max-width: 768px) 100vw, 1280px"
>

This allows:
browser to choose optimal image
reduced network load
Important Insight

LCP optimization is not just about:

❌ making images smaller
❌ using lazy loading

It is about:

Making the browser discover and prioritize the image earlier

Common Mistakes in Shopify LCP Optimization:

Lazy loading LCP image
Never lazy load above-the-fold images.
Missing fetch priority
Without priority hints, browser delays important resources.
No preloading
Browser discovers image too late.
Incorrect image sizes
Loading large images on mobile increases load time.

Final Results

After combining:
eager loading
fetchpriority
image preloading
correct sizing

LCP improved significantly and contributed heavily to:
30% → 62% performance improvement

Key Takeaways

If you're optimizing LCP in Shopify:

• identify the correct LCP element
• avoid lazy loading above-the-fold images
• use fetchpriority="high"
• preload critical images
• ensure correct image sizes
• use proper srcset and sizes

Final Thought:

LCP optimization is not about tricks.

It’s about understanding:

when the browser discovers the most important content
The earlier it discovers it, the faster your page feels.

Question for Developers

What has been your biggest challenge in optimizing LCP?
Have you tried preloading images in Shopify themes?

How I Improved a Shopify Store’s Performance from 30% to 65% - GTmetrix

GIRIDHAR DEV — Tue, 10 Mar 2026 17:26:26 +0000

A Real Shopify Performance Optimization Journey

When we upgraded our Shopify store to a new theme, I expected the performance to improve automatically.

Instead, the first performance test showed something alarming.

The store scored only 30% on GTmetrix — exactly the same as the old theme.

Despite migrating to a new theme, the website was still slow.

That moment started a deep investigation into Shopify performance optimization, Core Web Vitals, third-party scripts, and browser rendering behavior.

What You'll Learn

In this article I’ll cover:

-> Investigating slow Shopify performance
-> Optimizing Largest Contentful Paint (LCP)
-> Reducing Total Blocking Time (TBT)
-> Handling third-party scripts efficiently
-> Fixing layout shifts (CLS)

Over several weeks of experimentation, debugging, and testing, the store’s performance improved from 30% to 62%.

This article documents that journey.

Understanding the Performance Problem

Modern website performance is heavily influenced by Core Web Vitals.

Page Load:

-> LCP (Largest Contentful Paint) - When the main visible content appears
-> TBT (Total Blocking Time) - How long the main thread is blocked by JavaScript
-> CLS (Cumulative Layout Shift) - Unexpected layout movement during loading

Improving Core Web Vitals in Shopify themes requires optimizing several aspects of a page:

-> images
-> scripts
-> rendering behavior
-> third-party integrations

The Initial Situation:

I was working on upgrading a Shopify store to a new Booster theme version.
Migrating the theme and recreating all configurations from the live website took nearly a month.
Once everything was configured — including several third-party apps — I assumed the new theme would perform better.

However, the first GTmetrix test told a different story.

Metric Result
Performance Score ~30%
GTmetrix Grade E–F

This meant the theme upgrade alone had no meaningful performance impact.

So the real question became:

What exactly was slowing the store down?

Phase 1: Investigating Largest Contentful Paint (LCP)

The first major issue was Largest Contentful Paint.
On the homepage, the LCP element was the hero banner image.
The browser was discovering and loading this image too late during rendering.

Experiment 1: Loading the image eagerly

The first attempt was forcing the hero image to load eagerly.

loading="eager"

This ensured the browser prioritized loading the hero image earlier.
The improvement was small but noticeable.

Experiment 2: Increasing fetch priority

Next, I experimented with:

fetchpriority="high"

This tells the browser that the image is a high-priority resource.
The LCP improved slightly, but it was still slower than expected.

Experiment 3: Image preloading

To push optimization further, I experimented with preloading the hero image.

However, Shopify dynamically generates image URLs using srcset, which makes preloading tricky.
To work around this, I created a theme setting exposing the hero image URL, allowing it to be preloaded in the head tag. We cannot access section specific data (here - image banner section) in the head tag. So we need to create a global theme setting for this.
This improved the performance score from 30% to around 42–45%.
But performance optimization rarely stops with a single improvement.

Phase 2: Investigating Total Blocking Time (TBT)

Next, I analyzed Total Blocking Time, which measures how long JavaScript blocks the browser’s main thread.
Initially I suspected Google Tag Manager, since it loads multiple scripts.
But deeper analysis revealed a bigger problem.

Phase 3: Discovering the Real Bottleneck

One third-party application was responsible for most of the slowdown.
The app loaded:

a 4MB font file
several large scripts
heavy network requests

As a result, the homepage size had reached 11MB.
Even worse, the scripts from this app caused nearly 1000ms of Total Blocking Time.

The Solution: Interaction-Based Loading

Instead of loading the app during page initialization, I changed the logic so the app loads only when the user clicks the help icon.

This ensured:

the heavy iframe is not loaded during page load
unnecessary network requests are avoided
javaScript execution does not block the main thread

This small architectural change significantly improved performance.

Phase 4: Image Optimization

While analyzing the network waterfall, I discovered another issue.
Many images were loaded at 768px width, even on smaller mobile screens.
By resizing images appropriately (for example 375px for mobile devices), I reduced the homepage image payload by 30–40%.

This had two major benefits:

• smaller page size and faster downloads
• reduced JavaScript and rendering work, which also helped improve Total Blocking Time (TBT)

Optimizing images not only improved LCP but also reduced the amount of work the browser had to perform during page load.

Phase 5: Optimizing Collection and Product Pages

I realized that optimizing only the homepage was not enough.
Collection pages and product pages also needed improvements.
On collection pages, the LCP element was usually one of the first product images.

I optimized them by:

-> preloading important images
-> optimizing image sizes
-> improving product card rendering

The difference compared to the live theme was significant.

Page Live Theme Optimized Theme
Collection Page ~15% ~70%

For product pages, I applied a similar strategy by preloading the first product images.

Phase 6: Avoiding Unnecessary Resource Loading

Another issue I discovered was that some resources were loading on every page even when they were not needed.
Using Shopify’s template.name, I implemented page-specific loading.
This ensured resources load only on relevant pages, reducing unnecessary network requests.

Phase 7: Fixing Layout Shifts (CLS)

Another Core Web Vital that required improvement was Cumulative Layout Shift.
Layout shifts were caused by:

-> late-loading fonts
-> header dimension changes
-> dynamic UI elements

To fix this, I defined explicit layout dimensions so the browser reserves space before elements load.
This stabilized the page layout.

Phase 8: Rendering Optimization with Modern CSS

To reduce rendering work for the browser, I used modern CSS techniques:

content-visibility
contain-intrinsic-size

These allow the browser to skip rendering off-screen content until it becomes visible.
This significantly reduced rendering cost for below-the-fold sections.

My Debugging Workflow:

During the investigation I relied on several tools.

Lighthouse – local testing and layout debugging
GTmetrix – network waterfall analysis
WebPageTest – rendering insights
Chrome DevTools – CPU throttling and performance profiling

Testing under mobile CPU throttling and slow network conditions helped reveal issues that were not visible on powerful desktops.

A Small Shopify Performance Testing Trick:

While testing preview themes, I noticed performance results were slightly worse.
This happens because the Shopify preview bar injects additional scripts.
However, the preview bar can be disabled using the pb=0 query parameter.

Example preview URL:

https://example-store.myshopify.com/?preview_theme_id=123456789&pb=0

Without pb=0, Shopify injects the preview toolbar which can affect performance measurements.
Adding this parameter allows more accurate testing of preview themes.

Final Results

After several rounds of optimization, the results improved significantly.

Before:
Performance Score ~30%
GTmetrix Grade ~ E/F
After:
Performance Score ~62%
GTmetrix Grade ~ C

The improvement came from many small optimizations combined together.

Why Performance Matters

Website speed directly affects user behavior.
Research shows that a 1-second delay in page load time can reduce conversions by around 7%.

For e-commerce stores, performance directly impacts revenue.

Key Takeaways

If you're optimizing a Shopify store, these steps usually provide the biggest improvements:

• optimize LCP images
• reduce third-party scripts
• lazy load non-critical resources
• optimize image sizes
• stabilize layouts to prevent CLS

Most performance gains come from removing unnecessary work rather than adding more code.

Final Thoughts

This project taught me that performance optimization is not about chasing benchmark scores.

It’s about understanding how browsers load and render pages, and eliminating everything that slows that process down.

Performance optimization is not about making websites faster.
It’s about removing everything that makes them slow.

Question for Developers

Have you faced similar performance challenges when working with Shopify or other frontend frameworks?

What optimization had the biggest impact in your projects?

This article is part of my Shopify Performance Engineering Series.

In the next article, I’ll dive deeper into optimizing Largest Contentful Paint in Shopify through multiple experiments with eager loading, fetchpriority, and image preloading.