DEV Community: Evgenii Milevich

Shopify Performance Optimization: A Developer's Checklist for 2026

Evgenii Milevich — Fri, 03 Apr 2026 00:28:58 +0000

Last quarter we took a client's Shopify store from a PageSpeed Insights score of 35 to 92. Mobile. On a theme with 14 apps installed. This article is the exact process we followed, written as a checklist you can use on your own stores.

A few things before we start. Shopify is a hosted platform — you don't control the server, the CDN config, or the TLS handshake. That means roughly 30% of your total page load time is outside your control. The good news: the remaining 70% has so much low-hanging fruit that most stores can double their performance score without touching anything architectural.

We do this work regularly at MILEDEVS as part of our Shopify development services. Every recommendation below comes from production stores, not lab conditions.

1. Image Optimization — The Biggest Win

Images account for 50-80% of total page weight on a typical Shopify store. Fix this first.

Use Shopify's Built-in Image CDN Properly

Shopify automatically serves images through their CDN, but only if you use the image_url filter instead of hardcoded URLs:

{% comment %} Bad: hardcoded, no CDN optimization {% endcomment %}
<img src="{{ product.featured_image | img_url: 'master' }}" />

{% comment %} Good: responsive, WebP-auto, CDN-optimized {% endcomment %}
<img
  src="{{ product.featured_image | image_url: width: 600 }}"
  srcset="
    {{ product.featured_image | image_url: width: 300 }} 300w,
    {{ product.featured_image | image_url: width: 600 }} 600w,
    {{ product.featured_image | image_url: width: 900 }} 900w,
    {{ product.featured_image | image_url: width: 1200 }} 1200w
  "
  sizes="(max-width: 768px) 100vw, 50vw"
  loading="lazy"
  decoding="async"
  width="{{ product.featured_image.width }}"
  height="{{ product.featured_image.height }}"
  alt="{{ product.featured_image.alt | escape }}"
/>

Key details:

image_url (not img_url) automatically converts to WebP when the browser supports it
The width and height attributes prevent layout shift — the browser reserves space before the image loads
loading="lazy" defers off-screen images. Do NOT lazy-load the first visible image (hero, first product in grid) — that will hurt LCP
decoding="async" lets the browser decode images off the main thread

Upload Source Images at 2x Maximum Display Size

If your product images display at 600px, upload at 1200px. Not 4000px. Shopify resizes on the fly, but it still has to process larger source files, and you'll sometimes see the original loaded by poorly written app code or social sharing previews.

Our result: Replacing img_url: 'master' with properly sized image_url across a fashion store reduced page weight from 8.2 MB to 1.4 MB. LCP dropped from 6.1s to 2.3s.

2. JavaScript Audit — Find and Kill What You Don't Need

Identify the Bloat

Open Chrome DevTools, go to the Coverage tab (Ctrl+Shift+P, type "Coverage"), reload the page. The red bars show unused bytes. On a typical Shopify store, 60-70% of loaded JavaScript is unused on any given page.

The usual culprits:

Source	Typical Size	Often Unnecessary On
App scripts	200-800 KB	Pages where the app isn't used
Theme vendor.js	100-300 KB	Contains unused jQuery plugins
Analytics (GA4, Meta, TikTok)	150-400 KB	N/A (but can be deferred)
Chat widgets	200-500 KB	Every page except where needed

Defer Non-Critical Scripts

Shopify's content_for_header outputs all app scripts synchronously. You can't change that directly, but you can defer your own theme scripts:

{% comment %} layout/theme.liquid {% endcomment %}

{% comment %} Critical: render-blocking, needed for first paint {% endcomment %}
<script src="{{ 'critical.js' | asset_url }}" defer></script>

{% comment %} Non-critical: load after page is interactive {% endcomment %}
<script>
  window.addEventListener('load', function() {
    var scripts = [
      '{{ "deferred-features.js" | asset_url }}',
      '{{ "reviews-widget.js" | asset_url }}'
    ];
    scripts.forEach(function(src) {
      var s = document.createElement('script');
      s.src = src;
      s.async = true;
      document.body.appendChild(s);
    });
  });
</script>

Remove jQuery If You Can

Dawn and most modern Shopify themes don't require jQuery. If your theme still loads it, check whether any critical functionality depends on it. Many stores load jQuery (90 KB minified) solely because one old app snippet uses $('.something'). Replace those few lines with vanilla JS and drop the entire library.

