WooCommerce at TikTok Speed: The React Island Landing Technique

Ever watched a teenager doomscroll through TikTok? Thumb-flick, half a second to decide, scroll, next video. That’s how attention works now — and when I had to launch a paid campaign on the most frenetic social platform out there, the number-one problem was immediately obvious.

When boredom kicks in after half a second, the gap between clicking an ad and seeing a page is the difference between a view and a request that gets closed before it ever renders. This was especially critical for my colorful USB cables — they’re literally built for the Instagram and TikTok crowd. I couldn’t afford to lose people on the first step.

My solution: hybrid React landing pages that lean on WooCommerce for the data but completely skip its HTML output. Near-instant response, swipe-based navigation made for the swipe-or-skip generation.

The problem: WooCommerce is complete, but large

WooCommerce is a fantastic platform, but it builds every product page through dozens of hooks, filters, database queries, template lookups, and dynamically enqueued assets. For an ad-driven landing page, almost none of that is needed: I want to show one photo, one price, one buy button. And I want it in half a second.

Conventional fixes — aggressive caching, optimization, speed plugins — only get you so far. The limit is structural: every byte of HTML, CSS, and JavaScript WordPress pushes into the page delays first paint.

The React Island architecture

The approach I went with is the island architecture pattern: a minimal, static HTML page with a small JavaScript “island” handling interactivity. No jQuery, no WooCommerce frontend, no theme. A custom PHP template that returns exactly this:

<!DOCTYPE html>
<html>
  <head>
    <style>/* minimal reset + inline font */</style>
    <link rel="preload" href="hero.webp" as="image">
    <link rel="stylesheet" href="landing.css">
  </head>
  <body>
    <main id="lp-root"><!-- static skeleton --></main>
    <script>window.__LP_DATA__ = { /* product data as JSON */ }</script>
    <script defer src="landing.js"></script>
  </body>
</html>

The PHP template queries WooCommerce exactly once to pull the product data (name, price, variants, images, sale end date) and serializes it as inline JSON. React (actually Preact — 8KB gzipped instead of 40) picks up that data already sitting in memory and paints the UI. Zero AJAX calls during page load. The only fetch happens when the user taps “Add to cart”: a POST to the WooCommerce REST endpoint, then a redirect to checkout.

The whole JavaScript bundle weighs in at about 25KB gzipped. Rendering is essentially instant.

Two flavors: single product and card set

The landings come in two shapes.

Single product — a page dedicated to one product, with a swipeable image gallery, variant selector (color, length), sale countdown, and buy button. Perfect for single-product campaigns.

Card set — multiple products stacked like a deck, navigated with horizontal swipes (the same gesture the Tinder generation performs by reflex). Each card is a self-contained mini-landing: photo, price, variants, CTA. On the first card, an animated finger slides left for two seconds to hint at the gesture, for anyone who somehow hasn’t internalized it yet. Then it disappears forever.

The swipe is powered by scroll-snap-type: x mandatory — native, browser-driven, zero JavaScript libraries. On Android and iOS it feels as smooth as a native app.

The gotchas that cost me hours

Three things worth flagging, because anyone trying to replicate this architecture will hit them.

WooCommerce taxonomy attributes — product variations return their attribute keys with an attribute_ prefix (e.g. attribute_pa_color), while the parent product returns them without. Without a PHP normalization step that strips the prefix, the JavaScript matching between user selection and available variant silently fails every single time. Three days to figure that out.
CSS touch-action — the W3C spec computes it as an intersection along the DOM chain. Setting pan-x on a parent and pan-y on a child doesn’t give you “both directions”: it gives you neither. The correct setup is pan-x pan-y on the swiper, letting the browser disambiguate based on the actual gesture.
mix-blend-mode and stacking context — putting z-index on the container creates a new isolated stacking context, and blend mode can only see content inside that context. I wanted a colored trail that stayed visible on any background: mix-blend-mode: difference was the right tool, but with the z-index isolation it produced nothing. Fix: layer by DOM order (later = on top), no z-index needed.

Results

Google PageSpeed Insights, mobile:

Performance: 96/100
First Contentful Paint: 0.9s
Largest Contentful Paint: 2.4s
Cumulative Layout Shift: 0
Total Blocking Time: 150ms

The user sees the product before their thumb has finished leaving the screen. The attention-span problem, at least for a few seconds, stops being a problem.

The technique is portable to any WordPress + WooCommerce install. If you want to see it live, here’s one of the card landings. If you’re considering something similar for your own store, drop me a line.