DEV Community: Aakanksha Sharma

What Performance Really Means in Modern Storefronts (It is Not Just API Speed)

Aakanksha Sharma — Wed, 18 Jun 2025 07:09:33 +0000

Most frontend performance posts obsess over one thing: API latency.

Sure, shaving 200ms off a query helps. But storefronts often break not because of one slow API, but because of everything that happens after the data arrives:

Bloated JS delaying interactivity
Hydration blocking TTI
Redundant render logic on both client and server
Overfetching wrecking mobile performance

The bigger the catalog or checkout flow, the harder these bottlenecks tend to hit.

Let’s break down where performance gets lost and how we handle it across Shopify Hydrogen, Adobe PWA Studio, and headless platforms.

1. The real bottleneck is often hydration, not data

Most Hydrogen and Adobe PWA setups fetch product data in 300-400ms. But the page still takes 3-4s to become interactive.

Because the data gets serialized, passed to the client, then rehydrated with an entire JS bundle before anything is usable.

In Hydrogen-specific context: React Server Components reduce client JS, but hydration delays still apply for components wrapped in useEffect, client-rendered modals, and A/B test logic. Without careful boundary setting, RSC may not fully address TTI issues.

We split high-interaction components, like swatches, variant selectors, and promo modules, into isolated render islands.

In Hydrogen, that means server-only components where possible.

In Adobe PWA, we edge-cache UI shells and hydrate only what’s needed post-paint.

2. Client JS is heavier than most teams realize

Design updates often add 300-500KB of JavaScript. A/B tests re-import the same libraries. And it is not just third-party scripts. Internal A/B tests re-import the same component logic. Some Adobe builds I’ve seen still load Knockout alongside React because no one had time to rip it out.

We treat JS like a liability. Defer whatever doesn’t need to block paint.

Run a bundle audit every release. Flag anything that crosses 2MB. The bundle analysis consistently reveals bloat that impacts performance. If it's oversized, someone’s future LCP score is likely to suffer.

A 2.5MB payload may feel fine on a MacBook. But on a midrange Android over 4G in a crowded network zone? That’s often where your cart abandonment happens.

3. SSR ≠ fast if you don’t cache strategically

Server-side rendering is only fast when you cache pages smartly. But e-commerce builds often have:

Personalization rules (e.g., geo-based banners)
Variant stock logic
Cart preview hydration

In Hydrogen edge functions help, but you still need to isolate session-agnostic parts.

In Adobe, Varnish helps cache base layouts, but personalization modules often get excluded due to cookie or session reliance.

So, we precompute shared layout shells, cache edge-safe UI fragments, and defer everything else. Example: PDP renders instantly; restock prompts and add-to-cart logic hydrate later.

4. Observability is not optional

Slow is okay if you know where. What's challenging is operating blind.

We log hydration spans, collect client timing data, and trace key flow steps (PDP → ATC → Checkout). This helps spot regressions before your Lighthouse score dips or bounce rates spike.

One last thing -

Performance goes way beyond single metrics - it's how your entire system behaves.

The best storefronts tend to be not just fast-loading; but predictable. You know the rendering will be smooth, interactions will respond consistently, and when something breaks, recovery happens gracefully. That's what we aim for.

PS: If you're dealing with similar performance challenges, I'd love to hear about your experiences and approaches in the comments.

The React and JS Patterns That Keep Us Sane (and Shipping)

Aakanksha Sharma — Mon, 28 Apr 2025 10:02:42 +0000

📌 Note:

This post shares patterns and lessons pulled directly from our developers' experience building scalable storefronts.

When you see "I," it reflects real-world insights from the engineers behind these decisions.

E‑commerce at scale doesn’t fail because the code looks ugly.

It fails when a five‑second page tanks revenue, a silent error wipes out uptime, or a single developer holds the only GraphQL map.

That’s why predictability outranks prettiness. Four facts from the last year to frame the patterns that follow:

Speed is cash. Pages that load in ≤1s convert 2.5‑3× better than 5‑second pages, so I isolate heavy UI logic off the main thread and lean on edge rendering.
Observability moves the needle. Teams with full‑stack telemetry are 51 % more likely to improve uptime and 44 % more likely to boost efficiency., so I bake in proxy wrappers and tracing hooks from day one.
Static contracts won. TypeScript is now GitHub’s #3 language, behind only Python and JavaScript. So I ship every pattern with typed interfaces to prevent “works‑on‑my‑machine” refactors.
Testing is still a blind spot. Roughly 13 % of JS devs use no test framework at work (State of JS 2024), so I fail CI if unit‑test coverage dips below 90 %.