// Before (requires jQuery)
$('.accordion-toggle').click(function() {
  $(this).next('.accordion-content').slideToggle();
});

// After (vanilla JS, 0 dependencies)
document.querySelectorAll('.accordion-toggle').forEach(function(toggle) {
  toggle.addEventListener('click', function() {
    const content = this.nextElementSibling;
    content.style.display = content.style.display === 'none' ? 'block' : 'none';
  });
});

3. Liquid Profiling — Find Slow Templates

Enable Shopify's Liquid Profiler

Add ?_fd=0&pb=0 to any page URL on your development store to see raw Liquid render times in the response. For more detailed profiling:

https://your-store.myshopify.com/?profile_liquid=true

This adds HTML comments showing render time for every snippet and section. Look for anything over 5ms — that's slow for a Liquid partial.

Common Liquid Performance Traps

Trap 1: Nested loops over large collections

{% comment %} SLOW: O(n*m) — checks every product against every tag {% endcomment %}
{% for product in collections.all.products %}
  {% for tag in product.tags %}
    {% if tag == 'featured' %}
      {% render 'product-card', product: product %}
    {% endif %}
  {% endfor %}
{% endfor %}

{% comment %} FAST: Use a filtered collection instead {% endcomment %}
{% for product in collections.featured.products limit: 12 %}
  {% render 'product-card', product: product %}
{% endfor %}

Trap 2: Rendering the same snippet hundreds of times in a loop

Every {% render %} call has overhead. If you're rendering a product card 50 times in a collection page, make sure the snippet itself is lean — no nested render calls, no redundant assign statements.

Trap 3: Using where filter on large arrays

{% comment %} SLOW on arrays with 1000+ items {% endcomment %}
{% assign filtered = product.metafields.custom.related | where: "status", "active" %}

{% comment %} FASTER: filter server-side via collection or metafield definition {% endcomment %}

4. App Audit — The Hidden Performance Tax

Every Shopify app injects code into your storefront. Most store owners have no idea how much.

The Audit Process

List all installed apps — go to Settings > Apps and sales channels
Check which apps inject frontend code — in theme editor, look at content_for_header output (View Source, search for <script)
Test removal impact — disable apps one at a time and measure PageSpeed after each

What We Typically Find

On the store we took from 35 to 92, here's what the app audit revealed:

Review app: Loading 340 KB of JS on every page, including pages with no reviews. Fix: load conditionally only on product pages using Shopify's app embed controls.
Currency converter: 180 KB. The theme had built-in currency support. App was redundant. Removed.
Exit-intent popup: 220 KB. Replaced with a 3 KB custom implementation using mouseleave event.
Two abandoned analytics apps the client had forgotten about: 280 KB combined. Removed.

Total savings: 1,020 KB of JavaScript. That alone moved the score from 35 to 58.

Replace Heavy Apps With Lightweight Code

Many common app features can be replicated with 20-50 lines of Liquid and JavaScript:

Announcement bars — a <div> with inline styles and a dismiss cookie
Back-in-stock buttons — a form that posts to a Shopify Flow webhook
Size charts — a modal with a static HTML table
Trust badges — SVG icons in a snippet

Don't replace complex apps (reviews, subscriptions, loyalty programs) — those have backend logic that justifies their weight. But purely frontend features often don't need 200 KB of vendor JavaScript.

5. Core Web Vitals — The Metrics That Matter

Google uses three Core Web Vitals for ranking: LCP (Largest Contentful Paint), INP (Interaction to Next Paint), and CLS (Cumulative Layout Shift).

LCP: Target Under 2.5 Seconds

The largest contentful paint is almost always your hero image or the first product image. To optimize:

{% comment %} Preload the hero image — tells the browser to fetch it immediately {% endcomment %}
{% if template.name == 'index' %}
  <link
    rel="preload"
    as="image"
    href="{{ section.settings.hero_image | image_url: width: 1200 }}"
    type="image/webp"
    fetchpriority="high"
  />
{% endif %}

Also add fetchpriority="high" to the hero <img> tag itself:

<img src="..." fetchpriority="high" loading="eager" />

Do NOT lazy-load your LCP element. This is the single most common mistake we see. The loading="lazy" attribute tells the browser to deprioritize the image — the exact opposite of what you want for LCP.

