The Core Problem: How Fast Should Your Storefront Render?

Every e-commerce page you load goes through three stages: fetch data, render HTML, send to browser. The question isn't if these stages happen—they always do. The question is where and when they happen.

Most Shopify merchants use the Liquid templating engine. Liquid runs on Shopify's servers. Every time someone loads a product page, Shopify fetches data from your database, renders the HTML server-side, and ships the full page to the browser. This is Client-Side Rendering (traditional approach). It works, but it's not optimized for speed or scale.

The modern approach: decouple your storefront from Shopify's servers entirely. Use Shopify Hydrogen or a custom React/Next.js frontend. Now you control when rendering happens. You can pre-generate pages (SSG), generate them on-demand (SSR), or regenerate stale content incrementally (ISR). Each strategy has wildly different performance, cost, and complexity profiles.

Here's the insight most agencies miss: the fastest storefront isn't the most expensive one. It's the one that matches your content velocity and traffic patterns. A store with 500 static products optimizes differently than one with 50K inventory items updated hourly.

Rendering Method #1: Server-Side Rendering (SSR)

What it is: Every request triggers a server to fetch data, render HTML, and return a fresh page.

How it works: 1. Browser requests /products/blue-sneaker 2. Server fetches product data from Shopify (database query + API call: ~100-300ms) 3. Server renders HTML using React components (another ~50-100ms) 4. Server sends full HTML to browser 5. Browser displays page (total: ~300-400ms)

Performance profile: - Time to First Byte (TTFB): 300-500ms (slow) - Time to Interactive: 800-1200ms (slower) - Fully Loaded: 2-4 seconds (medium, depending on image optimization)

Costs: - Server infrastructure: $100-$500/month for basic server, $500-$2K/month for scale - Database: $50-$200/month (API quota + edge caching) - Bandwidth: 1-5 cents per GB of outbound data (scales with traffic) - CDN: Optional, reduces latency but adds cost

When to use SSR: - High product velocity. Your inventory changes hourly or faster. Pre-generating pages is impossible. - Highly personalized content. Every user sees different prices (A/B tests), recommendations, or inventory status. - Real-time inventory accuracy is critical. Customers must see live stock levels on every page load. - Low traffic volume (under 100K page views/month). Server costs are manageable.

Real-world example: Fashion brand with 20K SKUs. New items added daily. Seasonal inventory rotates constantly. SSR is the right choice because pre-generating 20K pages daily is wasteful—you'd regenerate stale inventory status every time. SSR lets you fetch fresh data on every request.

Downsides: - Slow TTFB hurts SEO and user experience. Google Search prefers fast sites. - Server costs scale with traffic. Each request hits your server, adding latency and load. - Cold starts (new servers spinning up) add 1-2 seconds on spiky traffic.

Rendering Method #2: Static Site Generation (SSG)

What it is: Pre-render all pages at build time. Every URL becomes a pre-built HTML file. No server computation needed.

How it works: 1. During build (manual trigger or CI/CD pipeline): fetch all product data from Shopify API 2. Generate HTML for every SKU (e.g., 500 SKUs = 500 HTML files) 3. Upload static HTML files to a CDN 4. Browser requests /products/blue-sneaker 5. CDN serves the pre-built HTML file instantly (~50-100ms globally)

Performance profile: - Time to First Byte (TTFB): 50-150ms (very fast) - Time to Interactive: 400-800ms (fast) - Fully Loaded: 1.5-2.5 seconds (fastest) - Cache hit rate: 99%+ (if using a good CDN)

Costs: - Build infrastructure: $0-$100/month (GitHub Actions, Netlify, Vercel free tier) - CDN: $0.08-$0.20 per GB (Vercel, Netlify, CloudFlare typically handle this) - Shopify API quota: $50-$200/month for bulk fetches during build - Bandwidth: Negligible (files served from CDN cache, not origin server)

When to use SSG: - Static product catalog. Your inventory changes weekly or monthly, not hourly. - High traffic volume (1M+ page views/month). Pre-generation saves servers from processing each request. - SEO is critical. Fast TTFB and cacheable pages boost search rankings. - Low personalization. Most customers see the same product page. - You can rebuild pages on a predictable schedule (nightly builds, weekly rebuilds).