JavaScript Patterns That Actually Scale

A PDP in one market may show a single SKU; in another, a subscription bundle with region‑specific tax rules. When product shapes diverge this fast, patterns are the only way to keep the codebase predictable.

With those stakes set, here are the React & JS patterns that buy us predictability -

1. Factory Pattern

When to reach for it:

SKU shapes vary by market, channel, or fulfilment method.
You need to expose a single cart interface while the back‑end business logic mutates.

When to avoid:

Only one immutable product type exists (KISS beats abstraction).

// Core Factory example: illustrates the “simple” branch; other branches follow the same pattern


type ProductShape = 

  | { kind: 'simple'; name: string; price: number } 

  | { kind: 'subscription'; name: string; monthlyPrice: number; duration: number } 

  | { kind: 'bundle'; name: string; items: { price: number }[]; discountRate?: number }; 


export function productFactory(data: ProductShape) { 

  if (data.kind === 'simple') { 

    return { ...data, total: data.price }; 

  } 

  // subscription & bundle logic implemented similarly 

}

Why it matters:

KPI	Impact
Cart uptime when adding new product types	Interface stays constant → < 1 % checkout errors during launches
Release velocity	Devs extend the switch block—not the UI—reducing PR churn
QA surface	Typed discriminated unions catch shape drift at compile time

2. Module Pattern

Use it for:

Tax currency, or promo logic that touches every page.
Shared utilities that must stay framework‑agnostic (SSR/edge safe).

// storefront/tax.ts 


export const taxRates = { US: 0.07, EU: 0.2 } as const; 

export function calcTax(amount: number, region: keyof typeof taxRates) { 

  return amount * (taxRates[region] ?? 0); 

}

Observability hook:

import { trace } from '@opentelemetry/api'; 


export function calcTaxTraced(amount: number, region: keyof typeof taxRates) { 

  return trace.getTracer('storefront').startActiveSpan('calcTax', span => { 

    const res = calcTax(amount, region); 

    span.end(); 

    return res; 

  }); 

}

Why it matters:

Think of this module as your single home for all tax and pricing rules—it runs exactly the same on the server, edge, or browser (no more “works in dev only” surprises). And because it’s all in one file, your finance or compliance team can sign off with a single diff instead of hunting through ten different PRs.

3. Proxy Pattern

Use it for:

Cross‑cutting concerns (rate‑limit, feature flags, telemetry) without touching call sites.
Gradual API deprecation—wrap the old SDK, add warnings, ship.

// inventoryProxy.ts 


import pRetry from 'p-retry'; 



const inventorySDK = { 

  check: (id: string) => fetch(`/api/inventory/${id}`).then(r => r.json()), 

}; 



export const inventory = new Proxy(inventorySDK, { 

  get(target, prop) { 

    if (prop === 'check') { 

      return async (productId: string) => { 

  return pRetry(() => target.check(productId), { retries: 2 }); 

      }; 

    } 

    // fallback to raw method 

    // @ts-ignore 

    return target[prop]; 

  }, 

});

Why it matters:
Because a Proxy wrapper gives you retries, logging, and feature‑flag hooks around every call—without ever touching your core logic.

I ended up making this decision cheat sheet, hope it helps -

Pattern	Ship if…	Skip if…
Factory	Product shapes proliferate	Single static SKU model
Module	Logic reused across views/runtime targets	Logic is truly page-local
Proxy	Need cross-cutting behavior w/ no consumer changes	Performance is ultra-critical and nanosecond proxy overhead matters

Patterns We Skip (99 % of the Time)

We embrace patterns that raise predictability and drop those that quietly erode it. Two common offenders:

Pattern	Why We Usually Pass	Acceptable Edge Case
Singleton	Global state hides complexity. In React + serverless stacks the same “singleton” can instantiate per lambda, breaking the very guarantee you wanted. It’s hard to unit-test, near-impossible to version, and leaks across feature flags.	A true infrastructure client that must share pooled resources—e.g., a Node database driver or Redis connection. Even then, wrap it behind an interface you can mock in tests.
Observer	Event chains look elegant until you’re spelunking a log at 2 a.m. wondering who fired what. Modern React already gives us deterministic data flow (state + effects), and scoped pub/sub libraries (e.g., mitt) keep responsibilities explicit.	High-frequency telemetry pipelines where decoupled consumers genuinely outnumber producers and you have distributed tracing in place. Even then, document every event contract like an API.