INP: Target Under 200ms

Interaction to Next Paint measures how fast the page responds to user input. Common fixes:

Break up long tasks. If a click handler does heavy DOM manipulation, use requestAnimationFrame or scheduler.yield() to avoid blocking the main thread for more than 50ms.
Debounce search inputs. Don't fire a search query on every keystroke.
Use content-visibility: auto on below-fold sections to reduce rendering work.

/* Skip rendering for off-screen sections */
.section--below-fold {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px;
}

CLS: Target Under 0.1

Layout shift happens when elements move after the page has started rendering. Fixes:

Always set width/height on images (covered in Section 1)
Reserve space for app embeds — if a reviews widget loads asynchronously, wrap its container in a div with a min-height
Font loading — use font-display: swap and preload your primary font:

<link
  rel="preload"
  href="{{ 'custom-font.woff2' | asset_url }}"
  as="font"
  type="font/woff2"
  crossorigin
/>

@font-face {
  font-family: 'CustomFont';
  src: url('custom-font.woff2') format('woff2');
  font-display: swap;
}

The Full Checklist

Here's the condensed version you can copy into your project management tool:

[ ] Replace all img_url with image_url + srcset + sizes
[ ] Add width/height attributes to every <img> tag
[ ] Set loading="lazy" on all images EXCEPT the LCP element
[ ] Preload hero/LCP image with fetchpriority="high"
[ ] Run JS coverage analysis — identify unused bytes
[ ] Defer all non-critical theme JavaScript
[ ] Remove jQuery if no critical features depend on it
[ ] Audit all installed apps — remove unused ones
[ ] Check which apps load JS globally vs. per-page
[ ] Replace simple app features with lightweight code
[ ] Profile Liquid render times — fix templates over 5ms
[ ] Eliminate nested loops over large collections
[ ] Add content-visibility: auto to below-fold sections
[ ] Preload primary web font
[ ] Test with PageSpeed Insights on mobile (not just desktop)
[ ] Verify Core Web Vitals in Google Search Console (field data, not lab)

Measuring Results

Lab scores (Lighthouse, PageSpeed Insights) are useful for development, but field data from Chrome UX Report (CrUX) is what Google uses for ranking. After deploying performance changes, wait 28 days for CrUX data to update before declaring victory.

Check your field data in Google Search Console under Core Web Vitals, or use the CrUX API directly:

curl "https://chromeuxreport.googleapis.com/v1/records:queryRecord?key=YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"origin": "https://your-store.com"}'

The store we optimized from 35 to 92 saw its CrUX "good URLs" percentage go from 12% to 89% over the following month. Organic traffic increased 23% in the same period — not entirely attributable to performance, but the correlation was strong.

Final Thoughts

Performance optimization on Shopify is not a one-time project. Every new app install, every theme update, every seasonal campaign can regress your scores. Build performance checks into your development workflow — run Lighthouse in CI, monitor CrUX monthly, and audit apps quarterly.

If you want a team to handle this end-to-end, we do exactly this at MILEDEVS. But this checklist gives you everything you need to do it yourself. Start with images and the app audit — those two alone will get you 80% of the gains.

How We Built a Fully Automated Shopify Blog Pipeline with AI

Evgenii Milevich — Fri, 03 Apr 2026 00:22:34 +0000

Six months ago, we had a client problem. We run a Shopify development agency (MILEDEVS) and our clients kept asking the same thing: "Can you help us blog consistently?" They understood that organic traffic matters, but nobody had the bandwidth to research topics, write articles, optimize for SEO, create images, and publish — every single week.

So we built a pipeline that does it automatically. Not a WordPress plugin, not a SaaS tool — a custom Node.js system that runs on a cron job and handles the entire workflow from topic discovery to published Shopify blog post.

Here's exactly how it works.

The Architecture

The pipeline has four stages, each handled by a different AI or API:

[Perplexity API] → Topic Research & Trend Detection
       ↓
[GPT-4o]         → Article Generation (SEO-optimized)
       ↓
[Gemini Flash]   → Featured Image Generation
       ↓
[Shopify Admin API] → Publishing with metadata

A single orchestrator script runs nightly, coordinates all four stages, and handles failures gracefully. If image generation fails, the article still publishes with a fallback image. If the Shopify API is rate-limited, posts queue for the next run.

Let's walk through each stage.

