Forem: Peter Hallander

Building related-post recommendations for a Shopify blog — the algorithm, not the app

Peter Hallander — Wed, 13 May 2026 19:14:48 +0000

Shopify gives you product recommendations out of the box. There's a whole /recommendations/products.json endpoint, a recommendations.products Liquid drop, and an entire ML pipeline behind it. For blog posts? Nothing. Zero. There is no /recommendations/articles, no recommendations.articles, no signal. If you run an editorial blog on Shopify — and a lot of stores do now, because content is how you get organic traffic without paying Meta — you're on your own.

What most themes do is one of three things:

A "Latest 3 posts" widget at the bottom of every article.
A hand-curated metafield where the merchant picks related posts manually.
An app that you install and treat as a black box.

I've shipped all three for clients. The first one is useless. The second one only works for the first month, then nobody updates the metafields. The third one works fine but most merchants want to understand what's actually happening. So this post is about how to roll your own — the algorithm, the rendering pattern, and the things I got wrong the first two times.

I'll be upfront: I made an app for this. I'll mention it once near the end. The article isn't about the app — it's about the engineering. If you'd rather build it yourself after reading this, fantastic; that's the point.

Why "latest posts" is the wrong default

A reader who lands on your article about "summer wedding shoes for outdoor ceremonies" is interested in summer wedding shoes for outdoor ceremonies. If your latest three posts are about pet grooming, holiday gift guides, and a sustainability report, you've just shown them three exit ramps. Bounce goes up. Pages-per-session goes down. And the internal linking signal you could have given Google — "this article about wedding shoes is topically related to these other wedding shoe articles" — is wasted on noise.

The fix isn't fancy. You need a similarity function that takes the current article and returns a ranked list of other articles, where "ranked" means topically relevant, not chronologically recent. Then you render the top three or four. That's it. The hard part is doing it without slowing the page down or breaking SEO.

The baseline: tag overlap with Jaccard similarity

Every Shopify article has a tags array. Most editorial Shopify stores tag posts with things like wedding, summer, outdoor, shoes, style-guide. If two articles share a high proportion of tags, they're probably related. That's the entire premise of Jaccard similarity:

J(A, B) = |A ∩ B| / |A ∪ B|

Intersection over union. Score between 0 and 1. Higher means more overlap. It's the simplest non-trivial similarity function you can compute, and for blog posts with reasonable tagging, it's surprisingly strong as a baseline.

You can do this in pure Liquid. No JS, no fetch, no script tag — the markup renders server-side and you get the related posts inline. Here's the loop:

{%- liquid
  assign current_tags = article.tags
  assign current_handle = article.handle
  assign scored = ''
-%}

{%- for post in blog.articles -%}
  {%- if post.handle == current_handle -%}{%- continue -%}{%- endif -%}

  {%- assign intersection = 0 -%}
  {%- assign union_set = current_tags | concat: post.tags | uniq -%}

  {%- for tag in current_tags -%}
    {%- if post.tags contains tag -%}
      {%- assign intersection = intersection | plus: 1 -%}
    {%- endif -%}
  {%- endfor -%}

  {%- assign union_size = union_set | size -%}
  {%- if union_size == 0 -%}{%- continue -%}{%- endif -%}

  {%- assign score = intersection
    | times: 1000
    | divided_by: union_size -%}

  {%- assign entry = score
    | append: '|'
    | append: post.handle -%}
  {%- assign scored = scored | append: entry | append: ',' -%}
{%- endfor -%}

{%- assign scored_list = scored
  | split: ','
  | sort
  | reverse -%}

<ul class="related-posts">
  {%- for entry in scored_list limit: 3 -%}
    {%- assign parts = entry | split: '|' -%}
    {%- assign handle = parts[1] -%}
    {%- assign related = blog.articles[handle] -%}
    {%- if related -%}
      <li>
        <a href="{{ related.url }}">
          <img src="{{ related.image | image_url: width: 400 }}"
               alt="{{ related.title | escape }}"
               loading="lazy">
          <h3>{{ related.title }}</h3>
        </a>
      </li>
    {%- endif -%}
  {%- endfor -%}
</ul>

A few notes on this. Liquid doesn't have floats, so I multiply by 1000 before dividing to preserve precision in the sort. The string concatenation trick (score|handle,score|handle,... then split and sort) is how you get a stable sort by numeric score in pure Liquid without a sort_by filter on a dynamic key. It's ugly. It works.

The other thing: this loops over blog.articles, which on a small blog is fine. On a blog with several hundred articles you'll pay for it in render time, and blog.articles is also capped at 50 by default — you'll want to paginate or limit to the most recent N for the candidate set. In practice, scoring against the last 50 articles is more than enough for relevance; older posts are usually less relevant anyway.

Adding author as a secondary signal

Tags are noisy. Some writers under-tag, some over-tag. A second signal that's almost free: same author. If two articles share an author, that's often a strong topical signal because writers tend to specialize. Your shoe writer writes about shoes. Your sustainability writer writes about sustainability. You don't even need to look at the tags to know the next article from the same person is probably in the same orbit.

I weight this lower than tags — author is a coarse signal, tags are fine-grained — but adding +0.2 when authors match and the article is in the same blog has been a clean lift in the data I've seen. It's also the savior when tags are sparse, which on a newer blog they will be.

In Liquid:

{%- assign author_bonus = 0 -%}
{%- if post.author == article.author -%}
  {%- assign author_bonus = 200 -%}
{%- endif -%}
{%- assign final_score = score | plus: author_bonus -%}

(Again, scaled by 1000 to play nice with integer math.)

Keyword overlap from titles and handles

The third signal is the most useful but takes the most care: content keyword overlap. Tags are author-controlled and inconsistent. The article title and the URL handle are usually clean, descriptive, and stable. "summer-wedding-shoes-outdoor" tells you a lot more than the tag summer does.

You can tokenize the title plus handle once per article, drop stopwords, and compute overlap against the current article's tokens. The bigger version of this is TF-IDF — you compute term frequency for each article and inverse document frequency across the whole corpus, then take a dot product on the resulting vectors. That's textbook IR and it works, but you don't need it for a blog with 50–500 articles. Plain keyword overlap with a stopword list gets you 80% of the win for 10% of the complexity.

I do this in JS rather than Liquid because tokenization in Liquid is painful and you can cache the token sets in localStorage or just compute them once per page load. Liquid handles the initial render with the tag-only score, then JS upgrades the list on hydration if you want a fancier score. Or — and this is what I do now — you push the whole scoring step server-side via the Section Rendering API.

Section Rendering API: why it matters

Here's the thing about doing recommendations purely in client-side JS: you lose two things you actually need.

First, SEO. Googlebot does render JS these days, but it discounts JS-rendered content and especially JS-rendered internal links. If the related-posts block is in the initial HTML, you get the full internal-link equity from day one. If it's injected on hydration, you don't.

Second, CLS. Cumulative Layout Shift is a real Core Web Vitals metric and Google ranks pages worse when they shift. A block that materializes 600ms after first paint pushes the footer down and you eat a CLS penalty. Reserving space with a skeleton is one fix, but the cleaner answer is to render the section server-side and not have it pop in at all.

Shopify's Section Rendering API lets you request a single section's rendered HTML from any URL. The pattern is ?section_id=related-posts appended to any request. You get back HTML, and you swap it into the DOM.

Why is this useful if Liquid already rendered the section server-side on the initial page load? Because you can do a two-pass approach:

First paint: render with the cheap tag-only scoring directly in Liquid. The block exists in HTML, the links are crawlable, no CLS.
Hydration: fetch the same section with a richer query (more candidate articles, optional author/keyword weighting) and replace the HTML. The swap is identical layout, no shift.