From Language Rules to Component Rules

(Now we are Shifting gears: JS → React)

We’ve just tightened the language‑level screws—factories, modules, proxies—so our business logic stays predictable no matter how many SKU shapes or tax rules get tossed at it.

But JavaScript patterns alone won’t stop a promo team, a personalization squad, and a cart‑experiment crew from tripping over each other in the React layer. UI state, render timing, and server/client boundaries introduce a new class of failure modes.

1. Custom Hooks Pattern

Use it when: Multiple components need identical business logic (e.g., delivery slots, promo eligibility).

Skip it when: Logic is purely UI‑side or single‑use.

// useDeliverySlots.ts 

import { useState, useEffect, useCallback } from 'react'; 



export function useDeliverySlots(productId: string | undefined, region: string) { 

  const [slots, setSlots] = useState<Date[]>([]); 

  const [loading, setLoading] = useState(true); 

  const [error, setError] = useState<string | null>(null); 



  useEffect(() => { 

    if (!productId) return; 

    setLoading(true); 



    fetch(`/api/delivery-slots?product=${productId}&region=${region}`) 

      .then(r => (r.ok ? r.json() : Promise.reject(r.status))) 

      .then(setSlots) 

      .catch(e => setError(String(e))) 

      .finally(() => setLoading(false)); 

  }, [productId, region]); 



  const sameDayEligible = useCallback( 

    () => slots.some(s => s.toDateString() === new Date().toDateString()), 

    [slots] 

  ); 



  return { slots, loading, error, sameDayEligible }; 

}

Why it matters: isolates business logic from rendering, slashes test time by 3×, and stays SSR‑safe.

2. Compound Component Pattern

Use it when: You need multi‑step, configurable UIs (e.g., product customizers).

Skip it when: Simple UI with minimal configuration or single render state is needed.

// Tabs.tsx 

import { 

  createContext, 

  useContext, 

  useState, 

  ReactNode, 

  useCallback, 

} from 'react'; 



type Ctx = { index: number; set: (i: number) => void }; 

const TabsCtx = createContext<Ctx | null>(null); 



export function Tabs({ 

  defaultIndex = 0, 

  onChange, 

  children, 

}: { 

  defaultIndex?: number; 

  onChange?: (i: number) => void; 

  children: ReactNode; 

}) { 

  const [index, setIndex] = useState(defaultIndex); 

  const update = useCallback( 

    (i: number) => { 

      setIndex(i); 

      onChange?.(i); 

    }, 

    [onChange] 

  ); 

  return ( 

    <TabsCtx.Provider value={{ index, set: update }}> 

      {children} 

    </TabsCtx.Provider> 

  ); 

} 

Tabs.List = ({ children }: { children: ReactNode }) => <div>{children}</div>; 

Tabs.Tab = ({ 

  i, 

  children, 

}: { 

  i: number; 

  children: ReactNode; 

}) => { 

  const ctx = useContext(TabsCtx)!; 

  return ( 

    <button 

      aria-selected={ctx.index === i} 

      onClick={() => ctx.set(i)} 

    > 

      {children} 

    </button> 

  ); 

}; 

Tabs.Panel = ({ i, children }: { i: number; children: ReactNode }) => { 

  const ctx = useContext(TabsCtx)!; 

  return ctx.index === i ? <div>{children}</div> : null; 

};

Why it matters:

Declarative API feels like HTML ⟶ faster onboarding.
No prop‑drilling; context stays private to Tabs, so bundle size is minimal.
Easy to slot A/B variants—wrap Tabs.Tab without touching internal state.

3. Provider Pattern (React Context API)

Use it when: You need global, low‑churn state (currency, auth) across layouts.
Skip it when: State is highly page‑specific—use a local hook instead.

/ CurrencyProvider.tsx 

import { 

  createContext, 

  useContext, 

  useState, 

  useEffect, 

  ReactNode, 

} from 'react'; 

type Rates = Record<string, number>; 

type Ctx = { 

  currency: string; 

  setCurrency: (c: string) => void; 

  convert: (val: number, to?: string) => number; 

}; 

const CurrencyCtx = createContext<Ctx | null>(null); 