Stage 1: Topic Discovery with Perplexity

The hardest part of consistent blogging isn't writing — it's figuring out what to write about. We use Perplexity's API to find topics that are trending in the client's niche but don't yet have strong competition.

async function discoverTopics(niche, existingTitles) {
  const prompt = `You are an SEO content strategist for a ${niche} ecommerce store.

Find 5 blog topic ideas that meet ALL criteria:
1. Currently trending or seasonally relevant (April 2026)
2. Have search intent that leads to product purchases
3. Not already covered: ${existingTitles.join(', ')}

For each topic return:
- title (under 60 chars)
- primary_keyword
- search_intent (informational | commercial | transactional)
- estimated_monthly_volume (rough range)

Return as JSON array.`;

  const response = await perplexity.chat.completions.create({
    model: 'sonar-pro',
    messages: [{ role: 'user', content: prompt }],
  });

  return JSON.parse(response.choices[0].message.content);
}

Why Perplexity instead of a keyword tool? Traditional keyword research tools give you historical data. Perplexity searches the live web, which means it catches trends before they show up in Ahrefs or SEMrush. For a blog pipeline that runs daily, this matters.

We also pass in existingTitles — an array of all previously published posts — so the model doesn't suggest topics we've already covered. Duplicate content is an SEO penalty we can avoid with a simple array check.

Stage 2: Article Generation with GPT-4o

Once we have a topic, we generate the full article. This is where most "AI blog" tools fall flat — they produce generic, surface-level content. Our prompt engineering took weeks of iteration to get right.

async function generateArticle(topic, storeContext) {
  const systemPrompt = `You are a senior content writer for an ecommerce blog.
Store context: ${JSON.stringify(storeContext)}

Rules:
- Write 1200-1800 words
- Use the primary keyword in H1, first paragraph, one H2, and meta description
- Include at least one data point or statistic with a source
- Add internal link opportunities as [INTERNAL_LINK:collection-handle] markers
- Write a meta_description (under 155 chars)
- Tone: expert but approachable, not corporate
- DO NOT use filler phrases like "In today's world" or "It's no secret that"
- Every paragraph must contain actionable information`;

  const response = await openai.chat.completions.create({
    model: 'gpt-4o',
    messages: [
      { role: 'system', content: systemPrompt },
      { role: 'user', content: `Write a blog post about: ${topic.title}\nPrimary keyword: ${topic.primary_keyword}\nSearch intent: ${topic.search_intent}` }
    ],
    temperature: 0.7,
  });

  const article = response.choices[0].message.content;
  return postProcess(article, storeContext);
}

The postProcess function handles several things that the LLM can't do reliably:

function postProcess(article, storeContext) {
  // Replace internal link markers with real Shopify URLs
  let processed = article.replace(
    /\[INTERNAL_LINK:([\w-]+)\]/g,
    (_, handle) => {
      const collection = storeContext.collections.find(c => c.handle === handle);
      return collection
        ? `[${collection.title}](/collections/${handle})`
        : '';
    }
  );

  // Inject product recommendation block after 3rd paragraph
  const paragraphs = processed.split('\n\n');
  if (paragraphs.length > 4) {
    const productBlock = buildProductRecommendation(storeContext.featuredProducts);
    paragraphs.splice(3, 0, productBlock);
    processed = paragraphs.join('\n\n');
  }

  // Add table of contents from H2 headings
  const toc = buildTableOfContents(processed);
  processed = toc + '\n\n' + processed;

  return processed;
}

The [INTERNAL_LINK:handle] marker pattern is a technique we use a lot. Instead of asking the LLM to generate correct URLs (which it will hallucinate), we ask it to place semantic markers. Our code then resolves those markers against real data. This separation of concerns — LLM handles content, code handles data — eliminates an entire class of errors.

Stage 3: Featured Image Generation with Gemini

Every blog post needs a featured image. Stock photos look generic. Custom photography is expensive. AI-generated images hit a sweet spot when done right.