Or, simpler: render once server-side with the full algorithm and never touch the DOM after. That's what I do for most installs. The Section Rendering API still matters because it's how you re-render the block in a wishlisted or AJAX-y context without reloading the page.

Here's the fetch:

async function loadRelatedPosts(articleHandle, container) {
  const url = `/blogs/news/${articleHandle}?section_id=related-posts`;

  try {
    const res = await fetch(url, {
      headers: { 'Accept': 'text/html' }
    });
    if (!res.ok) throw new Error(`HTTP ${res.status}`);

    const html = await res.text();
    // The section response is wrapped in a div with the section id.
    const parser = new DOMParser();
    const doc = parser.parseFromString(html, 'text/html');
    const fresh = doc.querySelector(`#shopify-section-related-posts`);

    if (fresh && container) {
      container.replaceWith(fresh);
    }
  } catch (err) {
    console.warn('Related posts refresh failed', err);
    // Leave the server-rendered block in place. Graceful degradation.
  }
}

Two things worth flagging. The URL has to be a valid Shopify URL — you can hit the article URL itself, or /, or any path that includes the section in its template. Different themes scope sections differently; you'll want to test which path includes your section. And the response is HTML, not JSON. There's no section.id.json endpoint for blog sections the way there is for product sections in some setups. Parse the HTML, find your section's outer wrapper by ID, and swap.

Combined scoring

Putting it together, here's the scoring function I land on for most stores. Tag overlap is the spine. Author is a tiebreaker. Keywords are the fine-grain.

const STOPWORDS = new Set([
  'the','a','an','and','or','of','to','in','on','for','with',
  'is','are','was','were','be','been','it','this','that','your','you'
]);

function tokenize(text) {
  return text
    .toLowerCase()
    .replace(/[^a-z0-9\s-]/g, ' ')
    .split(/[\s-]+/)
    .filter(t => t.length > 2 && !STOPWORDS.has(t));
}

function jaccard(setA, setB) {
  const a = new Set(setA);
  const b = new Set(setB);
  const intersection = [...a].filter(x => b.has(x)).length;
  const union = new Set([...a, ...b]).size;
  return union === 0 ? 0 : intersection / union;
}

function scoreArticle(current, candidate) {
  const tagScore = jaccard(current.tags, candidate.tags);

  const authorScore = current.author === candidate.author ? 1 : 0;

  const currentTokens = tokenize(
    `${current.title} ${current.handle}`
  );
  const candidateTokens = tokenize(
    `${candidate.title} ${candidate.handle}`
  );
  const keywordScore = jaccard(currentTokens, candidateTokens);

  return (
    tagScore * 0.5 +
    authorScore * 0.2 +
    keywordScore * 0.3
  );
}

function rankRelated(current, candidates, limit = 3) {
  return candidates
    .filter(c => c.handle !== current.handle)
    .map(c => ({ ...c, _score: scoreArticle(current, c) }))
    .filter(c => c._score > 0)
    .sort((a, b) => b._score - a._score)
    .slice(0, limit);
}

Weights are tunable. I've ended up at 0.5 / 0.2 / 0.3 because tags are the highest-signal feature on a well-tagged blog, but keywords pull more weight when tags are sparse. If you have a content audit step, you can A/B these — track click-through on the related-posts block as your success metric and adjust. The fallback when every score is 0 (an article with unique tags, unique author, no shared keywords) is to surface the latest few posts. That's the only legitimate use case for the "latest 3" widget — as a fallback, not as a default.

What I'd avoid

A few patterns I've seen on stores I've looked at that don't work:

Random shuffle. Some themes ship with "related posts" that are actually just blog.articles | shuffle | limit: 3. It's worse than latest-3 because at least latest-3 surfaces fresh content. Random surfaces archive posts that the merchant has probably stopped maintaining.

Pure JS rendering with no SSR fallback. Pretty common in older "related posts" apps. Block injects on DOMContentLoaded, Googlebot mostly ignores it, internal-link equity wasted, CLS hit. If you're doing this in 2026, stop.

Showing more than 3 or 4. Diminishing returns. The fourth and fifth items get clicks in the low single digits in the merchant data I've looked at. Real estate is better spent on a newsletter signup or a product card.

Scoring against every article. Cap the candidate set. The most recent 50 is plenty for any reasonable blog. If you genuinely have a 5000-article archive, build a separate batch job that pre-computes related posts and stores them in metafields. That's a different post though.

What shipping it taught me

A few things I didn't expect.

Most merchants under-tag. Their articles have one or two tags total, and Jaccard scores are mostly 0 or 0.5. The author and keyword signals carry more weight in practice than they should in theory. If you're building this for a single store, audit the tagging first — you'll get more lift from cleaning tags than from tweaking weights.

Carousels test worse than grids on mobile, from what I've seen. People scroll past carousels because they look like ads. A 2x2 grid that all renders above the fold of the post-article scroll position outperforms a swipeable carousel in the click-through data I've had access to. Hedge: this is from a handful of stores, not a controlled study. Try both.

The Section Rendering API approach saved me from a CLS regression on one store that was running a Liquid-rendered block but with images that loaded after first paint. Adding explicit width and height on the related-post thumbnails matters at least as much as the rendering pattern itself. Reserve the space.

I made an app for this — Better Related Blog Posts — if you'd rather not roll your own. It's on the App Store and it does the tag/author/keyword scoring plus the layouts (grid, list, carousel) on a Theme App Extension so there's no script tag and nothing to maintain. Happy to share more about how it's built if useful. But honestly, if you're comfortable in Liquid and JS, everything above is enough to build the V1 yourself in an afternoon. The hard part isn't the algorithm — it's getting the tagging clean enough that the algorithm has signal to work with.

Per-country free shipping thresholds in Shopify — Markets API + Theme App Extensions

Peter Hallander — Sat, 09 May 2026 11:55:03 +0000

Most free shipping bars on the Shopify App Store assume one number. You set "$50 ships free" in the app settings, the bar appears, and that's the end of the configuration. Fine if you only sell in one country.

But if you've turned on Shopify Markets and you're shipping to the UK, the EU, Canada, Australia — that single global threshold is actively misleading. A UK shopper sees "$50 to free shipping" while their cart shows £35. A German shopper sees the dollar sign and quietly leaves. The bar that's supposed to nudge AOV up becomes a confidence-killer.

I ran into this exact problem on a store I worked on last year. Markets was configured for five regions, and the existing free shipping app — one of the popular ones with thousands of installs — was happily showing "$75 away from free shipping" to every shopper, regardless of which storefront they hit. The merchant didn't notice for weeks because she only ever tested on her US store.

So I built one that actually reads the Markets API and switches threshold per country. Here's how it works.

The shape of the problem

Shopify Markets lets a merchant configure separate currencies, prices, domains, and shipping zones per region. The public Storefront API exposes the active market via localization.country, and there's a markets query for the full list. What it doesn't give you is "the free shipping threshold for this market" — that's a property of the shipping rate config, which lives in the Admin and isn't exposed to the storefront.

That's a deliberate gap. Shopify's internal checkout knows about the rate; the storefront doesn't. So if you want to display a progress bar that says "you're £10 away from free shipping in the UK", you have two options:

Have the merchant manually duplicate their shipping rate config into your app's settings, per market.
Sync once via a private app + Admin API, then cache.

I went with option 1. Sounds tedious but it's actually less brittle — the Admin API exposes shipping rates differently across plans, and merchants on Basic vs Plus get different shapes back. Asking the merchant to type the number once into a metaobject is honest.