export function CurrencyProvider({ children }: { children: ReactNode }) { 

  const [currency, setCurrency] = useState('USD'); 

  const [rates, setRates] = useState<Rates>({}); 



  useEffect(() => { 

    fetch(`/api/rates?base=${currency}`).then(r => 

      r.json().then((d: Rates) => setRates(d)) 

    ); 

  }, [currency]); 



  const convert = (val: number, to = currency) => 

    to === currency ? val : val * (rates[to] ?? 1); 



  return ( 

    <CurrencyCtx.Provider value={{ currency, setCurrency, convert }}> 

      {children} 

    </CurrencyCtx.Provider> 

  ); 

} 

export const useCurrency = () => { 

  const ctx = useContext(CurrencyCtx); 

  if (!ctx) throw new Error('useCurrency outside provider'); 

  return ctx; 

};

Why it matters:

Zero prop‑drilling across multi‑layout storefronts.
Only 3 × HTTP calls max (base currency change) versus per‑page fetch spam.
Throw‑if‑missing guard prevents silent provider mis‑config in tests.

NOTE : While Context is cleaner than prop drilling, it can trigger re-renders across the tree. For high-frequency updates, consider context splitting or state management libraries.

4. Container / Presentational Split

Use it when: You manage a shared component library with varying data.

Skip it when: Component is one‑off—co‑locate fetch + render.

// PromoTile.container.tsx 

import { useEffect, useState } from 'react'; 

import { PromoTile } from './PromoTile.view'; 

export function PromoTileContainer({ slot }: { slot: string }) { 

  const [promo, set] = useState<{ title: string } | null>(null); 

  useEffect(() => { 

    fetch(`/api/promos?slot=${slot}`) 

      .then(r => r.json()) 

      .then(set); 

  }, [slot]); 



  return <PromoTile promo={promo} />; 

} 

----------------------- 

// PromoTile.view.tsx 

export function PromoTile({ promo }: { promo: { title: string } | null }) { 

  if (!promo) return null; 

  return <div className="promo-tile">{promo.title}</div>; 

}

Why it matters:

UI teams A/B‑test layout without touching fetch code.
API migrations swap the container only; design tokens stay intact.
Cypress e2e tests stub API and snapshot the presentational component—no flaky mocks.

And like before, here is a decision cheat sheet for React patterns:

Pattern	Reach for it	Skip if…
Custom Hook	Logic reused across components	Single-use logic
Compound Component	Multi-step, configurable UI flow	Only one sub-component
Provider	Global, low-churn state	Highly page-specific data
Container / Presentational	Shared design, varying data	Component truly one-off

How We Choose Patterns (and When We Don’t)

Axis	Ship the pattern if…	Default to simpler code if…	“Go-to” patterns
Team Topology	≥ 2 squads touch the same feature or brand layer	A single, long-lived team owns it end-to-end	Compound Components; Container / Presentational
Codebase Footprint	Module lives in a monorepo, multi-tenant, or > 50 k LOC	App is < 10 k LOC or feature is truly isolated	Custom Hooks; Modules
Business Complexity	Logic changes per market, promo, or fulfilment rule	Single, static SKU & workflow	Factory; Module
Change Velocity	Weekly A/B tests, fast campaigns, or feature flags	Regulated workflows, quarterly release cadence	Proxy; Custom Hooks
Risk / Blast Radius	A bug here can halt checkout or settlement	Failure manifests as a cosmetic glitch	Add tracing hooks, typed APIs; else YAGNI

Litmus test we run on every PR

Will a junior dev grok ownership boundaries in < 30 seconds?
Can we unit‑test the business logic without rendering React?
Does rollback require touching more than one folder?

If any answer is “no,” we downgrade the abstraction—or scrap it.
The only non‑negotiable rule: If a pattern doesn’t cut complexity or blast‑radius, we don’t ship it.

(That’s the whole decision engine—everything else is commentary.)

Closing Thought

Patterns aren’t merit badges. They’re circuit‑breakers for future headaches.

Every abstraction in this post made it into our stack only after it saved an on‑call engineer, cut a rollback, or shaved build time. That’s the bar:

Does it shrink the blast radius when business logic pivots?
Can a new hire trace ownership in under a minute?
Will it still read clean at 3 a.m. when prod is on fire?

If the answer’s “yes,” we keep it; if not, we rip it out—even if it looked elegant in code review.

That’s the entire playbook. Use what buys you predictability, skip what doesn’t, and stay ruthless about revisiting the call as your team, codebase, and revenue targets grow.

Would love to hear what patterns you’ve leaned on—or skipped—and why. Drop a comment if you’ve got battle scars or lessons of your own.