async function generateFeaturedImage(topic, articleExcerpt) {
  const prompt = `Create a clean, professional blog header image for an article titled "${topic.title}".

Style: modern flat illustration, muted color palette, no text overlays,
suitable for an ecommerce blog. The image should suggest the topic
without being literal. Aspect ratio 16:9.

Article context: ${articleExcerpt.substring(0, 300)}`;

  const response = await genai.models.generateImages({
    model: 'imagen-3.0-generate-002',
    prompt: prompt,
    config: {
      numberOfImages: 1,
      aspectRatio: '16:9',
    },
  });

  const imageBuffer = Buffer.from(response.generatedImages[0].image.imageBytes, 'base64');

  // Optimize before upload — Shopify doesn't compress on ingest
  const optimized = await sharp(imageBuffer)
    .resize(1200, 675, { fit: 'cover' })
    .webp({ quality: 82 })
    .toBuffer();

  return optimized;
}

The sharp optimization step is non-optional. Raw AI-generated images are typically 2-4 MB. After resizing to 1200x675 and converting to WebP at quality 82, they're under 100 KB with no visible quality loss. Since these images load on every blog listing page, the cumulative bandwidth savings are significant.

We also explicitly tell the model "no text overlays" because AI-generated text in images is still unreliable — misspellings and garbled characters would look unprofessional.

Stage 4: Publishing to Shopify

The final stage uploads the image and creates the blog post via Shopify's Admin API.

async function publishToShopify(article, image, topic, shopifyClient) {
  // Upload image first
  const stagedTarget = await shopifyClient.graphql(`
    mutation {
      stagedUploadsCreate(input: {
        resource: BLOG_IMAGE
        filename: "${topic.primary_keyword.replace(/\s+/g, '-')}.webp"
        mimeType: "image/webp"
        httpMethod: POST
      }) {
        stagedTargets {
          url
          resourceUrl
          parameters { name value }
        }
      }
    }
  `);

  // POST image to staged URL (simplified)
  const target = stagedTarget.stagedUploadsCreate.stagedTargets[0];
  await uploadToStaged(target, image);

  // Create the blog article
  const result = await shopifyClient.graphql(`
    mutation {
      articleCreate(article: {
        blogId: "gid://shopify/Blog/${BLOG_ID}"
        title: "${escapeGql(topic.title)}"
        body: "${escapeGql(article)}"
        summary: "${escapeGql(topic.meta_description)}"
        image: { src: "${target.resourceUrl}" }
        isPublished: true
        publishDate: "${new Date().toISOString()}"
      }) {
        article { id handle }
        userErrors { field message }
      }
    }
  `);

  return result;
}

Why GraphQL instead of REST? Shopify's REST blog API works fine for simple cases. But the GraphQL mutation lets us handle staged uploads and article creation in a predictable flow. More importantly, userErrors in GraphQL responses are structured — we can parse and retry specific failures instead of guessing from HTTP status codes.

The Orchestrator

The cron job that ties it all together runs at 21:00 UTC daily:

// Simplified orchestrator
async function runPipeline(storeConfig) {
  const existingPosts = await fetchExistingBlogPosts(storeConfig.shopify);
  const existingTitles = existingPosts.map(p => p.title);

  const topics = await discoverTopics(storeConfig.niche, existingTitles);
  const selectedTopic = topics[0]; // Take highest-priority topic

  const article = await generateArticle(selectedTopic, storeConfig.context);

  let image;
  try {
    image = await generateFeaturedImage(selectedTopic, article);
  } catch (err) {
    console.error('Image generation failed, using fallback:', err.message);
    image = storeConfig.fallbackImage;
  }

  const result = await publishToShopify(
    article, image, selectedTopic, storeConfig.shopify
  );

  await logToDatabase({
    topic: selectedTopic,
    articleId: result.article?.id,
    status: result.userErrors?.length ? 'error' : 'published',
    errors: result.userErrors,
    timestamp: new Date(),
  });
}

Error handling philosophy: Every stage can fail independently. Image generation failures shouldn't block publishing. Shopify rate limits shouldn't crash the process. Each failure is logged with enough context to debug, and the pipeline moves on. Over six months, we've had a 94% success rate on first attempt, with failures almost always being transient API issues that resolve on retry.

Results After 6 Months

For one client store in the home decor niche:

180+ articles published automatically
Organic traffic up 340% (from ~2,000 to ~8,800 monthly sessions)
42 keywords ranking on page 1 that had no presence before
Average time to publish: 4 minutes from trigger to live post
Monthly cost: ~$45 in API calls (Perplexity + OpenAI + Gemini)

The ROI math is straightforward: $45/month in API costs replaces what would be $2,000-3,000/month in freelance writing fees for equivalent output.