Real-world example: Coffee subscription brand with 50 core products. Inventory updates daily in batches. Run a nightly build at 2am UTC, regenerate all 50 product pages, deploy to CDN. By 3am, all pages are fresh and live. User requests hit the CDN instantly. No server computation. Cost: $0 infrastructure (Vercel free tier) + $50 Shopify API quota.

Downsides: - Inventory is stale between builds. If you regenerate once per night, inventory displayed is 12-24 hours old. Bad if you're a live-supply store (farmers market, limited drops). - Build time scales with product count. 10K SKUs = 10-30 minutes of build time. Not scalable. - Rebuild the entire catalog for one product update. Inefficient.

Rendering Method #3: Incremental Static Regeneration (ISR)

What it is: Hybrid approach. Pre-generate pages at build time (like SSG), but allow individual pages to regenerate on-demand when requested (like SSR), without rebuilding the entire site.

How it works: 1. During build: generate 500 popular product pages, deploy to CDN 2. Browser requests /products/blue-sneaker (popular, pre-generated) - CDN serves instantly (~50-100ms) 3. Browser requests /products/obscure-variant-xyz (rare, not pre-generated) - Server renders on-demand (~300-400ms, like SSR) - Page is cached for the next 60 seconds 4. Inventory updates in Shopify? Stale pages can be purged immediately via webhook, forcing regeneration on the next request

Performance profile: - Time to First Byte: 50-150ms (popular pages), 300-400ms (rare pages) - Average TTFB: 100-200ms (blended) - Time to Interactive: 500-900ms - Fully Loaded: 1.5-3 seconds (blended)

Costs: - Build infrastructure: $0-$100/month (GitHub Actions, CI/CD) - Server (for on-demand renders): $50-$200/month (lightweight, handles spikes) - CDN: $0.08-$0.20 per GB - Shopify API quota: $100-$300/month (initial build + on-demand rendering)

When to use ISR: - Large product catalogs (5K-100K+ SKUs) with unequal traffic distribution. - Core products change regularly. Rare products rarely change. - You want sub-second performance on popular pages but can accept 300-400ms latency on rare pages. - Real-time inventory matters for high-velocity items only. - You're willing to manage cache invalidation via webhooks.

Real-world example: Marketplace with 50K vendor products. 80% of traffic goes to 200 bestselling items. ISR: pre-generate the top 200 at build time (served from CDN, super fast). Other 49.8K products render on-demand (slower but rare). Webhook from Shopify invalidates cache when inventory changes. Best of both worlds: fast for most users, fresh data for inventory, no massive daily rebuild.

Downsides: - Complexity. You need to manage cache invalidation, webhooks, and revalidation logic. - Cold-start latency on un-cached pages (first request is slow). - ISR behavior varies by platform. Vercel's ISR differs from Netlify's On-Demand Builders. You need to understand your host's implementation.

Performance Comparison Table

Metric SSR SSG ISR
TTFB 300-500ms 50-150ms 50-150ms (hot), 300-400ms (cold)
Time to Interactive 800-1200ms 400-800ms 500-900ms
Fully Loaded 2-4s 1.5-2.5s 1.5-3s
Server Cost $100-2K/mo ~$0 $50-200/mo
Build Time None 5-30min (10K SKUs) 2-10min (popular only)
Inventory Freshness Real-time 1-24hrs old Configurable (mins-hours)
Suitable Catalog Size Any <5K products 5K-500K products
Scalability Poor (request limit) Excellent (CDN scale) Excellent (CDN + on-demand)
Personalization Excellent Poor Medium

Cost Reality Check

Let's model three scenarios.

Scenario 1: 500-product D2C brand (low traffic, ~50K page views/month)

SSR: $1.2K/month total - Server: $100/month - Database/API: $50/month - Bandwidth + CDN: $1050/month (50K page views × ~5KB per page view = 250GB outbound)

SSG: $110/month total - Build infrastructure: $0 (Vercel/Netlify free) - CDN: $0 (included free tier) - Shopify API: $60/month (nightly rebuilds) - Total: ~$110/month

Winner: SSG ($1090/month cheaper)

Scenario 2: 20K-product marketplace (high velocity, 1M page views/month)