What Makes Hyvä a Smarter Frontend Choice for Adobe Commerce

Aakanksha Sharma — Thu, 10 Apr 2025 16:45:37 +0000

Running a Magento store can feel like an uphill climb. The more features you add, the more your storefront starts to slow you down.

Slower load times. Outdated frontend workflows. Systems that don’t move at the pace your business needs. It’s costing customers, and conversions.

Hyvä isn’t a patch but a rethink. A faster, modern foundation that transforms how Magento storefronts perform and scale.

Here’s how it changes the game for merchants:

What actually sets Hyvä apart?

Magento’s challenge has never been potential. It’s always been the frontend friction that slows everything down. Slow doesn’t sell, and complexity doesn’t scale. Hyvä strips away the bloat and replaces it with a modern, lightweight architecture that’s fast, flexible, and easy to work with.

1. Speed that shows up in SEO, UX, and revenue

Hyvä brings page weight down to ~0.2 MB—Luma clocks in at over 1 MB. That alone cuts load times, bounce rates, and frustration. Over 50% of Hyvä stores hit Google’s Core Web Vitals benchmarks, compared to just 19% on Luma. It’s not just faster, it’s Google-fast. And it shows up in rankings, retention, and revenue.

2. Less tech debt, fewer headaches

Hyvä drops legacy tools like RequireJS and Knockout.js in favor of Alpine.js and clean templates. That means faster debugging, fewer breaking changes, and more time building instead of putting out fires.

3. Scales without starting from scratch

Hyvä’s modular setup makes it easier to grow. Whether you’re launching in new markets, managing multiple storefronts, or expecting traffic spikes, you can scale without redesigning your entire frontend. It flexes with the business—not against it.

Built to solve real merchant problems

In most Magento builds, two issues show up again and again:

• Misaligned workflows that slow teams down
• Check out delays that kill conversions

Hyvä tackles both—by design.

Let’s talk workflow first.

Dev, design, and content teams often end up working in silos, which adds friction at every stage. Hyvä cuts that down with customizable UI components that plug straight into Figma and Magento. You ship faster—and with fewer surprises in QA.

Then there’s checkout.
This is where most revenue leaks happen. Hyvä delivers 13x faster mobile load times, seamless navigation with Magewire, and built-in support for gateways like PayPal and Stripe. It’s fast where it counts, and frictionless when it matters most.

The tech behind Hyvä’s speed

Hyvä isn’t just another Magento theme but a full rethink of how the frontend works. But getting results still comes down to execution. Here’s what powers it under the hood:

1. Instant page loads with predictive navigation and SSR

Hyvä removes the usual lag with a combo of Predictive Navigation and Server-Side Rendering (SSR). Predictive Navigation preloads the next likely page before users click. SSR makes sure key data is ready the moment the page loads.

For B2B storefronts with large catalogs or bulk ordering, that means lightning-fast product navigation without sacrificing real-time inventory accuracy.

2. JavaScript that gets out of the way

Most themes load way too much JS by default. Hyvä doesn’t. It uses strategies like x-defer and conditional rendering to load only what’s needed, when it’s needed.

Dev-side bonus: with the hyva_themes.xml, you can control which scripts load where. Prioritize interactions on PDPs. Defer sliders on PLPs. No bloated bundles, no guesswork—just faster pages and smoother UX.

For high-traffic or high-SKU storefronts, that kind of control makes all the difference.

3. PWA-ready, without the PWA pain

Hyvä makes headless and PWA builds simpler. Its lightweight stack (Alpine.js + Tailwind) keeps things fast without losing flexibility.

For global brands, it’s a clean way to build region-specific storefronts while keeping ops centralized. APIs move clean, UX stays fast, and you avoid the complexity that comes with bloated frontend frameworks.

You still get the headless win, without needing to reinvent your stack to get there.

4. Analytics without the drag

Hyvä makes it easy to integrate tracking tools—like GTM, GA4, or heatmaps—without weighing down your storefront.

You still get rich data layers and conversion insights, but page speed stays sharp. Want to ID why users drop during checkout? You’ll know. And you’ll still be loading in under 2 seconds.

That kind of performance-awareness isn’t an afterthought in Hyvä. It’s built in.

Thinking about rebuilding your Adobe Commerce storefront?

Would love to hear how you’re thinking about frontend performance, or the challenges you’re running into.

Have you looked at Hyvä for your storefront yet?
Drop your thoughts or questions below 👇