You can see examples of pipeline-generated content on our blog — some of our own posts use the same system.

What We'd Do Differently

1. Add a human review queue. Fully autonomous publishing works 90% of the time. The other 10% produces posts that are technically correct but tonally off, or that cover a topic too similar to an existing post. A Slack notification with a 2-hour approval window would catch these.

2. A/B test titles. We generate the article but not title variations. Running two titles against each other on social channels before committing to one for SEO would improve click-through rates.

3. Multi-language support. Several clients sell internationally. Generating articles in 2-3 languages per topic would multiply the organic reach with minimal additional API cost.

Should You Build This?

If you're publishing fewer than 4 blog posts per month because of bandwidth constraints, and you have a Shopify store with products that benefit from content marketing — yes. The pipeline pays for itself within the first month.

If you're interested in this kind of automation for your store, reach out to our team at MILEDEVS. We build custom pipelines, not one-size-fits-all tools.

The full pipeline is about 800 lines of JavaScript. The hardest part isn't the code — it's the prompt engineering and the edge case handling. Both take weeks of iteration that you only learn by running the system in production.

5 Shopify Liquid Tricks That Actually Boost Conversion Rate

Evgenii Milevich — Fri, 03 Apr 2026 00:21:27 +0000

Most Shopify Liquid tutorials stop at "here's how to render a variable." That's fine for learning, but it won't help you ship features that actually increase revenue.

At our agency (MILEDEVS), we've tested these patterns across 15+ stores over the past two years. Every trick below comes from a real A/B test or a measurable before-and-after on a production storefront. No theory — just code you can paste into your theme and adapt.

1. Dynamic Product Badges That React to Real Data

Static "SALE" badges are everywhere. They're also easy to ignore. A badge that says "32% OFF — ends Thursday" converts better because it carries specific, time-sensitive information.

{% comment %} snippets/dynamic-badge.liquid {% endcomment %}

{% if product.compare_at_price > product.price %}
  {% assign discount = product.compare_at_price | minus: product.price %}
  {% assign percent = discount | times: 100.0 | divided_by: product.compare_at_price | round %}

  <span class="badge badge--sale" aria-label="On sale">
    {{ percent }}% OFF
  </span>

{% elsif product.created_at | date: "%s" | plus: 604800 > "now" | date: "%s" %}
  <span class="badge badge--new" aria-label="New arrival">
    NEW
  </span>

{% elsif product.metafields.custom.bestseller == true %}
  <span class="badge badge--best" aria-label="Bestseller">
    BESTSELLER
  </span>
{% endif %}

Why it works: The badge hierarchy prevents stacking (sale takes priority over "new," which takes priority over "bestseller"). The percentage is calculated from real price data, so it's always accurate. The 604800-second window (7 days) means "NEW" disappears automatically — no manual cleanup.

Result on a client store: Switching from a static "SALE" image to this dynamic badge increased click-through from collection pages by 11%.

2. Stock Urgency Without Lying to Customers

Fake scarcity ("Only 2 left!!" on every product) erodes trust. Real inventory-based urgency is different — it's honest, and it works.

{% comment %} snippets/stock-urgency.liquid {% endcomment %}

{% assign inventory_total = 0 %}
{% for variant in product.variants %}
  {% if variant.inventory_management == 'shopify' %}
    {% assign inventory_total = inventory_total | plus: variant.inventory_quantity %}
  {% endif %}
{% endfor %}

{% if inventory_total > 0 and inventory_total <= 5 %}
  <div class="stock-urgency" role="status">
    <svg class="stock-urgency__icon" aria-hidden="true" width="14" height="14">
      <circle cx="7" cy="7" r="5" fill="#e53e3e" />
    </svg>
    <span>Only {{ inventory_total }} left in stock</span>
  </div>
{% elsif inventory_total > 5 and inventory_total <= 20 %}
  <div class="stock-indicator" role="status">
    <svg class="stock-indicator__icon" aria-hidden="true" width="14" height="14">
      <circle cx="7" cy="7" r="5" fill="#38a169" />
    </svg>
    <span>In stock</span>
  </div>
{% endif %}

The key detail: We only show a count when it's genuinely low (5 or fewer). Above that, we show a calm green "In stock" dot. If you show "Only 47 left" nobody cares — that's not urgency, that's inventory management leaking into your UI.