SSR: $2.5K/month total - Server: $500/month (handle 30K requests/day) - Database/API: $150/month - Bandwidth: $1.8K/month (1M page views × 5KB = 5TB outbound)

SSG: Infeasible - Build time: 60-120 minutes daily - Build infrastructure: $200/month (dedicated build server) - Shopify API quota: $300/month (massive bulk fetches) - Result: Still lags in freshness

ISR: $850/month total - Server: $100/month (light on-demand server for cold-start renders) - Build infrastructure: $50/month (pre-generate top 1K products) - CDN: Included (Vercel or Netlify) - Shopify API: $200/month (initial build + webhook invalidation) - Bandwidth: $400/month (most traffic cached, CDN origin pulls)

Winner: ISR ($1650/month cheaper than SSR, feasible unlike SSG)

Scenario 3: 100K-product catalog (extreme scale, 10M page views/month)

SSR: $18K/month total - Server farm: $5K/month (distributed load balancers) - Database: $3K/month (managed PostgreSQL with read replicas) - API/bandwidth: $10K/month (10M page views × 5KB)

ISR: $3.2K/month total - Server: $300/month (lightweight on-demand renders) - Build infra: $150/month - CDN: $800/month (Fastly or higher-tier CloudFlare for 100K product variants) - Shopify API: $400/month (webhook management + bulk revalidation) - Bandwidth: $1.5K/month (most traffic cached, CDN hits)

Winner: ISR ($14.8K/month cheaper than SSR)

The pattern: As catalog size and traffic grow, ISR's hybrid approach scales better than SSR's per-request model.

Implementation: How to Choose

Decision tree:

  1. Is your product catalog static (changes weekly or less)? → Use SSG
  2. Cost: Lowest
  3. Performance: Fastest

  4. Catalog size: <5K products

  5. Do you have 5K-100K products with uneven traffic? → Use ISR

  6. Cost: Medium
  7. Performance: Fast for core products, acceptable for long tail

  8. Complexity: Higher (webhook management required)

  9. Do you need real-time inventory or hyper-personalization? → Use SSR

  10. Cost: Highest
  11. Performance: Slowest

  12. Catalog size: Any

  13. Are you starting from scratch (no Shopify Plus)? → Default to SSG

  14. Lowest cost and complexity
  15. Upgrade to ISR once catalog exceeds 5K SKUs

Tools & Frameworks for Shopify Rendering