Storing thresholds as metaobjects

Metaobjects are the right primitive here. You define a shipping_threshold metaobject type with two fields — country_code (ISO alpha-2) and amount (money) — and the merchant adds one entry per market. They're queryable from Liquid in a Theme App Extension via shop.metaobjects, which means the data lives with the store, not in your app's database. If a merchant uninstalls the app and reinstalls a year later, the config is still there.

Here's what the app block schema looks like:

{% schema %}
{
  "name": "Free Shipping Bar",
  "target": "body",
  "settings": [
    {
      "type": "single_line_text_field",
      "id": "default_threshold",
      "label": "Default threshold (fallback)",
      "default": "50"
    },
    {
      "type": "single_line_text_field",
      "id": "default_currency",
      "label": "Default currency code",
      "default": "USD"
    },
    {
      "type": "single_line_text_field",
      "id": "message_progress",
      "label": "Progress message",
      "default": "Spend {{ remaining }} more for free shipping"
    },
    {
      "type": "single_line_text_field",
      "id": "message_unlocked",
      "label": "Unlocked message",
      "default": "You've got free shipping"
    },
    {
      "type": "color",
      "id": "bar_color",
      "label": "Bar color",
      "default": "#111111"
    },
    {
      "type": "select",
      "id": "display_mode",
      "label": "Display mode",
      "options": [
        { "value": "overlay", "label": "Overlay" },
        { "value": "push",    "label": "Push down content" }
      ],
      "default": "push"
    }
  ]
}
{% endschema %}

The thresholds themselves come from a metaobject the merchant configures once in the Admin under Content → Metaobjects → Shipping Threshold. Reading them in Liquid:

{% liquid
  assign country = localization.country.iso_code
  assign matched_threshold = block.settings.default_threshold
  assign matched_currency  = block.settings.default_currency

  for entry in shop.metaobjects.shipping_threshold.values
    if entry.country_code.value == country
      assign matched_threshold = entry.amount.value | money_without_currency
      assign matched_currency  = entry.amount.currency
      break
    endif
  endfor

  capture thresholds_json
    echo '{'
    for entry in shop.metaobjects.shipping_threshold.values
      echo '"' | append: entry.country_code.value | append: '":'
      echo '{"amount":' | append: entry.amount.value | append: ','
      echo '"currency":"' | append: entry.amount.currency | append: '"}'
      unless forloop.last
        echo ','
      endunless
    endfor
    echo '}'
  endcapture
%}

<script>window.__freeShippingThresholds = {{ thresholds_json }};</script>

<free-shipping-bar
  data-threshold="{{ matched_threshold }}"
  data-currency="{{ matched_currency }}"
  data-country="{{ country }}"
  data-mode="{{ block.settings.display_mode }}"
  data-message-progress="{{ block.settings.message_progress | escape }}"
  data-message-unlocked="{{ block.settings.message_unlocked | escape }}"
></free-shipping-bar>

The localization.country.iso_code is the line that does the work. It's populated by Shopify's edge based on the active market — same source the prices on the storefront use, so there's no inconsistency between what the cart shows and what the bar reads. If Markets isn't configured at all, it falls back to the shop's primary country, and the default threshold from the block settings kicks in.

The <script> tag at the bottom inlines the full per-country lookup table so the JS layer can re-resolve the threshold without a network round-trip if the shopper switches markets mid-session.

Detecting the country client-side too

Liquid runs once on render. The cart, on the other hand, mutates. If a shopper switches market mid-session — and on stores with country selectors they do — the Liquid-rendered country goes stale. So I read it again on the JS side.

There are three sources for the active country in the browser:

The Shopify global, specifically Shopify.country and Shopify.currency.active. Set by Shopify's storefront runtime.
The HTML element's lang attribute (locale, not country — careful).
A cookie called cart_currency for the currency, no built-in cookie for country.

Of these, Shopify.country is the only one that's reliable across the Online Store 2.0 themes I've tested against. It's not officially documented as a public API, which is the usual Shopify reality — half the things that work are technically internal. I read it with a fallback to the data attribute that Liquid wrote.

class FreeShippingBar extends HTMLElement {
  constructor() {
    super();
    this.country   = this.detectCountry();
    this.currency  = this.detectCurrency();
    this.threshold = parseFloat(this.dataset.threshold);
    this.subtotal  = 0;
    this.debounceTimer = null;
  }

  detectCountry() {
    if (window.Shopify?.country) return window.Shopify.country;
    if (this.dataset.country)    return this.dataset.country;
    return 'US';
  }

  detectCurrency() {
    if (window.Shopify?.currency?.active) return window.Shopify.currency.active;
    return this.dataset.currency || 'USD';
  }

  connectedCallback() {
    this.fetchInitialCart();
    document.addEventListener('cart:updated', this.handleCartUpdate.bind(this));
    // Theme variants — none of these are standard, all are common in the wild
    document.addEventListener('cart:refresh', this.handleCartUpdate.bind(this));
    document.addEventListener('cart:change',  this.handleCartUpdate.bind(this));
  }

  async fetchInitialCart() {
    const res  = await fetch('/cart.js', { credentials: 'same-origin' });
    const cart = await res.json();
    this.subtotal = cart.total_price / 100;
    this.render();
  }
}

customElements.define('free-shipping-bar', FreeShippingBar);

Two notes here. The fallback chain matters more than it looks — on a few legacy themes I tested, window.Shopify doesn't exist by the time the custom element initializes, so the data-country attribute that Liquid wrote is what saves you. And Shopify.currency.active returns a 3-letter ISO code, which is exactly what Intl.NumberFormat wants downstream, so no translation layer.

The real-time update

This is where most free shipping bars I've taken apart get sloppy. They listen for one event, re-render the whole component, and trigger a layout shift on every keystroke in a quantity input. On a slow Android device that compounds badly.

The pattern I landed on: debounce the event handler, hash the relevant cart state, and only re-render when something material actually changes.

handleCartUpdate(event) {
  clearTimeout(this.debounceTimer);
  this.debounceTimer = setTimeout(() => {
    this.refreshFromCart(event?.detail?.cart);
  }, 120);
}

async refreshFromCart(cartFromEvent) {
  let cart = cartFromEvent;
  if (!cart || typeof cart.total_price === 'undefined') {
    const res = await fetch('/cart.js', { credentials: 'same-origin' });
    cart = await res.json();
  }

  const newSubtotal = cart.total_price / 100;
  const newCountry  = this.detectCountry();

  // Bail if nothing material changed — avoids re-render storms
  if (newSubtotal === this.subtotal && newCountry === this.country) return;

  this.subtotal = newSubtotal;

  if (newCountry !== this.country) {
    this.country  = newCountry;
    this.currency = this.detectCurrency();
    this.threshold = this.lookupThreshold(newCountry);
  }

  this.render();
}

lookupThreshold(country) {
  // Inlined by Liquid above — no fetch needed
  const map = window.__freeShippingThresholds || {};
  return map[country]?.amount ?? parseFloat(this.dataset.threshold);
}

render() {
  const remaining = Math.max(0, this.threshold - this.subtotal);
  const progress  = Math.min(100, (this.subtotal / this.threshold) * 100);
  const unlocked  = remaining <= 0;

  const message = unlocked
    ? this.dataset.messageUnlocked
    : this.dataset.messageProgress.replace(
        '{{ remaining }}',
        this.formatMoney(remaining, this.currency)
      );

  this.innerHTML = `
    <div class="fs-bar" role="status" aria-live="polite">
      <div class="fs-bar__fill" style="width:${progress}%"></div>
      <div class="fs-bar__msg">${message}</div>
    </div>
  `;
}