3. Smart Breadcrumbs That Reflect the Customer's Path

Default Shopify breadcrumbs show the product's primary collection. But if a customer arrived via a different collection, the breadcrumb should reflect their journey, not your taxonomy.

{% comment %} snippets/smart-breadcrumbs.liquid {% endcomment %}

<nav class="breadcrumb" aria-label="Breadcrumb">
  <ol itemscope itemtype="https://schema.org/BreadcrumbList">
    <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
      <a href="/" itemprop="item"><span itemprop="name">Home</span></a>
      <meta itemprop="position" content="1" />
    </li>

    {% if collection %}
      {% assign crumb_collection = collection %}
    {% elsif product.collections.size > 0 %}
      {% assign referrer = request.host | append: request.path %}
      {% assign crumb_collection = product.collections | first %}

      {% for col in product.collections %}
        {% if request.page_url contains col.handle %}
          {% assign crumb_collection = col %}
          {% break %}
        {% endif %}
      {% endfor %}
    {% endif %}

    {% if crumb_collection %}
      <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
        <a href="{{ crumb_collection.url }}" itemprop="item">
          <span itemprop="name">{{ crumb_collection.title }}</span>
        </a>
        <meta itemprop="position" content="2" />
      </li>
    {% endif %}

    {% if product %}
      <li itemprop="itemListElement" itemscope itemtype="https://schema.org/ListItem">
        <span itemprop="name" aria-current="page">{{ product.title }}</span>
        <meta itemprop="position" content="3" />
      </li>
    {% endif %}
  </ol>
</nav>

What's happening: The snippet checks if a collection object is already in scope (meaning the customer navigated from a collection page). If not, it falls back to the product's first collection. The Schema.org markup is included because breadcrumbs are one of the easiest structured data wins for SEO.

4. Lazy-Loaded Sections for Below-the-Fold Content

Shopify sections render server-side, which means every section on your page adds to Time to First Byte. For content below the fold you can defer rendering until the user scrolls.

{% comment %} sections/lazy-testimonials.liquid {% endcomment %}

<div class="lazy-section" data-lazy-section="testimonials" style="min-height: 400px;">
  <noscript>
    {% render 'testimonials-content' %}
  </noscript>
</div>

<script>
  (function() {
    const observer = new IntersectionObserver((entries) => {
      entries.forEach(entry => {
        if (!entry.isIntersecting) return;
        const el = entry.target;
        const url = window.location.pathname + '?sections=' + el.dataset.lazySection;
        fetch(url, { headers: { 'Accept': 'application/json' } })
          .then(r => r.json())
          .then(data => { const key = Object.keys(data)[0]; if (key) el.innerHTML = data[key]; })
          .catch(() => { const ns = el.querySelector('noscript'); if (ns) el.innerHTML = ns.textContent; });
        observer.unobserve(el);
      });
    }, { rootMargin: '200px' });
    document.querySelectorAll('[data-lazy-section]').forEach(s => observer.observe(s));
  })();
</script>

We've written more about this technique in our Shopify store optimization guide.

5. Conditional Free Shipping Bar With Real Cart Data

A free shipping bar should show how far the customer is from the threshold, update live when items are added, and disappear once the threshold is met.

{% assign threshold_cents = settings.free_shipping_threshold | times: 100 %}
{% assign cart_total = cart.total_price %}
{% assign remaining = threshold_cents | minus: cart_total %}

{% if threshold_cents > 0 %}
  <div class="shipping-bar" data-shipping-bar data-threshold="{{ threshold_cents }}" role="status" aria-live="polite">
    {% if remaining > 0 %}
      {% assign progress = cart_total | times: 100 | divided_by: threshold_cents %}
      <div class="shipping-bar__track">
        <div class="shipping-bar__fill" style="width: {{ progress }}%"></div>
      </div>
      <p>Add <strong>{{ remaining | money }}</strong> more for free shipping!</p>
    {% else %}
      <p class="shipping-bar__text--success">You've unlocked free shipping!</p>
    {% endif %}
  </div>
{% endif %}

Wrapping Up

None of these tricks require an app install. They're pure Liquid and vanilla JavaScript.

If you want to go deeper, we publish technical breakdowns on our blog. And if you need a team to implement these optimizations, that's what we do at MILEDEVS.

The best optimization is the one you actually ship. Pick one, implement it today, measure for a week, and iterate.