For Headless Hydrogen/React: - Remix + Hydrogen (Shopify's native headless framework): Built-in ISR support, Shopify-optimized - Next.js (Vercel): Native ISR support, industry standard, largest ecosystem - Gatsby (GraphQL-first): SSG-focused, slow builds on large catalogs, declining adoption - Astro (new hotness): Static-first, fast builds, growing ecosystem

CDN & Deployment: - Vercel (built by Next.js creators): Excellent ISR, $20/month pro tier - Netlify: Good SSG/ISR support, $19/month pro tier - Cloudflare Pages (cheapest): $20/month for advanced features, but ISR is newer and less documented - AWS CloudFront + Lambda@Edge: Highest control, but requires DevOps knowledge ($50-500/month)

Link to internal resources: Hydrogen is Shopify's native headless framework. Read our Hydrogen 101 guide for setup and best practices.

Common Pitfalls

Pitfall 1: Choosing SSG for a large catalog You have 30K products. You decide to SSG them all. Build time is 2 hours. You add one product. Now the next build is 2+ hours. You end up delaying releases. Solution: Use ISR. Pre-generate the top 2K, render the rest on-demand.

Pitfall 2: ISR without cache invalidation You enable ISR revalidation every 60 seconds. Customer buys the last unit. The stale cache serves inventory as "in stock" for another 50 seconds. Angry customer. Solution: Implement webhook-based cache invalidation. The moment inventory changes in Shopify, purge the CDN cache immediately.

Pitfall 3: Forgetting image optimization You nail the rendering strategy but ignore images. Your product page renders in 300ms, but 5 product images (5MB total) load over 4 seconds. Solution: Use Next.js Image component or similar. Serve WebP format, lazy-load below-the-fold images, use CDN-optimized storage (AWS S3, Cloudinary).

Pitfall 4: Not measuring actual performance You deploy ISR and assume it's fast. You don't monitor Core Web Vitals. Users in slow networks see 3-second page loads. Solution: Monitor Core Web Vitals in production. Use Google PageSpeed Insights, Vercel Analytics, or Sentry for real-world performance data.

FAQ

Q: What about JAMstack? Is that SSG? A: Mostly yes. JAMstack (JavaScript, APIs, Markup) emphasizes pre-built markup (SSG) served via CDN. Modern JAMstack includes ISR and SSR, so it's evolved beyond pure SSG.

Q: Can I use SSG if inventory changes hourly? A: Only if you rebuild hourly. That's feasible for <1K products but becomes expensive at scale. For hourly changes, use SSR or ISR with webhook invalidation.

Q: Does Shopify Plus affect rendering strategy? A: Yes. Shopify Plus merchants can use custom apps and webhooks, enabling sophisticated cache invalidation for ISR. Standard Shopify has limited webhook flexibility, making SSG simpler.

Q: What about Shopify's native Liquid theme? Can I use these strategies? A: Shopify Liquid is always SSR by default. To use SSG or ISR, you must decouple from Liquid and build a custom headless storefront using Hydrogen, Next.js, or similar.

Q: How much does rendering strategy affect SEO? A: Significantly. Google prefers fast sites. SSG and ISR have better TTFB (50-150ms) than SSR (300-500ms), boosting SEO ranking. SSR can rank well with optimizations, but you're starting behind.

Q: What if I have seasonal inventory spikes? A: Use ISR with configurable revalidation. During peak season (holidays), shorten the revalidation window to 5-10 minutes. During off-season, extend to 24 hours. Balances freshness and cost.

Frequently Asked Questions

What's the difference between SSR, SSG, and ISR?

SSR (Server-Side Rendering) renders pages on every request—slower but real-time data. SSG (Static Site Generation) pre-renders all pages at build time—fastest but stale data between builds. ISR (Incremental Static Regeneration) pre-renders popular pages and renders rare pages on-demand, balancing speed and freshness.

Which rendering strategy is fastest?

SSG is fastest (TTFB 50-150ms). ISR is nearly as fast for cached pages. SSR is slowest (TTFB 300-500ms) because every request hits a server.

Which is cheapest?

SSG is cheapest (often free for <1K products on Vercel/Netlify). ISR is moderate cost. SSR is most expensive because server costs scale with traffic.

How many products can SSG handle?

SSG scales to ~5K products before build times become unmanageable (>30 minutes). Beyond 5K, use ISR.

Do I need Shopify Plus for ISR?

Not required, but Shopify Plus makes ISR easier because you get advanced webhook support. Standard Shopify works with ISR but requires more custom coding.

Can I switch rendering strategies after launch?

Yes, but it's non-trivial. You're essentially rebuilding your storefront. Plan rendering strategy before development, not after.

How does image optimization relate to rendering?

Rendering strategy handles HTML/data. Image optimization (compression, format conversion, lazy-loading) is separate but equally important for overall page speed.

EDITORIAL NOTE: Rendering strategy isn't about picking the "best" approach. It's about matching architecture to your data velocity and traffic patterns. The Tenten team has seen brands overspend on SSR infrastructure when SSG or ISR would deliver better performance at a fraction of the cost. The fastest storefront isn't always the most expensive one.

Authority Citations

  1. Shopify Hydrogen Documentation (2025): "Hydrogen Framework and Rendering Strategies." https://shopify.dev/docs/hydrogen — Official guidance on Hydrogen's SSR, SSG, and ISR capabilities.
  2. Vercel (2025): "Next.js Incremental Static Regeneration (ISR)." https://vercel.com/docs/concepts/next.js/incremental-static-regeneration — Deep dive on ISR implementation and performance benchmarks.
  3. Web.dev (Google): "Core Web Vitals and Rendering Performance." https://web.dev/core-web-vitals/ — Google's standards for page speed and how rendering affects metrics.
  4. Netlify (2025): "Static Site Generation vs. Server-Side Rendering: A Detailed Comparison." https://www.netlify.com — Performance and cost comparisons for rendering strategies.
  5. eMarketer (2025): "E-commerce Site Speed and Conversion Rates." https://www.emarketer.com — Data on how rendering performance affects conversion rates and SEO.