formatMoney(amount, currency) {
  return new Intl.NumberFormat(undefined, {
    style: 'currency',
    currency,
    minimumFractionDigits: 0
  }).format(amount);
}

A few things worth calling out.

role="status" and aria-live="polite" matter because the bar updates asynchronously and screen readers should hear the new state without being interrupted mid-sentence. Most free shipping bars I audited had no ARIA at all.

The threshold map is read from window.__freeShippingThresholds — that's the JSON the Liquid layer inlined. You already paid for the metaobject lookup at render time, so don't pay for it again from JS.

The debounce on the event handler is something I tuned by hand. Too aggressive and you can still get double renders from theme code that fires cart:change twice in quick succession (looking at you, Dawn fork). Too lax and the bar feels laggy — you can see the visual delay between adding an item and the bar updating. The window I landed on felt right across the themes I tested.

The bail-out check at the top — if (newSubtotal === ... && newCountry === ...) — sounds obvious but the legacy bars I took apart re-render unconditionally. On a cart drawer that re-fires cart:updated every time a quantity field gets focus, that adds up.

Why Theme App Extension over a script tag

This part is going to feel preachy if you've been reading Shopify dev posts for the last two years, but a lot of free shipping bars on the App Store are still legacy script tag apps. They inject a <script src="https://cdn.theirapp.com/bar.js"> into theme.liquid via the ScriptTag API, the script does its own DOM injection, and the bundle is render-blocking by default.

Theme App Extensions replaced that pattern. The arguments are familiar:

The block lives in the merchant's theme editor. They drag it into the section they want, configure it visually, and remove it the same way. No support tickets that start with "I uninstalled the app but the bar is still there."
No theme.liquid modification. When the merchant updates their theme or switches to a new one, the app block follows the section it's attached to, not a hardcoded edit.
Liquid runs server-side at render. Country detection, threshold lookup, message rendering — all happen before the first byte ships, so the bar appears in the initial HTML. No flash, no CLS.
The JS is loaded as a separate asset and you can defer it. The bundle stays small.
App Store review actively flags new submissions that use the ScriptTag API for store-facing UI. It's not strictly deprecated yet but it's on the way.

The migration cost from a script tag app to a TAE is real — you rewrite the rendering layer in Liquid, you re-architect the settings as schema, you give up a chunk of runtime flexibility. The result is faster, cleaner, and survives theme updates.

What I learned shipping this

A few things came out of building and shipping this that I didn't expect.

The metaobject route is more discoverable than an admin UI inside the app. Merchants who'd already used metaobjects for product specs or recipe cards picked up the threshold config in seconds. The ones who'd never touched them needed a screenshot. I added a one-time setup helper inside the app's embedded admin that writes the metaobject definition for them — that cut the setup-related support emails noticeably, though I don't have a clean before/after number I'd publish.

The cart:updated event fragmentation across themes is worse than I assumed going in. Dawn fires it. Some popular paid themes don't fire anything at all on quantity changes — they re-render the cart drawer's HTML wholesale and rely on the next /cart.js fetch. For those, polling /cart.js on a short interval when the cart drawer is open is the only reliable signal. It's ugly. I wish Shopify would standardize this.

Push-down display mode wins almost always over overlay mode in the merchant feedback I've gathered. Overlay covers content above the fold and people complain about it. Push down respects the existing layout. Defaults matter — most merchants don't change the default display mode.

The localization.country fallback chain catches more shoppers than I expected. From talks I've had with merchants running international stores, a non-trivial slice of traffic hits the storefront before Shopify's edge has resolved a market — VPN users, edge cases on certain CDN configurations, shoppers landing via hreflang on the wrong subdomain. Having both a Liquid-side default and a JS-side fallback meant nobody saw a broken bar, even in those edge paths.

I run an NPS-style review prompt that routes unhappy merchants to email instead of straight to the public review form. This isn't a dark pattern — they can still leave a public review if they want — but it gives me a chance to fix the actual issue first. Most "I'd give this 2 stars" responses turn into "thanks, that fixed it" once I reply. From the merchants I've talked to, this matters way more for product quality than any in-app feature.

I made an app for this — AOV Free Shipping Bar Upsell — if you'd rather not roll your own Liquid + JS + metaobject plumbing, it's on the Shopify App Store. The free plan covers the progress bar, all three placements (site-wide embed, product page block, cart page block) and analytics. The Markets-aware per-country thresholds are on the paid tier, alongside multi-store analytics and weekly email reports. Happy to share more about the implementation if it's useful.

What Shopify merchants get wrong about Core Web Vitals — and what's actually worth fixing

Peter Hallander — Fri, 08 May 2026 16:54:04 +0000

I've been scanning Shopify storefronts for the last few months across a sample of stores I've had access to through an app I shipped. Most of them fail Core Web Vitals on at least one metric, and the pattern is depressingly consistent: it's almost always the same three things, in the same order, and the fixes are usually less work than the merchants think.

The number that surprised me most: a large share of the product pages I've scanned have an LCP above 4 seconds on a throttled mobile profile. Above 2.5s is "needs improvement." Above 4s is "poor." That means a lot of merchants are paying for Google ads that land on a page Google itself considers slow, and it's costing them in two places at once — quality score and conversion.

This article is the long version of what I tell merchants when they ask me what to fix first. None of this is theoretical. I've shipped all of it.

Why Core Web Vitals actually matter on Shopify

I'll keep this short because most of it is well-trodden, but two things are worth pulling out for the Shopify context specifically.

First, ad cost. If you run Google Shopping or any kind of paid traffic, landing page experience feeds into Quality Score, which feeds into CPC. A slow PDP is a tax on every click. Merchants who fix LCP often report their cost-per-click drifting down over the following weeks — not always dramatically, but enough to notice on a budget over $500/day.

Second, conversion. The "100ms = 1% conversion" line gets thrown around like gospel and it's not really true at any specific number, but the directional finding is real. On mobile, going from a 5-second LCP to a 2.5-second LCP almost always lifts add-to-cart rate. The size of the lift depends on how desperate your customers were to buy in the first place. A coffee subscription with brand loyalty? Maybe 2%. A first-time visitor on a generic apparel store from a cold ad? Could be 8%.

Don't expect speed alone to fix a conversion problem caused by pricing, photography, or trust. Speed amplifies whatever you already have.

LCP: the hero image trap

The single most common LCP failure I see on Shopify is a 2400px-wide hero image being served to a 390px iPhone viewport, with no loading attribute, no srcset, and no width/height to reserve space.

The fix is built into Liquid. Most themes from the last two years use it correctly on collection grids, but somehow forget to apply it to the homepage hero or the PDP main image, which are exactly the two places it matters.

Here's the pattern I drop into custom sections:

{% liquid
  assign image = section.settings.hero_image
  assign widths = '375,540,750,1080,1500,2000'
%}

<img
  src="{{ image | image_url: width: 1080 }}"
  srcset="
    {{ image | image_url: width: 375 }} 375w,
    {{ image | image_url: width: 540 }} 540w,
    {{ image | image_url: width: 750 }} 750w,
    {{ image | image_url: width: 1080 }} 1080w,
    {{ image | image_url: width: 1500 }} 1500w,
    {{ image | image_url: width: 2000 }} 2000w
  "
  sizes="100vw"
  width="{{ image.width }}"
  height="{{ image.height }}"
  alt="{{ image.alt | escape }}"
  loading="eager"
  fetchpriority="high"
>

Two things people miss:

fetchpriority="high" on the LCP image, loading="eager", and a preload <link> in <head> if you can get away with it. The preload is the cheat code. It pulls the hero image fetch up next to the HTML response instead of waiting for the renderer to discover it. Adding a preload for the hero typically pulls LCP down by several hundred milliseconds in published case studies — sometimes more, depending on what was blocking the original fetch.
Don't loading="lazy" the hero image. I see this mistake constantly because someone read "always lazy-load images" on a generic web-perf post and applied it everywhere. Lazy on the hero means the browser waits until layout is computed before requesting it, which is exactly the opposite of what you want for LCP.

For everything below the fold — product cards, secondary images, anything that needs a scroll to be seen — loading="lazy" is correct, and the same srcset pattern still applies.

The hero image fix alone is usually worth 1-2 seconds on a poorly-optimized store. It is the single highest-ROI thing on this list.

CLS: the late-loaded review widget

CLS on Shopify is almost always one of two things: web fonts swapping in late and pushing text down, or a third-party widget (reviews, swatches, recommendations) injecting itself after the rest of the page has already painted.

Reviews are the worst offender. The big review apps have gotten better, but plenty of merchants still have a <div id="reviews-widget"></div> that loads via async JS, fetches reviews from an API, and then pops a 400px-tall block into the middle of the PDP about 1.5 seconds after first paint. That's a CLS catastrophe — sometimes 0.4 or higher, when the threshold for "good" is 0.1.

The fix is to reserve the space. Even if you don't know the exact height, a min-height is enough:

{% comment %} On the PDP template, above the reviews widget container {% endcomment %}
<div
  id="reviews-mount"
  style="min-height: 320px; contain: layout;"
  data-product-id="{{ product.id }}"
>
  {% comment %} The widget will hydrate into this. {% endcomment %}
</div>

contain: layout is underused. It tells the browser that whatever happens inside this element won't cause reflow outside of it, which is a useful hint when the widget injects content of unpredictable height. Combined with a min-height that's at least as tall as the average rendered widget, you eat the layout shift inside the container instead of pushing the rest of the page around.

The other CLS culprit is font-display: swap on a font that loads slowly. If you're using a custom font from a CDN, either preload it or switch to font-display: optional for non-critical text. Optional won't swap if the font hasn't arrived in time, which avoids the flash but means some users see the fallback font on first visit. That's almost always a better tradeoff than a CLS hit.

INP: the JS bundle problem

INP replaced FID in 2024 and it's a much harder metric to fake your way through. FID measured first input delay; INP measures the slowest interaction across the entire session. If your "Add to cart" button has a 400ms response time because some analytics script is blocking the main thread, INP catches it.

On Shopify, INP failures usually trace back to one of three things: a giant theme JS bundle that runs on every page, a tag manager firing 15 third-party scripts on page load, or a section that re-renders the entire DOM tree when a variant changes.

The variant-switcher one is fixable with the Shopify Section Rendering API, and it's underused. Most themes update variant info by scanning the DOM, swapping image src attributes, updating prices manually, and rebinding event listeners. That works, but it gets slow once you have variant images, swatches, and a dynamic "X people are viewing this" widget all reacting to the change.

The cleaner pattern: hit the section endpoint and replace the whole section's HTML with the server-rendered version.

async function updateVariantSection(variantId, sectionId) {
  const url = new URL(window.location.href);
  url.searchParams.set('variant', variantId);
  url.searchParams.set('section_id', sectionId);

  const response = await fetch(url.toString(), {
    headers: { 'Accept': 'text/html' }
  });

  if (!response.ok) return;

  const html = await response.text();
  const parser = new DOMParser();
  const doc = parser.parseFromString(html, 'text/html');
  const newSection = doc.querySelector(`#shopify-section-${sectionId}`);
  const oldSection = document.querySelector(`#shopify-section-${sectionId}`);

  if (newSection && oldSection) {
    oldSection.replaceWith(newSection);
  }
}

You hand off the rendering to Shopify's edge, which is fast, and you avoid running a bunch of client-side template logic that was the actual source of the INP issue. The first time I rewrote a "related products" carousel this way, the INP on that PDP came down from "needs improvement" range into "good" — and the carousel itself didn't get any faster. I just stopped doing work on the main thread.

The other INP move worth mentioning is breaking up long tasks with scheduler.yield() where it's available, falling back to a setTimeout(fn, 0). If you have an init function that's doing 200ms of synchronous work on page load, that 200ms is going to show up in INP if the user clicks anything during it. Yielding lets the browser process input in between.

The prefetch tactic — what it actually does

Once the page itself is fast, the next bottleneck is the navigation between pages. That's where <link rel="prefetch"> earns its keep on Shopify, because the typical session involves 3-5 product page views, and each one is a fresh round-trip.

The idea is simple: when a user hovers over a product link (or starts a touch on mobile), there's a delay of around 100-300ms before they actually click. That window is enough to fetch the next page's HTML in the background. By the time they actually click, the page is already in the browser cache and the navigation feels instant.

const prefetched = new Set();

function prefetch(href) {
  if (prefetched.has(href)) return;
  prefetched.add(href);

  const link = document.createElement('link');
  link.rel = 'prefetch';
  link.href = href;
  link.as = 'document';
  document.head.appendChild(link);
}

function shouldPrefetch(href) {
  // Only same-origin, only product/collection routes,
  // skip if user has data-saver on or is on slow connection
  try {
    const url = new URL(href, window.location.origin);
    if (url.origin !== window.location.origin) return false;
    if (!/^\/(products|collections)\//.test(url.pathname)) return false;
  } catch { return false; }

  const conn = navigator.connection;
  if (conn?.saveData) return false;
  if (conn?.effectiveType && /2g|slow-2g/.test(conn.effectiveType)) return false;

  return true;
}

document.addEventListener('mouseover', (e) => {
  const link = e.target.closest('a[href]');
  if (link && shouldPrefetch(link.href)) prefetch(link.href);
}, { passive: true });

document.addEventListener('touchstart', (e) => {
  const link = e.target.closest('a[href]');
  if (link && shouldPrefetch(link.href)) prefetch(link.href);
}, { passive: true });

There are three things to be careful about:

Bots and crawlers. Googlebot doesn't hover, but plenty of crawlers fire synthetic mouseover events, and you don't want to waste merchant bandwidth prefetching pages for a scraper. Gating on navigator.connection filters most of them out, but the more aggressive filter is to require an actual user gesture earlier in the session before enabling prefetch at all.
Route gating. Don't prefetch the cart, checkout, or account pages. They're personalized, often uncacheable, and prefetching them wastes the round-trip. Restrict to product and collection routes where the response is cacheable.
The hover trigger doesn't fire on mobile. That's why you also bind to touchstart — it gives you a similar window between the touch and the click, usually around 80-150ms, which is enough to start a fetch.

The upgrade path: Speculation Rules

<link rel="prefetch"> is the universally-supported floor. The ceiling is the Speculation Rules API, which Chrome 108+ and Edge 108+ support. Instead of just downloading the next page's HTML, Speculation Rules can fully prerender the destination — execute the JS, build the DOM, run client-side hydration — all in a hidden tab. When the user clicks, the prerendered page swaps in instantly with zero round-trip. It's the closest thing the web has to instant navigation.

const rules = {
  prerender: [{
    source: 'document',
    where: {
      and: [
        { href_matches: '/products/*' },
        { not: { href_matches: '/cart*' } },
        { not: { href_matches: '/checkout*' } },
        { not: { href_matches: '/account*' } }
      ]
    },
    eagerness: 'conservative'
  }]
};

const script = document.createElement('script');
script.type = 'speculationrules';
script.textContent = JSON.stringify(rules);
document.head.appendChild(script);

The browser handles eviction, throttling, memory limits, and bot filtering — you just declare the rules. Eagerness conservative waits for hover/touch (similar to the manual prefetch above); moderate triggers a bit earlier; eager is for high-confidence next-page predictions. On a typical PDP, conservative is the right default.

For non-Chrome browsers — Safari mobile is the big one — fall back to the manual <link rel="prefetch"> approach. A real-world implementation runs both: Speculation Rules where supported, manual prefetch as the floor. That covers ~95% of e-commerce traffic.

The cumulative effect is that subsequent navigations on the store feel instant. Not "fast" — instant. It's the difference between a native app feeling and a web feeling. Whether it shows up in your CWV numbers depends on whether the prefetched page becomes the navigation that's measured (it sometimes does, via the Navigation Timing API reporting on bfcache and prefetch-served loads), but even when it doesn't, the perceived speed is meaningfully different.

What I learned shipping this

A few things that surprised me when I started seeing real merchant data:

The biggest CWV problems on most stores are introduced by apps the merchant installed, not by the theme. A store can have a beautifully optimized base theme and still score 30 on Performance because they've got six apps injecting scripts into the head, two of which are render-blocking. The merchant has no idea, because none of those apps say "this will tank your LCP" in their listing.

Speed wins compound. The merchants who fix LCP and then stop usually see a small lift. The ones who fix LCP, then CLS, then INP, then add prefetch end up with a store that feels different to use, and that's where the real conversion gains show up. Each individual fix moves the needle a little; the combination changes the user's perception of the brand.

And the prefetch tactic in particular is one of those things that's hard to A/B test cleanly, because the metric you're trying to improve (perceived navigation speed) doesn't show up in standard analytics. The signals I've seen — pages-per-session creeping up, bounce rate dropping on entry pages — are circumstantial but consistent.

Disclosure: I built and ship a Shopify app called Prefetch that bundles the scanner (PageSpeed Insights against the merchant's own storefront, surfaced in the admin dashboard) and the prefetch logic (Speculation Rules where supported, manual <link rel="prefetch"> as the floor). I mention it once, here, for transparency — none of the fixes above require an app, and the rest of this article works whether you install it or not.

The Liquid pattern, the CLS reservation, the Section Rendering API call — all of that is core Shopify, and any developer can ship it on a Friday afternoon. If you do nothing else after reading this, fix your hero image. It's the highest-ROI hour of work most stores have on the table.

Embedding a WordPress blog inside Shopify: 3 approaches I've actually shipped

Peter Hallander — Wed, 06 May 2026 18:24:00 +0000

Embedding a WordPress blog inside Shopify: 3 approaches I've actually shipped

If you've worked on a Shopify storefront for any merchant who takes content seriously, you've hit this wall. The merchant runs a WordPress blog (because Yoast, Rank Math, ACF, and the editor experience are still better than Shopify Blogs in 2026), but the marketing team wants the posts to render inside the storefront, on store.com/blog, in the same theme, with the same nav, the same footer, the same cart drawer.

The naive options all break something. Migrate everything to Shopify and you lose the WP plugin ecosystem and bleed redirect equity for months. Drop an <iframe> and Google won't index it, the layout breaks on mobile, and your Core Web Vitals tank. Copy-paste posts manually and you're maintaining two CMSs by hand.

I've shipped all three of the patterns below for client stores and for my own apps. Here's what each one actually involves, what breaks, and when to pick which.

Approach 1: Migrate WordPress content to Shopify Blogs

The "just consolidate" play. You export WP posts, import them as Shopify articles, set up 1:1 redirects, and decommission WP.

What it actually involves:

Export WP posts via WP REST API or WXR. The Shopify Articles API accepts HTML body, author, tags, image, published_at, so you can script the import in a few hundred lines of Node.
Build a redirect map. Every wordpress.example.com/2024/03/slug/ or example.com/blog/slug/ needs a 301 to example.com/blogs/news/slug. Shopify's Redirects API caps at 100k entries which is fine for most blogs, but you'll batch in 250s.
Resubmit the new sitemap to Search Console and request indexing on the top 50 URLs.
Rewrite internal anchors. Old posts linked to other old posts; if you don't rewrite those anchors during import, every internal link is now a 301 hop.

// redirect map sample (Node, Shopify Admin GraphQL)
const redirects = wpPosts.map(p => ({
  path: new URL(p.link).pathname,           // /2024/03/some-slug/
  target: `/blogs/news/${p.slug}`,
}));

for (const batch of chunk(redirects, 250)) {
  await admin.graphql(URL_REDIRECT_BULK_CREATE, { input: batch });
}

Pros: one CMS, one domain, no third-party dependency, no proxy to maintain. Editors stop asking "which login do I use again?"

Cons: you lose the WP plugin ecosystem (Yoast schema, ACF flexible content, custom post types). The Shopify article editor is genuinely worse for long-form. Redirect chains accumulate if the blog has ever moved before. Duplicate-content risk lingers for weeks while Google reconciles the old WP URLs that are still cached.

Pick this when: the blog is small (under ~200 posts), the team is already tired of maintaining WP, and the content is mostly product-adjacent (buying guides, how-tos) rather than long-form journalism that depends on WP-specific plugins.

Approach 2: Reverse proxy WordPress at /blog

Keep WP exactly where it is. Serve it under the Shopify domain via a reverse proxy so store.com/blog/* is actually WordPress, while everything else is Shopify.

The cleanest way I've shipped this is a Cloudflare Worker sitting in front of the apex domain.

// Cloudflare Worker: route /blog/* to WP, everything else to Shopify
export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname.startsWith('/blog')) {
      const wpUrl = new URL(url.pathname + url.search, 'https://wp-origin.example.com');
      const wpRes = await fetch(wpUrl, {
        method: request.method,
        headers: request.headers,
        body: request.body,
      });
      // rewrite absolute WP origin URLs in the response body
      const html = await wpRes.text();
      const rewritten = html.replaceAll('https://wp-origin.example.com', 'https://store.example.com');
      return new Response(rewritten, {
        status: wpRes.status,
        headers: wpRes.headers,
      });
    }

    return fetch(`https://store.example.com${url.pathname}${url.search}`, request);
  },
};

Pros: the cleanest SEO story by far. Canonicals stay on WP, all the schema and meta tags Yoast generates are preserved, no migration, no duplicate content. From Google's perspective store.com/blog/post-slug is one URL with one canonical. Nothing has moved.

Cons: two systems to keep alive forever. You need to match the WP theme's header/footer to the Shopify theme manually (or pull the Shopify header HTML into a WP template). The Worker is a paid hop on every blog request. Some Shopify Plus reverse-proxy patterns exist as alternatives but they're locked behind the Plus plan. You'll also debug "why is this asset 404ing" more than you'd like.

Pick this when: organic traffic to the blog dwarfs everything else and migrating risks real revenue. Big content sites with hundreds of ranking posts. Or when the editorial team is non-negotiable about WordPress.

Approach 3: Embed posts via the WP REST API (the WP Feed pattern)

Don't migrate, don't proxy. Just fetch posts from wp.example.com/wp-json/wp/v2/posts and render them inside Shopify Liquid sections. Both CMSs stay independent. The Shopify storefront pulls a feed when needed.

Here's the DIY path. A Liquid section that fetches on the client and renders into the page:

{% comment %} sections/wp-feed.liquid {% endcomment %}
<div id="wp-feed" data-wp-endpoint="https://wp.example.com/wp-json/wp/v2/posts?_embed&per_page=6">
  <h2>{{ section.settings.heading }}</h2>
  <ul class="wp-feed__list"></ul>
</div>

<script>
  (async () => {
    const root = document.getElementById('wp-feed');
    const res = await fetch(root.dataset.wpEndpoint);
    const posts = await res.json();
    const list = root.querySelector('.wp-feed__list');
    list.innerHTML = posts.map(p => `
      <li>
        <a href="${p.link}">
          <img src="${p._embedded?.['wp:featuredmedia']?.[0]?.source_url ?? ''}" alt="" loading="lazy">
          <h3>${p.title.rendered}</h3>
          <p>${p.excerpt.rendered}</p>
        </a>
      </li>
    `).join('');
  })();
</script>

That works. Six posts render. You can ship it in an afternoon.

What it doesn't give you: caching (every storefront visitor hits your WP origin, which will fall over on a sale day), JSON-LD BlogPosting schema for the embedded posts, tag/category filtering, fallback for when WP is down, or a way to render posts on a static-rendered page that gets indexed properly. Each of those is a half-day of work and a thing to maintain.

I made WP Feed (a Shopify app for this exact pattern), so I'm biased. Sharing the technical reasoning anyway because the architecture works whether you use my app or build your own. The productized version handles the caching layer, emits JSON-LD per post, supports filtering by tag or category or slug, and degrades gracefully when WP is down. The DIY snippet above is fine for a single section on a single page; once you want it across a storefront with proper SEO you start rebuilding what's already there.

One thing worth getting right either way: if you embed WP post content (not just titles and excerpts) inline on a Shopify URL, set <link rel="canonical"> on the rendering page back to the WP post. Otherwise you're competing with yourself in search.

Pros: zero migration, fast to ship, both CMSs stay independent, no proxy infrastructure, editors keep using WP normally.

Cons: dependency on WP origin uptime (cache aggressively), canonical setup matters or you'll cannibalize your own rankings, third-party app if you go productized.

Pick this when: you want a few recent posts on the homepage, a blog landing section, or a "related reads" block on product pages, but you're not trying to make store.com/blog itself become WordPress.

Decision matrix

Situation	Approach
Bulk of organic traffic lives on the WP blog	Reverse proxy (Approach 2)
Phasing out WP, small post count, team wants one CMS	Migrate (Approach 1)
Just want recent posts visible on Shopify pages	Embed via REST API (Approach 3)
Editorial team won't give up WP plugins, but blog isn't huge yet	Reverse proxy or embed depending on traffic mix
Bootstrapped, no Plus plan, no Cloudflare budget	Embed via REST API
Compliance / legal needs single-domain audit trail	Migrate

If the blog is the SEO engine, don't move it. If the blog is a content surface that supports the store, embed it. Migration is the right answer less often than people assume, but when it's right it's very right.

What's not in scope

Full headless setups (Hydrogen, Next.js Commerce) where Shopify is the data source and a JS framework is the renderer are a different conversation. So is using a third-party CMS like Contentful or Sanity as the source of truth and dual-publishing to both Shopify and WP. Both are valid, both are bigger commitments than what's above.

Questions on any of the three patterns, or edge cases I missed, drop them in the comments.

Peter Hållander makes Shopify apps at Stackedboost. WP Feed, Better Related Blog Posts, Eye Catching, Prefetch.

Embedding a WordPress blog inside Shopify: 3 approaches I've actually shipped

Peter Hallander — Wed, 06 May 2026 18:18:08 +0000

Embedding a WordPress blog inside Shopify: 3 approaches I've actually shipped

I've shipped all three of the patterns below for client stores and for my own apps. Here's what each one actually involves, what breaks, and when to pick which.

Approach 1: Migrate WordPress content to Shopify Blogs

The "just consolidate" play. You export WP posts, import them as Shopify articles, set up 1:1 redirects, and decommission WP.

What it actually involves:

Export WP posts via WP REST API or WXR. The Shopify Articles API accepts HTML body, author, tags, image, published_at, so you can script the import in a few hundred lines of Node.
Build a redirect map. Every wordpress.example.com/2024/03/slug/ or example.com/blog/slug/ needs a 301 to example.com/blogs/news/slug. Shopify's Redirects API caps at 100k entries which is fine for most blogs, but you'll batch in 250s.
Resubmit the new sitemap to Search Console and request indexing on the top 50 URLs.
Rewrite internal anchors. Old posts linked to other old posts; if you don't rewrite those anchors during import, every internal link is now a 301 hop.

// redirect map sample (Node, Shopify Admin GraphQL)
const redirects = wpPosts.map(p => ({
  path: new URL(p.link).pathname,           // /2024/03/some-slug/
  target: `/blogs/news/${p.slug}`,
}));

for (const batch of chunk(redirects, 250)) {
  await admin.graphql(URL_REDIRECT_BULK_CREATE, { input: batch });
}

Pros: one CMS, one domain, no third-party dependency, no proxy to maintain. Editors stop asking "which login do I use again?"

Approach 2: Reverse proxy WordPress at /blog

Keep WP exactly where it is. Serve it under the Shopify domain via a reverse proxy so store.com/blog/* is actually WordPress, while everything else is Shopify.

The cleanest way I've shipped this is a Cloudflare Worker sitting in front of the apex domain.

// Cloudflare Worker: route /blog/* to WP, everything else to Shopify
export default {
  async fetch(request) {
    const url = new URL(request.url);

    if (url.pathname.startsWith('/blog')) {
      const wpUrl = new URL(url.pathname + url.search, 'https://wp-origin.example.com');
      const wpRes = await fetch(wpUrl, {
        method: request.method,
        headers: request.headers,
        body: request.body,
      });
      // rewrite absolute WP origin URLs in the response body
      const html = await wpRes.text();
      const rewritten = html.replaceAll('https://wp-origin.example.com', 'https://store.example.com');
      return new Response(rewritten, {
        status: wpRes.status,
        headers: wpRes.headers,
      });
    }

    return fetch(`https://store.example.com${url.pathname}${url.search}`, request);
  },
};

Approach 3: Embed posts via the WP REST API (the WP Feed pattern)

Here's the DIY path. A Liquid section that fetches on the client and renders into the page:

{% comment %} sections/wp-feed.liquid {% endcomment %}
<div id="wp-feed" data-wp-endpoint="https://wp.example.com/wp-json/wp/v2/posts?_embed&per_page=6">
  <h2>{{ section.settings.heading }}</h2>
  <ul class="wp-feed__list"></ul>
</div>

<script>
  (async () => {
    const root = document.getElementById('wp-feed');
    const res = await fetch(root.dataset.wpEndpoint);
    const posts = await res.json();
    const list = root.querySelector('.wp-feed__list');
    list.innerHTML = posts.map(p => `
      <li>
        <a href="${p.link}">
          <img src="${p._embedded?.['wp:featuredmedia']?.[0]?.source_url ?? ''}" alt="" loading="lazy">
          <h3>${p.title.rendered}</h3>
          <p>${p.excerpt.rendered}</p>
        </a>
      </li>
    `).join('');
  })();
</script>

That works. Six posts render. You can ship it in an afternoon.

Pros: zero migration, fast to ship, both CMSs stay independent, no proxy infrastructure, editors keep using WP normally.

Cons: dependency on WP origin uptime (cache aggressively), canonical setup matters or you'll cannibalize your own rankings, third-party app if you go productized.

Decision matrix

Situation	Approach
Bulk of organic traffic lives on the WP blog	Reverse proxy (Approach 2)
Phasing out WP, small post count, team wants one CMS	Migrate (Approach 1)
Just want recent posts visible on Shopify pages	Embed via REST API (Approach 3)
Editorial team won't give up WP plugins, but blog isn't huge yet	Reverse proxy or embed depending on traffic mix
Bootstrapped, no Plus plan, no Cloudflare budget	Embed via REST API
Compliance / legal needs single-domain audit trail	Migrate

What's not in scope

Questions on any of the three patterns, or edge cases I missed, drop them in the comments.

Peter Hållander makes Shopify apps at Stackedboost. WP Feed, Better Related Blog Posts, Eye Catching, Prefetch.

How Polish Accounting Firms Are Managing KSeF Tokens for 50+ Clients at Once

Peter Hallander — Mon, 27 Apr 2026 10:29:17 +0000

If you run an accounting firm in Poland, the past year has meant one thing above everything else: KSeF. The National e-Invoice System (Krajowy System e-Faktur) has dominated compliance conversations for months, and for good reason. But most of the public discussion focuses on the invoice format itself. What gets far less attention is the authentication layer, and that is where the real operational headache lives.

One Token Per Client, Multiplied by 50

KSeF uses a token-based authorization model. Each company registered in the system can generate API tokens that allow authorized software to send and receive invoices on its behalf. Simple enough in theory. In practice, when you are a bookkeeper managing the finances of 50, 80, or 150 businesses, you suddenly have 50 to 150 separate tokens to generate, store, rotate, and track.

Each token is tied to a specific NIP (Polish tax identification number). Each one has its own permissions scope, its own expiration window, and its own generation date. If a token gets revoked, the connected software stops working silently. If you store tokens in a shared spreadsheet and someone leaves the company, that spreadsheet is now a security liability. And if a client asks you to revoke their access immediately, you need to find the right token fast, not scroll through rows in a Google Sheet under pressure.

This is not a hypothetical. It is the daily reality for hundreds of Polish accounting offices right now.

What KSeF Actually Requires Under the Hood

KSeF authentication works through the Ministry of Finance API. You can find the full technical terminology explained in the KSeF glossary, but the short version is this: to interact with the system on behalf of a taxpayer, your software needs a valid session token. To get a session token, you first need an authorization token that was granted by that taxpayer.

The authorization token is generated in the KSeF production environment by the company's NIP holder, or someone they explicitly delegate. Once you have it, you use it to open sessions and send or receive invoices. The token does not expire on a fixed schedule, but it can be revoked by the client at any time, and it is specific to the NIP it was issued for.

The technical flow is straightforward for a single client. Multiply it across dozens of clients, with different delegation setups, different software configurations, and different client expectations for how often credentials should rotate, and the complexity becomes real.

How Firms Are Actually Handling This

From conversations with accountants working in this space, there are roughly three approaches in active use right now.

The first is a spreadsheet or text document. It works, technically. Firms list client NIP, token value, date of generation, who generated it, and maybe a rotation reminder. This approach is fine for five clients. At thirty it becomes fragile. At eighty it is a genuine liability, both operationally and from a data security standpoint.

The second approach involves password managers like 1Password or Bitwarden. Better than a spreadsheet for security, but these tools were not designed for structured credential management across dozens of businesses with context-specific fields. You end up with messy folder structures and no way to see at a glance which tokens are stale, which clients have not yet delegated access, or whether a token belongs to the production environment versus test.

The third approach, where firms with larger client books are moving, is dedicated tooling. The idea is simple: a system that stores KSeF tokens alongside client NIP data, tracks their status, and integrates directly with the invoicing workflow. No copy-pasting between a credential vault and an invoicing app. No switching tabs to check whether a token is still valid before sending a batch of invoices.

This operational challenge is exactly what shaped the design of FakturaFlow. The platform was built from the start for accounting firms handling KSeF access for multiple clients, with token management treated as a core part of the data model rather than bolted on afterward. When you are sending invoices for forty clients in a single morning, the token is not a side detail, it is part of the critical path.

The Pattern That Keeps Emerging

The firms that struggle most with KSeF are not struggling with the invoice format. The XML schema, the mandatory fields, the FA namespace, those are learnable problems. The struggle is operational: credentials, delegation chains, permissions, client communication about access, and what happens when a token breaks something at 4pm on a Friday.

The firms handling it smoothly have made a deliberate choice about where token data lives and how that storage connects to their daily invoicing work. That choice is worth making explicitly, before something breaks at an inconvenient moment.

If you are managing KSeF access for a larger client book, how are you currently handling token storage and rotation? Spreadsheet, password manager, custom solution, or something else entirely?

I built a Shopify app that makes stores feel instant using link prefetching

Peter Hallander — Wed, 22 Apr 2026 08:43:30 +0000

I've been building small Shopify apps as side projects for a while, and one thing that's always bugged me about Shopify stores is the noticeable page load delay when navigating between products and pages.

You click a link, and there's a brief but annoying pause before anything happens. It's not catastrophic, but that friction adds up — especially on mobile connections. I decided to fix it.

The idea: prefetch on hover

The fix is conceptually simple. When a user hovers over a link, there's roughly a 200–400ms window before they actually click. That's enough time to start loading the destination page in the background, so by the time they click, the page is already partially (or fully) loaded.

This technique is called link prefetching, and libraries like instant.page and quicklink have been doing it on general websites for years. But for Shopify specifically, there was no dead-simple plug-and-play solution that works within the app ecosystem constraints. So I built one: Prefetch for Shopify.

How it works technically

Prefetch injects a small script (~2KB gzipped) into your storefront that listens for hover events and fires prefetch requests using <link rel="prefetch">.

A few nuances worth sharing:

1. Debouncing hover intent

We don't prefetch on every fleeting mouseover — that would waste bandwidth and fire constantly as users scan a page. Instead, we use a ~65ms delay to detect genuine hover intent. Fast accidental mouse movements don't count.

link.addEventListener('mouseover', () => {
  hoverTimer = setTimeout(() => prefetch(link.href), 65);
});
link.addEventListener('mouseout', () => clearTimeout(hoverTimer));

2. Network-aware prefetching

On slow connections (2G/slow-3G), prefetching is a net negative — it would consume the limited bandwidth users need for the actual page they're on. The script checks navigator.connection.effectiveType and disables itself on slow connections automatically.

const conn = navigator.connection;
if (conn && (conn.saveData || /2g/.test(conn.effectiveType))) return;

3. Only prefetch what matters

We limit prefetching to internal store links (same origin only), skip already-cached URLs, skip checkout/cart links, and skip static resource files. Only navigational page links get prefetched — which is what actually benefits the user.

4. Mobile: touchstart instead of mouseover

On mobile there's no hover, so we listen for touchstart instead. The moment a finger touches a link, we fire the prefetch. Given that touch-to-tap typically takes 80–150ms, this gives us a meaningful head start.

The result

In testing across several stores, this shaves 200–400ms off perceived navigation time. Google's research puts 100ms as the threshold humans perceive as "instant" — we're not magic, but closing the gap noticeably improves how snappy a store feels.

The Shopify constraint challenge

Building for Shopify is interesting because you can't modify the theme directly from an app — everything has to be injected via script tags through the App Bridge / ScriptTag API. That forced me to keep the implementation entirely self-contained with zero dependencies, no global namespace pollution, and graceful degradation if the browser doesn't support the Prefetch API.

The hardest design decision was figuring out when not to prefetch. Being too aggressive causes a spike in server requests and bandwidth consumption that can hurt slow-connection users. The threshold tuning (65ms delay, connection checks, same-origin filtering) took the most iteration.

Try it

If you run a Shopify store and care about performance, the app is free to install: Prefetch on the Shopify App Store

Happy to answer any technical questions in the comments — particularly around the Shopify scripting constraints or the prefetch threshold tuning.