DEV Community: Ashish Kumar

Finding Duplicate Photos in the Browser (Without Uploading Your Library)

Ashish Kumar — Sun, 17 May 2026 14:54:38 +0000

My Downloads folder had the same vacation photos three times — once from Google Photos export, once from a WhatsApp forward, once from a backup script that renamed everything IMG_20240315 (1).jpg. Different names. Same bytes. About 4 GB of waste I only noticed when my laptop started complaining about disk space.

The obvious fix is a "duplicate photo finder." The obvious problem is what most of those tools ask you to do first: upload your entire library.

That felt wrong for photos I would never put on a random SaaS server. So I spent a few weeks building a client-side alternative — DupShelf — and this post is the engineering story behind it: what browsers can actually do today, where they still can't, and how to verify that your files never leave your machine.

Why cloud duplicate scanners are a bad default for personal photos

Server-side duplicate finders follow a simple pipeline:

You upload thousands of files.
Their backend hashes or perceptually compares them.
You get a report (and sometimes a "delete all" button).

That made sense in 2012 when JavaScript couldn't read a folder from disk. In 2026 it's mostly inertia.

The costs for you:

Privacy — wedding albums, kids' photos, medical scans, work screenshots. Uploading is an act of trust with unclear retention.
Time — home upload speeds are asymmetric. Shipping 30 GB up often takes longer than hashing locally.
Control — many tools optimize for "free up space now" with aggressive delete flows. One mis-click on a similar-looking burst is worse than keeping a duplicate.

Client-side duplicate finding flips the model: your CPU does the work, your disk is the only storage that matters, and nothing is deleted unless you decide to.

Exact duplicates vs "similar" photos (be precise about what you promise)

Users say "find duplicate photos" but mean two different things:

What users imagine	What most engineers build first
Same file copied twice	Exact duplicate — identical bytes
Burst shots, crops, re-saved JPEGs	Similar image — perceptual hash, ML embeddings

Exact matching is deterministic: hash the file, compare hashes, done. Renamed copies, re-exports, and "Copy of…" files still match even when metadata differs.

Similar matching is fuzzy: two portraits taken a second apart might group together; a heavily edited version might not. It needs different algorithms (pHash, CLIP, etc.), more CPU, and more false positives.

DupShelf ships exact duplicates only for now — SHA-256 over file content, grouped by hash. That's intentional: it's the safest first cleanup pass. You only remove files that are provably identical to another file in the set.

When similar-image mode exists, it should be optional and loudly labeled. Mixing "similar" results into an exact-duplicate UI is how tools earn angry reviews.

How local duplicate detection actually works

At a high level the pipeline is boring on purpose:

Enumerate files in a folder (recursive) or from a file picker batch.
Filter to image types the browser can treat as blobs (jpeg, png, webp, etc.).
Hash each file's bytes (DupShelf uses SHA-256 via Web Crypto).
Group files that share a hash.
Review — human picks one keeper per group.
Act — move extras to a subfolder or export a CSV for manual cleanup.

No magic. The interesting parts are browser APIs and UX around large folders.

Hashing at scale

SHA-256 in the browser is fast enough for real libraries on a desktop. The slow part is often reading files from disk through the File System Access API, not the hash itself.

Practical patterns:

Stream or chunk large files if memory is tight (DupShelf reads blobs sized for typical photos).
Run hashing off the main thread with Web Workers so the UI stays responsive.
Show honest progress — "hashing" is the slow phase users feel on 8k+ file folders; hiding that behind a spinner breeds distrust.

Why filenames lie

Backup tools, messengers, and sync clients rename files constantly:

photo.jpg → photo (1).jpg
DSC_0042.NEF → DSC_0042-copy.NEF
Same bytes, new path

Content hashing ignores names. That's the whole point.

The File System Access API: folder scan and safe moves

Chrome and Edge on desktop support picking a directory handle with showDirectoryPicker(). DupShelf walks it recursively, builds a list of image refs, and keeps the handle so you can move non-keepers later.

Important nuances:

Read vs write — scanning needs read access. Moving duplicates into a subfolder needs write permission; the browser may prompt again. That's good — explicit consent beats silent disk writes.
Safari / Firefox — no full-folder picker today. Users can still add batches via file input, drag-and-drop, or paste. The tool should say that plainly instead of failing mysteriously.
Secure context — folder access requires HTTPS (or localhost during development).

DupShelf never auto-deletes. The write path creates a folder named dupshelf-duplicate-images inside your library and moves extras there in grouped subfolders. You verify in Finder or Explorer, then delete when ready.

OPFS for session restore (optional but nice)

If you've read about the Origin Private File System, it's a good fit for tool state:

Scan results (groups, keeper choices, file metadata) can be large.
localStorage is the wrong tool — size limits and synchronous JSON stringify hurt.
OPFS gives you private, origin-scoped file storage for structured session snapshots.

DupShelf persists completed scans to OPFS so a tab refresh doesn't throw away an hour of hashing. File handles don't survive reloads — you reconnect the same folder to move files again. That's a browser security rule, not a product bug.

Review UX: the product is the grouping UI

Finding duplicates is table stakes. Reviewing them is the product.

What worked in testing:

Virtualize the group list — a 900-group library must not render 900 DOM cards at once.
One keeper per group — tap a thumbnail to keep it; everything else in the group is a move candidate.
Show recoverable space — sum file sizes minus keepers. People need a number to justify an afternoon of cleanup.
CSV export — for users who want a checklist in Excel or a script, not in-app moves.
Verify folder — re-enumerate and re-hash after manual changes on disk.

Real use cases (where local exact dedup wins)

Messy Downloads folders — screenshots, memes, and attachments with (1) in the name. Low risk, high reward.

Pre-backup cleanup — dedupe before Time Machine or copying to an external drive. Smaller archives, faster restores.

WhatsApp / Telegram exports — forwarded photos land with new names daily. Exact dedup catches true copies; it won't merge burst shots.

Photographer delivery folders — verify you didn't zip the same export twice before sending to a client.

Privacy-sensitive libraries — anything you legally or personally shouldn't upload to a third-party "free scanner."

DupShelf has longer guides on these scenarios at dupshelf.renderlog.in if you want SEO-shaped deep dives; the workbench itself is at dupshelf.renderlog.in/app.

How to verify a tool really runs locally

Before you point any duplicate finder at a sensitive folder:

Network tab — start a scan, filter by your domain. Image bytes should not POST to the server. Marketing pages may load analytics; the scan itself should not upload files.
Offline test — load the app once, disconnect, refresh. Client-side tools should still open (scanning may need the tab that already has permission).
Read the move contract — does it delete in-app or move to a folder you control?

DupShelf is static-hosted (Next.js on Vercel) with no backend that accepts your photos. The privacy policy describes folder permissions in plain language: dupshelf.renderlog.in/privacy.

Trade-offs (honest list)

Browser memory — hashing 20k RAW files in one tab on an 8 GB machine can hurt. Start with a subfolder.

Exact only — re-saved JPEGs at different quality settings are different bytes. Similar detection is a different product.

Desktop-first — folder scan + move is built for Chrome/Edge on a laptop. Mobile can add files manually; it's not the primary workflow.

Initial JS bundle — a serious tool ships workers, virtualization, and OPFS helpers. First visit costs more than a landing-page-only site. Cache helps after that.

What I shipped (and what I deliberately didn't)

DupShelf is free, no account, no upload. Core loop:

Choose folder or add batches
Scan with visible progress
Review groups, pick keepers
Move to dupshelf-duplicate-images or export CSV
Session restore + undo last move for folder scans

Deliberately not in v1: cloud sync, AI similarity, auto-delete, mobile folder access, or upsell walls. Those are either privacy regressions or scope explosions.

If you maintain a photo library on disk and you've been putting off cleanup because cloud tools feel gross, try a local pass first. Exact duplicates are the safest win — you'll know the bytes matched before you move anything.

Try it: dupshelf.renderlog.in/app

How it works (marketing): dupshelf.renderlog.in

I build browser-based tools under the Renderlog umbrella — client-side when the platform allows, honest about limits when it doesn't. DupShelf is the duplicate-photo piece; if this post helped, the workflow might save you a few gigabytes this weekend.

If this was useful, I've also built a handful of other free, browser-based tools — no signup, no uploads, everything runs client-side:

JSON Tools — https://json.renderlog.in (formatter, validator, JWT decoder, JSONPath tester, 40+ converters)
Text Tools — https://text.renderlog.in (case converters, slug generator, HTML/markdown utilities, 70+ tools)
PDF Tools — https://pdftools.renderlog.in (merge, split, OCR, compress to exact size, 40+ tools)
Image Tools — https://imagetools.renderlog.in (compress, convert, resize, background remover, 50+ tools)
DupShelf — https://dupshelf.renderlog.in (find exact duplicate photos locally, move or export CSV, no upload)
QR Tools — https://qrtools.renderlog.in (WiFi, vCard, UPI, bulk QR codes with logos)
Calc Tools — https://calctool.renderlog.in (60+ calculators for finance, health, math, dates)
Notepad — https://notepad.renderlog.in (private, offline-first notes, no signup)

What Is Preact and Why Does a 3KB Version of React Exist

Ashish Kumar — Sat, 16 May 2026 00:30:00 +0000

Related: JavaScript Bundle Analysis: Tree Shaking and Code Splitting Explained covers why the size difference between React and Preact matters and how bundle size translates to parse time on real hardware.

React is approximately 45KB minified and gzipped (react + react-dom combined). Preact is approximately 3KB. Both let you write JSX components with hooks. Both produce the same UI. The question "why does Preact exist" has a specific technical answer, not a vague one about bundle size. React ships features that most applications never use, and those features are not cheap. Preact ships without them. The 42KB difference is exactly those features.

What this covers: What is actually inside React's 45KB that Preact does not include, what the API compatibility story looks like, which applications benefit most from the switch, and the one major React feature that Preact does not support at all.

What React's 45KB actually contains

React is split into two packages: react (core API, ~7KB) and react-dom (renderer for the browser, ~38KB). The react-dom package is where most of the size lives, and it contains several systems that Preact either removes entirely or significantly simplifies.

Synthetic event system. React does not attach event listeners directly to DOM elements. It attaches a single event listener to the root of the document and uses event delegation to handle all events across the component tree. When an event fires, React's synthetic event system normalizes it into a cross-browser compatible event object before passing it to your handler.

This system exists because in 2013 when React was created, browser event handling was inconsistent enough that normalization was necessary. Today, modern browsers are far more consistent, but the synthetic event system remains because removing it would be a breaking change.

Preact attaches event listeners directly to DOM elements using addEventListener. It calls native browser events. No normalization layer. No delegation. Most applications running on modern browsers do not notice the difference.

Legacy context API support. React ships code for both the old context API (childContextTypes, contextTypes) and the new one (createContext). Legacy code and third-party libraries that still use the old API continue to work. This backward compatibility code adds size.

Preact supports only the modern createContext API. Any library that uses the old context API will not work with Preact.

Development mode tooling. React has two bundles for every module: a development build (with warnings, error messages, and development tooling) and a production build. The bundler switches between them at build time. Even the production build retains some infrastructure for React DevTools integration.

Fiber scheduling infrastructure. React's Fiber architecture includes a complete implementation of a cooperative scheduler, work loops, priority lanes, and the infrastructure for Concurrent Mode features. This is the machinery behind useTransition, useDeferredValue, Suspense for data fetching, and streaming SSR. It is substantial code, and it is always present in your bundle even if you use none of the concurrent features.

Preact does not have a scheduler. It processes updates synchronously. This is simpler and smaller, but it means Preact does not support Concurrent Mode features.

What Preact keeps

Preact supports essentially the full modern React component API:

Function components with all core hooks: useState, useEffect, useReducer, useContext, useRef, useMemo, useCallback, useLayoutEffect
JSX (same syntax, same compilation output)
createContext and useContext
forwardRef and createRef
React.memo (called memo in Preact)
Suspense (for lazy-loaded components via React.lazy())
Error boundaries (class components only, same as React)
Portals

For most application code, the API surface is identical. Components written for React generally work in Preact without modification.

Preact/compat: the drop-in replacement layer

For projects that want to migrate from React to Preact, or that use third-party libraries expecting React, Preact provides a compatibility layer called preact/compat.

// vite.config.ts or webpack.config.js
// Alias react and react-dom to preact/compat

  resolve: {
    alias: {
      'react': 'preact/compat',
      'react-dom': 'preact/compat',
      'react-dom/test-utils': 'preact/test-utils',
      'react/jsx-runtime': 'preact/jsx-runtime',
    },
  },
};

With this alias in place, any import of react or react-dom in your code or in node_modules resolves to Preact's compatibility layer. Libraries like React Router, React Query, Radix UI, and most of the ecosystem work without any changes to their source code.

The compatibility layer adds some size on top of the 3KB Preact core, but the total is still around 4 to 5KB, compared to React's 45KB.

Where the performance difference shows up

On a MacBook M3 or any modern development machine, the difference between React and Preact is usually imperceptible. The extra 42KB parses in under a millisecond. This is why most large applications with fast deployment targets never feel compelled to switch.

The difference becomes measurable in specific contexts:

Low-end Android devices. JavaScript parse time scales with bundle size and with CPU speed. On a mid-range Android phone with a slower CPU, 42KB of JavaScript takes meaningfully longer to parse than it does on a development machine. Cutting 42KB from the bundle has a proportionally larger effect on slower CPUs than on fast ones.

Embedded widgets. If you are building a component that will be embedded on third-party pages (chat widgets, feedback forms, survey tools, analytics dashboards), you do not control the host page's performance budget. The host page has its own React bundle if it is a React app. Your embedded widget cannot share that React installation. Shipping 45KB of React in your widget is a significant imposition on the host page. Shipping 3KB is not.

High-traffic marketing sites with strict performance budgets. Sites where LCP targets are aggressive and every kilobyte is audited. Trading 45KB of React for 4KB of Preact can be the difference between passing and failing a performance budget.

Micro-frontends where React cannot be shared. If different micro-frontend bundles are versioned independently and cannot share a single React installation, each bundle that requires React pays the 45KB cost. Preact's 3KB cost is less significant to pay multiple times.

The one major missing feature: Concurrent Mode

Preact does not support React's Concurrent Mode features. Specifically:

useTransition and startTransition exist in Preact's API but do not schedule work the way React's scheduler does. They behave more like synchronous updates with a lower priority hint rather than truly preemptible background rendering.
useDeferredValue has limited effectiveness for the same reason.
Streaming SSR via renderToReadableStream is not supported.
React Server Components are not supported.

For applications that rely on useTransition to keep heavy re-renders from blocking user input, or that use React Server Components and streaming SSR, Preact is not a viable replacement.

For applications using hooks, standard data fetching (React Query, SWR), React Router, and the standard component model without concurrent features, Preact is functionally identical from the developer's perspective.

Who uses Preact in production

Shopify uses Preact for several of its storefront components because their theme ecosystem requires JavaScript bundles that load on every merchant's store. Reducing bundle size directly reduces Time to Interactive for millions of storefronts.

Google has several internal tools and projects built on Preact, maintained partly by Jason Miller, Preact's creator, who works at Google. The Google Search result page has used Preact for interactive elements.

Smaller SaaS products with widget offerings frequently use Preact to keep their embeddable widgets lightweight.

The pattern is consistent: teams choose Preact when they either cannot afford React's bundle size (constraint) or do not need its advanced runtime features (simplicity). Most large SPAs do not switch because the difference does not justify the migration risk and the loss of Concurrent Mode capabilities.

Making the decision

The decision framework:

Situation	Recommendation
New application, no performance budget constraints	React. Larger ecosystem, better concurrent features, more future-proof.
New application, strict bundle size budget	Preact with preact/compat. Near-identical DX, fraction of the size.
Existing React app, minor performance concerns	Do not migrate. The risk-to-benefit ratio is poor.
Embedded widget or micro-frontend	Preact is worth evaluating.
Need `useTransition` for heavy re-renders	React. Preact cannot match this.
Need React Server Components	React. Preact has no equivalent.

Preact exists because React's size is not an accident of poor engineering; it is the result of deliberate decisions to support a broad range of use cases and to maintain backward compatibility. For applications that do not need those use cases, Preact removes the cost without removing the API. Understanding what the cost actually is makes the decision straightforward.

Read the original article on Renderlog.in:
https://renderlog.in/blog/preact-vs-react-why-3kb-alternative-exists/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Service Worker Caching Strategies: Cache-First, Network-First, and SWR

Ashish Kumar — Fri, 15 May 2026 00:30:00 +0000

Related: Network Optimization for SPAs and React Apps covers the broader network optimization picture including HTTP caching and API request optimization.

A service worker is a JavaScript file that runs in a background thread, separate from your main application. It intercepts every network request your page makes and can respond from cache, modify the request, or let it pass through to the network unchanged. For a returning visitor, a well-configured service worker means many requests never touch the network at all. The page loads from cache at local disk speed.

What this covers: What service workers can and cannot do, the three core caching strategies (cache-first, network-first, stale-while-revalidate), when each strategy is correct for which resource type, and how Workbox makes implementing these strategies practical without writing the interception logic by hand.

What a service worker actually does

A service worker is registered by your application JavaScript and installed by the browser. Once installed, it intercepts all network requests made from pages on its origin. This includes requests for HTML, CSS, JavaScript, images, fonts, and API calls.

// Register the service worker from your main application
if ('serviceWorker' in navigator) {
  window.addEventListener('load', () => {
    navigator.serviceWorker.register('/sw.js');
  });
}

The service worker file (sw.js) runs in a separate worker thread. It has access to the Cache Storage API, which is separate from the HTTP cache the browser manages automatically. The Cache Storage API is under your complete control: you decide what to cache, when to cache it, how long to keep it, and when to delete it.

// Inside sw.js: intercept a fetch event and respond from cache
self.addEventListener('fetch', event => {
  event.respondWith(
    caches.match(event.request).then(cachedResponse => {
      if (cachedResponse) {
        return cachedResponse; // Serve from cache
      }
      return fetch(event.request); // Fall through to network
    })
  );
});

This is the basic cache-first pattern in raw form. Every real application needs more nuance: what if the cache is stale? What if certain resources should never be served from cache? What if the network is unavailable? Writing and maintaining all of this logic by hand is error-prone, which is why Workbox exists.

Strategy 1: Cache-First

Cache-first means: check the cache first. If a response is in cache, return it immediately without hitting the network. Only go to the network if the resource is not in cache.

Use this for: Versioned static assets. JavaScript bundles, CSS files, images, and fonts that have content hashes in their filenames (main-a1b2c3.js). When the content changes, the filename changes, so cached versions are never stale. The old cache entry becomes unreachable by the new URL and gets cleaned up during the next cache update.

Why it works for these resources: Versioned assets are safe to serve from cache forever because the filename is tied to the content. A browser serving main-a1b2c3.js from cache in six months will serve the exact same content that was served when the file was first cached. The application code that requests this file will either request the cached version (nothing changed) or request a different URL (the content changed and the new build output has a new hash).

// Workbox: cache-first for all versioned assets

registerRoute(
  // Match hashed JavaScript and CSS files
  ({ request, url }) =>
    request.destination === 'script' ||
    request.destination === 'style',
  new CacheFirst({
    cacheName: 'static-assets',
    plugins: [
      new ExpirationPlugin({
        maxAgeSeconds: 365 * 24 * 60 * 60, // 1 year
        maxEntries: 60,
      }),
    ],
  })
);

What to avoid: Using cache-first for HTML documents or unversioned API endpoints. If your HTML is served from cache and you deploy a new version, users will continue loading the old HTML until the cache expires. HTML should use network-first or stale-while-revalidate so users always get current navigation and content structure.

Strategy 2: Network-First

Network-first means: try the network first. If the network succeeds, serve the response and update the cache. If the network fails (offline, timeout, server error), fall back to the cached version.

Use this for: HTML pages, API endpoints serving fresh data, and any resource where stale content would cause problems. The user always gets the freshest version when online. When offline, they get a reasonable fallback from cache.

// Workbox: network-first for HTML pages

registerRoute(
  ({ request }) => request.mode === 'navigate', // HTML navigation requests
  new NetworkFirst({
    cacheName: 'pages',
    networkTimeoutSeconds: 3, // Fall back to cache if network takes more than 3 seconds
    plugins: [
      new ExpirationPlugin({
        maxEntries: 50,
        maxAgeSeconds: 30 * 24 * 60 * 60, // Keep cached pages for 30 days
      }),
    ],
  })
);

The networkTimeoutSeconds option is important for offline-capable applications. Without it, network-first will wait indefinitely for a network response even when the user is offline, only falling back to cache after the connection eventually times out (which can take 30-60 seconds). Setting a 3-second timeout means users in poor network conditions get a cached response quickly.

For API endpoints serving user-specific or time-sensitive data:

// Workbox: network-first for API calls
registerRoute(
  ({ url }) => url.pathname.startsWith('/api/'),
  new NetworkFirst({
    cacheName: 'api-responses',
    networkTimeoutSeconds: 5,
    plugins: [
      new ExpirationPlugin({
        maxEntries: 100,
        maxAgeSeconds: 24 * 60 * 60, // Cache API responses for 1 day
      }),
    ],
  })
);

The cached API response is not perfectly fresh, but for most use cases it is better than showing an error page when the network is unavailable.

Strategy 3: Stale-While-Revalidate

Stale-while-revalidate means: serve the cached version immediately (stale), and simultaneously fetch a fresh version from the network in the background (revalidate). The next request gets the fresh version.

Use this for: Resources where some staleness is acceptable and speed is more important than absolute freshness. Navigation assets that change infrequently, avatar images, icon sets, and any resource where showing a slightly old version on the current visit is fine as long as the next visit gets the update.

// Workbox: stale-while-revalidate for images

registerRoute(
  ({ request }) => request.destination === 'image',
  new StaleWhileRevalidate({
    cacheName: 'images',
    plugins: [
      new ExpirationPlugin({
        maxEntries: 60,
        maxAgeSeconds: 30 * 24 * 60 * 60, // 30 days
      }),
    ],
  })
);

The user experience for stale-while-revalidate: on the first visit, there is no cache, so the image loads from the network normally. On subsequent visits, the cached image appears instantly. In the background, the service worker fetches a fresh version from the network. If the image changed, the fresh version replaces the cached version. On the visit after that, the updated image appears instantly.

Why this is powerful for most non-critical resources: Users almost never notice if an avatar image or icon set is one version old. What they notice is speed. Stale-while-revalidate gives them cache speed on every visit while keeping the cache reasonably fresh.

Precaching: caching at install time

All three strategies above are runtime caching: resources get cached when the user visits pages that request them. Precaching is different: you tell Workbox which resources to cache immediately when the service worker installs, before the user has visited any page.

Precaching is used for the application shell: the minimal HTML, CSS, and JavaScript needed to render a working (possibly empty) UI. When the user opens the app, even before any network requests complete, the service worker serves the precached shell and the app renders immediately.

// Workbox: precache the app shell at install time

// This list is generated by Workbox at build time (via workbox-build or the Vite plugin)
// It contains all files from your build output with their content hashes
precacheAndRoute(self.__WB_MANIFEST);

The self.__WB_MANIFEST placeholder is replaced at build time by the Workbox build tool with an array of all your static assets and their content hashes. When a user installs the service worker for the first time, Workbox fetches all these assets and caches them. On subsequent visits, they are served from cache instantly.

Setting up Workbox in a Vite project

The easiest setup for modern projects uses the vite-plugin-pwa plugin, which integrates Workbox configuration into the Vite build process:

// vite.config.ts

  plugins: [
    VitePWA({
      registerType: 'autoUpdate',
      workbox: {
        // Precache all files matching these patterns from the build output
        globPatterns: ['**/*.{js,css,html,ico,png,webp,svg,woff2}'],

        // Runtime caching rules
        runtimeCaching: [
          // Cache-first for versioned assets
          {
            urlPattern: /\.(?:js|css)$/,
            handler: 'CacheFirst',
            options: {
              cacheName: 'static-resources',
              expiration: {
                maxAgeSeconds: 365 * 24 * 60 * 60,
              },
            },
          },
          // Network-first for API calls
          {
            urlPattern: /^https:\/\/api\.example\.com\//,
            handler: 'NetworkFirst',
            options: {
              cacheName: 'api-cache',
              networkTimeoutSeconds: 5,
              expiration: {
                maxEntries: 200,
                maxAgeSeconds: 24 * 60 * 60,
              },
            },
          },
          // Stale-while-revalidate for images
          {
            urlPattern: /\.(?:png|jpg|webp|svg|gif)$/,
            handler: 'StaleWhileRevalidate',
            options: {
              cacheName: 'images',
              expiration: {
                maxEntries: 100,
                maxAgeSeconds: 30 * 24 * 60 * 60,
              },
            },
          },
        ],
      },
    }),
  ],
};

This configuration handles the most common case: versioned JavaScript and CSS with cache-first, API responses with network-first and a 5-second fallback timeout, and images with stale-while-revalidate.

What service workers cannot cache

Opaque responses. Requests to third-party origins without CORS headers return "opaque" responses. Opaque responses can be cached, but their size is counted as 7MB regardless of actual size due to security restrictions. Caching too many opaque responses can exhaust cache storage limits.

Range requests. Video streaming uses HTTP range requests to fetch specific byte ranges. Service workers can intercept these, but handling them correctly requires specific logic. The default Workbox strategies do not handle range requests.

Resources requiring authentication in every request. If a resource requires a fresh token in each request and you cannot cache the token, you cannot meaningfully cache the resource either.

The return visit experience

After a service worker is installed and caching is running correctly, a returning visitor's experience is qualitatively different from a first visit:

User opens the app
Service worker intercepts navigation request
Precached index.html returns instantly from service worker cache
Browser parses HTML, requests JavaScript and CSS
Service worker intercepts those requests, returns from cache instantly
App renders with no network requests at all
In background, service worker fetches fresh API data
UI updates with fresh data when background fetch completes

Steps 1 through 6 complete in under 100ms on most devices, regardless of network speed, because no network requests were made. The perceived load time is the time to render from cache, not the time to fetch from a server.

This is the correct mental model for why service workers matter: not as a way to make network requests faster, but as a way to eliminate network requests entirely for everything that can safely be served from cache.

Read the original article on Renderlog.in:
https://renderlog.in/blog/service-worker-caching-strategies-workbox/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Preload vs Prefetch vs Preconnect: When to Use Each Resource Hint

Ashish Kumar — Thu, 14 May 2026 00:30:00 +0000

Related: Critical CSS: What Render-Blocking Really Means and How Inlining Fixes It covers the related optimization of eliminating render-blocking CSS, which pairs well with resource hint strategy.

The three resource hints (preload, prefetch, preconnect) look similar enough that developers regularly use them interchangeably. They are not interchangeable. Each one tells the browser to do a different thing with a different priority and a different timing. Using preload when you meant prefetch puts a resource in the high-priority queue and competes with CSS and critical JavaScript, potentially making the current page slower while trying to speed up a future page. Getting this wrong is worse than not using resource hints at all.

What this covers: What each hint actually tells the browser, when each one fires in the page lifecycle, the browser's priority system and how hints fit into it, and concrete examples of when to use each.

Preload: this page needs this resource soon

preload tells the browser to fetch a specific resource at high priority because the current page will need it soon. It is a declaration of intent for the current page, not a future one.

<head>
  <!-- Preload the LCP image before the HTML parser finds the <img> tag -->
  <link rel="preload" href="/hero.webp" as="image" fetchpriority="high" />

  <!-- Preload a font that is referenced in CSS (CSS would discover it later) -->
  <link rel="preload" href="/fonts/Inter.woff2" as="font" type="font/woff2" crossorigin />

  <!-- Preload a script that will be needed immediately after parsing -->
  <link rel="preload" href="/analytics.js" as="script" />
</head>

The as attribute is required and tells the browser what type of resource is being preloaded. This is critical because different resource types have different priorities and different caching behaviors. Without as, the browser fetches the resource but cannot apply the correct priority, content security policy, or caching headers.

Resource type	`as` value
JavaScript file	`script`
CSS stylesheet	`style`
Image	`image`
Font	`font`
Video	`video`
Fetch/XHR data	`fetch`

The use case for preload: A resource that is on the critical path for the current page but is discovered late by the browser's preloader. The browser preloader scans HTML as it arrives looking for resources to fetch. It finds <link>, <script>, and <img> tags. It does not execute JavaScript, so it cannot discover resources loaded dynamically. It cannot read CSS to discover the fonts referenced in url(). Preload is how you tell it about resources it would otherwise miss until late in the parse.

The most common correct use: Preloading the LCP image when it is a background image set by CSS (the preloader cannot discover it), preloading fonts that appear in the CSS (the preloader cannot read CSS), and preloading scripts that initialize critical functionality immediately on load.

The most common incorrect use: Preloading resources for other pages ("I'll preload the dashboard assets on the homepage just in case"). That is what prefetch is for. Misusing preload here gives those assets the same priority as critical CSS and can delay the current page's first paint.

Prefetch: a future page will probably need this

prefetch tells the browser to fetch a resource that a future navigation might need. It is a low-priority request that runs during browser idle time and does not compete with resources the current page needs.

<head>
  <!-- Hint that the user will probably navigate to the dashboard next -->
  <link rel="prefetch" href="/dashboard.js" as="script" />
  <link rel="prefetch" href="/dashboard.css" as="style" />
</head>

The browser treats prefetch as a background task. On a busy connection, it may delay the prefetch until the current page is fully loaded. On an idle connection, it may start immediately. The browser makes this decision based on network conditions and its own resource scheduling.

Prefetched resources are stored in the browser's cache with a short TTL. When the user navigates to the page that needs them, the browser finds them in cache and skips the network request entirely.

The use case for prefetch: Predictable navigation paths. You know from analytics that 70% of users who view the homepage proceed to the signup page. Prefetching the signup page's JavaScript and CSS assets during the homepage's idle time means those assets are already cached when the user clicks "Sign Up."

<!-- On the homepage, prefetch signup page assets -->
<link rel="prefetch" href="/signup-bundle.js" as="script" />

<!-- On product listing pages, prefetch checkout assets -->
<link rel="prefetch" href="/checkout-bundle.js" as="script" />

When not to use prefetch: When you are not confident about the next navigation. Prefetching assets that most users will not need wastes bandwidth, particularly on mobile connections where the user may have limited data.

Preconnect: we will talk to this server soon

preconnect tells the browser to establish a connection to an origin before it needs to make any requests to it. Establishing a connection has three steps: DNS lookup, TCP handshake, and TLS negotiation. Together these can take 100 to 500ms depending on the server location and connection quality.

<head>
  <!-- Establish connection to CDN before any requests are made to it -->
  <link rel="preconnect" href="https://cdn.example.com" />

  <!-- Establish connection to Google Fonts so the font request starts faster -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

  <!-- Establish connection to your API server -->
  <link rel="preconnect" href="https://api.example.com" />
</head>

preconnect does not fetch anything. It just performs the handshake. When the actual request to that origin comes (because the browser encountered a font URL in CSS, or your JavaScript fetched from the API), the connection is already established and the request goes straight to data transfer.

The crossorigin attribute is required for connections to origins that will serve resources requested with CORS (such as fonts). Without crossorigin, the browser establishes an anonymous connection, but the actual font request is a CORS request that requires credentials, so the browser has to establish a second connection. Two handshakes instead of one.

The use case for preconnect: Any third-party origin that serves resources critical to the current page. Google Fonts, analytics providers, CDN origins for your static assets, API endpoints that your application calls on load.

The timing advantage: The browser discovers third-party origins by reading your HTML, CSS, and JavaScript. It cannot preconnect until it encounters the URL. With preconnect in the document head, the connection starts before HTML parsing is even complete. Google's Lighthouse team measured typical savings of 100 to 300ms on FCP for pages with third-party fonts and CDN assets.

dns-prefetch: preconnect's less aggressive sibling

dns-prefetch does only the DNS lookup, skipping the TCP handshake and TLS negotiation.

<link rel="dns-prefetch" href="https://api.example.com" />

Use dns-prefetch for third-party origins that you know the page will talk to but that are not on the critical path for initial render. The DNS lookup (20 to 120ms) is still saved, but you avoid keeping a TCP connection open for a server the page might not talk to for several seconds.

For origins that are on the critical path, preconnect is better. For origins that are used later in the page's lifetime (analytics, chat widgets, lazy-loaded components), dns-prefetch is the appropriate hint.

fetchpriority: priority signaling within a resource type

fetchpriority is a newer attribute that works alongside preload, not as a separate hint. It lets you tell the browser the relative priority of resources within the same type.

<!-- Tell the browser this is the most important image -->
![Hero](https://renderlog.in/hero.webp)

<!-- Mark lower-priority images that can wait -->
![Thumbnail](https://renderlog.in/thumbnail.webp)

<!-- For preloaded LCP images: add fetchpriority to the preload link too -->
<link
  rel="preload"
  href="/hero.webp"
  as="image"
  fetchpriority="high"
/>

Without fetchpriority, the browser assigns image priority based on its position in the document and whether it is in the viewport. For the LCP image, the browser often gets this right. But when the LCP image is loaded dynamically via JavaScript, or when it appears below several other images in the HTML, the browser might assign it a lower priority than it deserves. fetchpriority="high" overrides this.

Putting it together: a real page example

Here is what a well-instrumented <head> looks like for a content-heavy site with a hero image, a custom font, and a CDN for assets:

<head>
  <meta charset="UTF-8" />
  <meta name="viewport" content="width=device-width, initial-scale=1" />

  <!-- 1. Preconnect to third-party origins on the critical path -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />
  <link rel="preconnect" href="https://cdn.example.com" />

  <!-- 2. Preload the LCP image (hero) -->
  <link
    rel="preload"
    href="https://cdn.example.com/hero.webp"
    as="image"
    fetchpriority="high"
  />

  <!-- 3. Load CSS -->
  <link rel="stylesheet" href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600" />
  <link rel="stylesheet" href="/styles/main.css" />

  <!-- 4. Prefetch assets for the most common next page -->
  <link rel="prefetch" href="/dashboard.js" as="script" />

  <!-- 5. DNS prefetch for non-critical third-party origins -->
  <link rel="dns-prefetch" href="https://analytics.example.com" />
</head>

The order matters: preconnects first so connection establishment starts as early as possible, then preloads for current-page critical resources, then the actual <link> and <script> tags, then prefetches for future pages, then dns-prefetch for non-critical origins.

The mistake that costs the most

Preloading resources that the page does not use is the most expensive error. The browser fetches the preloaded resource at high priority, competing with your CSS and render-critical JavaScript. If the resource is never used on the current page, Lighthouse will warn:

Unused preload: /dashboard.js was preloaded but not used within 3 seconds

This unused preload consumed bandwidth and network priority for nothing. It is strictly worse than not having the hint at all.

Before adding a preload hint, verify that the resource is used on the current page and that it is on the critical path (meaning the user sees something broken or unstyled without it). If it meets both conditions, preload it. If it is for a future page, use prefetch. If you just need to warm up a connection, use preconnect.

Read the original article on Renderlog.in:
https://renderlog.in/blog/preload-prefetch-preconnect-resource-hints-guide/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Critical CSS: What Render-Blocking Means and How Inlining Fixes It

Ashish Kumar — Wed, 13 May 2026 00:30:00 +0000

Related: The Browser Main Thread and Rendering Pipeline explains the full rendering pipeline that critical CSS inlining is optimizing for.

Lighthouse flags "eliminate render-blocking resources" and most developers look at their CSS files with mild confusion. The file is small. It is on a CDN. How can 15KB of CSS be blocking the render of a page that otherwise looks fast? The answer is in the word "render-blocking" itself, which is more precise than it sounds. The browser will not draw a single pixel to the screen until it has read every CSS file in the document head. Not because it is slow, but because it is correct.

What this covers: Why all CSS is render-blocking by specification, what the browser is actually waiting for before painting, how critical CSS inlining removes the wait, and how to extract and inline it without manually editing stylesheets.

Why the browser blocks on CSS

The browser builds two trees before painting: the DOM (Document Object Model) from your HTML, and the CSSOM (CSS Object Model) from your CSS. Rendering requires both. The render tree is built by combining DOM and CSSOM, and nothing is painted until the render tree exists.

This means CSS is blocking by design. The browser cannot make progress on rendering while waiting for an external CSS file because it literally does not know how to style any element until all CSS is parsed. An element that appears red in the DOM might be styled to be invisible in CSS. The browser has no way to know until it reads the CSS.

When the browser encounters a <link rel="stylesheet"> tag in the HTML, it:

Pauses HTML parsing to prioritize fetching the CSS file (CSS is a high-priority resource)
Starts a network request for the CSS file
Waits for the full file to download
Parses the CSS and builds the CSSOM
Resumes HTML parsing
Proceeds to build the render tree and paint

That network request in step 2 is the problem. On a typical server with a 100ms round trip time, a CSS file adds at minimum 100ms to the time before the first pixel appears. With a slower connection or a server that is geographically distant, this can be 300 to 500ms. The CSS file can be completely empty and the delay still happens because the browser does not know that until it receives the empty file.

What critical CSS is

Not all CSS needs to block the render. The CSS needed to render the visible content on the initial viewport (above the fold) blocks the render of something the user cares about. The CSS for a modal that appears three screens down, the CSS for the footer, the CSS for components the user has not scrolled to yet: these block rendering but the user does not see the result of that rendering anyway.

Critical CSS is the subset of your CSS that applies to elements visible in the initial viewport without scrolling. It is the minimum CSS needed to make the above-the-fold content look correct.

For a typical landing page, critical CSS might include:

Body and base typographic styles
Navigation bar styles
Hero section layout and colors
Above-fold image styles
Any font-face declarations for above-fold text

Everything else is non-critical: sidebar styles, footer, modal, article content styles, form styles for components below the fold.

How inlining fixes the problem

Instead of loading critical CSS from an external file, you embed it directly in the HTML document inside a <style> tag in the <head>.

<!DOCTYPE html>
<html>
<head>
  <!-- Critical CSS: embedded directly, no network request needed -->
  <style>
    body { margin: 0; font-family: system-ui, sans-serif; }
    .nav { height: 60px; background: #fff; border-bottom: 1px solid #eee; }
    .nav__logo { font-size: 1.25rem; font-weight: 600; }
    .hero { padding: 80px 24px; max-width: 800px; margin: 0 auto; }
    .hero__title { font-size: 2.5rem; line-height: 1.2; }
    /* ... rest of above-fold CSS ... */
  </style>

  <!-- Non-critical CSS: loaded asynchronously, does not block paint -->
  <link
    rel="preload"
    href="/styles/main.css"
    as="style"
    onload="this.onload=null;this.rel='stylesheet'"
  />
  <noscript><link rel="stylesheet" href="/styles/main.css" /></noscript>
</head>

The critical CSS is available immediately: the browser reads the HTML, finds the <style> tag, parses the CSS inline, and builds the CSSOM without a network round trip. It can begin rendering above-fold content immediately.

The full stylesheet loads asynchronously using the rel="preload" trick (preload the file with as="style", then switch rel to stylesheet when loaded). Below-fold content that depends on the full stylesheet renders when it loads, but by that time the above-fold content is already visible and the user has started reading.

The <noscript> fallback handles the case where JavaScript is disabled, which would prevent the onload from firing. In that scenario, the stylesheet loads normally as a blocking resource.

Why manually maintaining critical CSS is impractical

Manually identifying which CSS applies above the fold and which does not is not feasible at any scale. Layouts change. Viewports vary. The above-fold content on a 375px phone is different from the above-fold content on a 1440px monitor.

The standard approach is to automate extraction with a tool that renders the page in a headless browser, identifies all elements visible in the initial viewport, and extracts the CSS rules that apply to those elements.

Critters is a plugin for webpack and Vite that does this at build time:

// vite.config.ts

  plugins: [critters()],
};

After building, Critters:

Renders each HTML page in a headless environment
Identifies which CSS rules apply to above-fold elements
Inlines those rules in <style> tags
Changes the <link> to load asynchronously

No manual work required. The build output has correct inlined critical CSS for each page.

Next.js has had critical CSS extraction built in since v10 through its integration with Critters. If you are using Next.js, this optimization is applied automatically to pages using the App Router.

Critical is a standalone Node.js package for extraction:


await critical.generate({
  base: 'dist/',
  src: 'index.html',
  target: {
    html: 'index-critical.html',
    css: 'critical.css',
  },
  width: 1300,
  height: 900,
  // Also generate for mobile viewport
  dimensions: [
    { width: 375, height: 812 },
    { width: 1300, height: 900 },
  ],
});

The dimensions option is important: critical CSS should cover the most common viewport sizes, not just one. A rule that is critical on mobile (because it styles content visible at 375px width) might be non-critical on desktop (where the content is below the fold), and vice versa.

The tradeoffs to understand

HTML file size increases. Inlining critical CSS means the CSS is embedded in every HTML response rather than being fetched once and cached. For pages with substantial critical CSS (say, 20KB), this adds 20KB to every HTML response. Weigh this against the round-trip savings.

CSS is duplicated. Critical CSS rules appear both in the <style> tag and in the full external stylesheet. When the external stylesheet loads, the browser parses the same rules again. This is harmless (CSS parsing is fast) but worth knowing.

Dynamic content complicates extraction. If your page uses client-side rendering to insert above-fold content after the initial HTML load, the extraction tool cannot see that content. The critical CSS it extracts will be incomplete because the above-fold elements did not exist when the headless renderer checked.

For server-side rendered pages, extraction works accurately. For heavily client-side rendered pages, you may need to either use renderBefore options to delay extraction until after React hydrates, or limit critical CSS to truly static above-fold elements like the navigation.

The Lighthouse connection

When Lighthouse reports "Eliminate render-blocking resources" and lists CSS files, it is measuring the time between when the page starts loading and when the first paint occurs. Every external CSS file in <head> adds to this time.

After inlining critical CSS and loading the full stylesheet asynchronously, Lighthouse will no longer flag the CSS file as render-blocking because it is loaded asynchronously and does not delay the initial paint.

The metric that typically improves most is First Contentful Paint, because above-fold content can now paint as soon as the HTML is received rather than waiting for an external CSS round trip. Depending on the server response time and connection speed, the FCP improvement can range from 100ms on fast connections to over 500ms on slow mobile connections.

A mental model for understanding render-blocking

Think of the browser as a factory. The HTML is the blueprint, the CSS is the paint colors and finishes specification, and the factory cannot start production until it has both documents. If the paint colors arrive one minute late, the entire factory sits idle for one minute regardless of how fast the machines are.

Critical CSS inlining is equivalent to printing the paint colors for the first section of the product directly on the blueprint. The factory can start producing the visible parts immediately and wait for the full paint specification to arrive for the parts it will produce later.

The external stylesheet still arrives and the rest of the page still gets fully styled. But the user sees the first screenful of content without waiting for a network round trip that was never about content the user could see on arrival.

Read the original article on Renderlog.in:
https://renderlog.in/blog/critical-css-inlining-render-blocking-explained/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

How HTTP/2 Made Five Frontend Performance Best Practices Obsolete

Ashish Kumar — Tue, 12 May 2026 00:30:00 +0000

Related: Network Optimization for SPAs and React Apps covers the modern optimization techniques that work with HTTP/2 rather than around HTTP/1.1's limitations.

In 2012, a frontend developer optimizing a website's network performance would combine all their JavaScript into one file, combine all their CSS, put icons into a single sprite image, split their static assets across multiple subdomains, and inline small images as base64 strings in CSS. All of these were correct. They were the right things to do.

By 2020, most of them were wrong. Not slightly suboptimal; actively counterproductive on HTTP/2. The underlying constraint they were designed around had been replaced by a better protocol, and the optimizations built for the old constraint became liabilities under the new one.

What this covers: What HTTP/1.1's connection limit actually meant in practice, how Google's SPDY experiment led to HTTP/2, what multiplexing changes about the request model, and which of the old practices to stop doing today.

The HTTP/1.1 problem: six connections, one queue per connection

HTTP/1.1 browsers open at most 6 parallel TCP connections to a single domain. Each connection handles one request at a time. If a response is slow, everything queued behind it on that connection waits.

A page loading 30 resources (CSS, JavaScript, fonts, images) from the same origin has to queue 24 of those resources to wait while the first 6 load. When one finishes, the next one in the queue starts. The 30th resource does not begin loading until 24 other resources have each had their turn.

The practical consequence was measured in seconds on typical web pages of that era. Performance engineers spent significant effort on strategies to work around this constraint.

The five workarounds that HTTP/1.1 made necessary

1. Domain sharding. Since browsers limited connections to 6 per domain, the workaround was to host assets on multiple subdomains. static1.example.com, static2.example.com, static3.example.com. Each subdomain got its own 6 connections, effectively multiplying the connection limit by the number of shards.

This worked at the cost of extra DNS lookups (20-120ms each), extra TCP handshakes, and extra TLS negotiations for each new domain. The parallelism gain typically exceeded those costs under HTTP/1.1.

2. CSS sprites. Making a separate HTTP request for each small icon or UI image was expensive under HTTP/1.1 because each request occupied a connection slot for its full round trip. The solution was to combine all icons into a single large image (the sprite sheet) and use CSS background-position to display the relevant portion of the sprite for each icon.

This reduced dozens of requests to one. The downside was that the browser had to download the entire sprite sheet even if only one icon was used on a given page.

3. JavaScript and CSS concatenation. For the same reason, all JavaScript files were concatenated into one file, and all CSS files into another. Two HTTP requests instead of twenty. The cost: browser cache granularity. If any file changed, the entire concatenated bundle was invalidated, even if only one module changed.

4. Inlining small resources as base64. Images smaller than a few kilobytes were often embedded directly in CSS as base64-encoded strings. This eliminated the HTTP request entirely at the cost of increasing the CSS file size and preventing the image from being cached separately.

/* HTTP/1.1 era optimization: inline small images to save a request */
.icon-search {
  background-image: url('data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAA...');
}

5. Cookie-free domains for static assets. Browsers send all cookies for a domain with every request to that domain. For static assets like images, fonts, and JavaScript, cookies are irrelevant but they still add bytes to every request header. Serving static assets from a cookieless domain avoided this overhead.

What Google built instead: SPDY

In 2009, Google's Chrome and infrastructure teams began prototyping a new transport protocol called SPDY (pronounced "speedy"). The goal was to eliminate the performance bottlenecks in HTTP/1.1 at the protocol level rather than working around them with application-level hacks.

SPDY ran over a single TCP connection and used multiplexing: multiple requests could share the same connection simultaneously, with responses interleaved in priority order. There was no queue. A slow response did not block faster responses. The connection limit was no longer the bottleneck.

Google deployed SPDY across their own infrastructure and published the results. Sites serving Google traffic saw measurable page load improvements. The IETF used SPDY as the basis for HTTP/2, which was standardized in 2015. Chrome, Firefox, and all major servers adopted it rapidly.

By 2018, HTTP/2 support was widespread enough that most web traffic ran over it. By 2022, HTTP/2 was the norm and HTTP/1.1 was the exception for major sites.

What multiplexing actually means

HTTP/2 multiplexing means that multiple HTTP requests and responses are interleaved on a single TCP connection. Each request/response pair is broken into frames, and frames from different requests can be intermixed on the wire.

From the browser's perspective: it can make 50 requests simultaneously over one connection and receive responses as they become ready, regardless of the order requests were made. A fast response to request 30 can arrive before the slow response to request 1.

From the server's perspective: it sees all requests and can prioritize responses. CSS and critical JavaScript can be sent before images, regardless of which was requested first.

The 6-connection limit no longer constrains parallelism. The browser can have hundreds of in-flight requests over a single HTTP/2 connection.

Why the old optimizations became anti-patterns

Domain sharding now hurts performance. With HTTP/2, all assets should come from the same origin. Multiple origins require multiple connections, and each HTTP/2 connection has overhead: TCP handshake, TLS negotiation, and the HTTP/2 settings exchange. Where HTTP/1.1 made multiple connections valuable, HTTP/2 makes a single connection more efficient.

Sharding across subdomains today means the browser establishes multiple connections when one would serve all resources with better prioritization.

CSS sprites now cost more than they save. HTTP/2 handles many small requests efficiently because they share a connection without queuing behind each other. A sprite sheet that was one efficient request is now one large resource that the browser must download entirely before any icon renders. Individual SVG files can be requested in parallel and only the ones used on the current page need to be downloaded.

Concatenated bundles hurt cache efficiency. The original reason for concatenation was to minimize HTTP requests. Under HTTP/2, 30 small JavaScript modules load nearly as fast as one large concatenated file. But the 30 individual files can be cached independently. When you change one module, only that module's cache is invalidated. With concatenation, every change invalidates the entire bundle.

This is one of the reasons Vite's development server can serve unbundled ES modules efficiently: in development over HTTP/2, hundreds of individual module requests perform similarly to serving one large bundle.

Inlining base64 images inflates critical resources. A base64-encoded image in your CSS increases CSS file size and delays rendering of everything that depends on that CSS file. Under HTTP/2, the marginal cost of an extra image request is low enough that it is almost never worth paying the inlining cost.

Cookie-free domains fragment the connection. Serving assets from multiple origins forces multiple HTTP/2 connections. The cookie overhead that domain separation was designed to avoid is minor compared to the connection overhead of the separation itself.

What has replaced the old optimizations

The modern equivalents address the same performance concerns through different mechanisms:

Old optimization	Modern replacement	Why it changed
Domain sharding	Single origin, HTTP/2	HTTP/2 connection is more efficient than multiple HTTP/1.1 connections
CSS sprites	Inline SVG, icon fonts, HTTP/2 parallel requests	Small requests are cheap; sprites prevent caching granularity
JS/CSS concatenation	Code splitting with long-lived vendor chunks	Cache efficiency matters more than request count
Base64 inlining	`preload` link hints, `fetchpriority="high"`	Control load priority without embedding in CSS
Cookie-free domains	Partitioned cookies, CDN configuration	Modern cookie scoping reduces cross-domain request overhead

The pattern is consistent: the old optimizations were workarounds for the 6-connection limit. The modern replacements assume multiplexing and optimize for what HTTP/2 actually costs: connection establishment, request priority signaling, and cache efficiency.

How to check if your site uses HTTP/2

Open Chrome DevTools, go to the Network tab, right-click the column headers, and enable the "Protocol" column. Reload the page. Each resource will show its protocol: h2 for HTTP/2, h3 for HTTP/3, or http/1.1 for the older protocol.

If any of your own resources show http/1.1 while others show h2, something in your infrastructure is not upgraded. Common causes: an old reverse proxy in front of your server, a CDN that does not have HTTP/2 enabled for your origin, or an older self-hosted server configuration.

If all resources show h2, the old workarounds above should be removed from your build process if they are still present. They are doing nothing useful and in several cases are actively reducing performance.

One thing that did not change

Request count is less important under HTTP/2, but response size still matters. Every byte downloaded costs bandwidth and parse time. The goal of reducing unnecessary requests shifted to reducing unnecessary bytes. Code splitting, tree shaking, image compression, and font subsetting are all about bytes, not request count, and they matter as much under HTTP/2 as they did under HTTP/1.1.

The optimizations that survived the HTTP/2 transition are the ones that were always about bytes. The ones that disappeared were the ones that were only about request count.

Read the original article on Renderlog.in:
https://renderlog.in/blog/http2-multiplexing-frontend-performance-changes/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

React.lazy() Route Code Splitting Explained

Ashish Kumar — Mon, 11 May 2026 00:30:00 +0000

Related: JavaScript Bundle Analysis: Tree Shaking and Code Splitting Explained covers how bundlers construct module graphs and where tree shaking fails, which is the foundation for understanding what code splitting actually does.

The size of your JavaScript bundle is not the number that matters for first load. What matters is how much of that bundle is needed to render the page the user actually landed on. A 5MB React application where the user landed on the marketing homepage might need 80KB to show that page. The other 4.92MB is code for routes the user has not visited and may never visit. React.lazy() is how you stop shipping those 4.92MB on first load.

What this covers: What React.lazy() does to the bundle at build time, how Suspense fits into the loading flow, how to confirm the split actually happened, the cases where it silently fails, and the preloading pattern that prevents waterfall fetches on navigation.

What React.lazy() does to the bundle

React.lazy() takes a function that returns a dynamic import(). The key word is dynamic. A static import at the top of a file is analyzed at build time and the imported module is included in the same output chunk. A dynamic import is a split point: the bundler creates a separate output chunk containing the dynamically imported module and all of its unique dependencies.

// Static import: Dashboard ends up in the same chunk as App

// Dynamic import with React.lazy(): Dashboard becomes a separate chunk
const Dashboard = lazy(() => import('./pages/Dashboard'));

When you switch from a static import to React.lazy(), your bundler (Vite, Webpack, or otherwise) creates a new file in the build output. Instead of one bundle, you get the main bundle plus a chunk file specifically for Dashboard and everything it imports that is not already in the main bundle.

The main bundle shrinks by the size of Dashboard and its unique dependencies. The Dashboard chunk is downloaded on demand when the user navigates to the dashboard route.


const Home = lazy(() => import('./pages/Home'));
const Dashboard = lazy(() => import('./pages/Dashboard'));
const Settings = lazy(() => import('./pages/Settings'));
const AdminPanel = lazy(() => import('./pages/AdminPanel'));

function App() {
  return (
    }>

    </Suspense>
  );
}

In this setup, a user who lands on / downloads the main bundle plus the Home chunk. They do not download anything for Dashboard, Settings, or AdminPanel until they navigate to those routes.

How Suspense fits in

React.lazy() by itself will throw an error if you try to render the component before its chunk has loaded. Suspense catches that error and shows a fallback UI while the chunk downloads.

The mechanics: when React tries to render a lazy component and the chunk is not yet loaded, the component throws a Promise. Suspense catches the thrown Promise and renders the fallback. When the Promise resolves (the chunk has downloaded), Suspense re-renders the tree with the actual component.

This is the same Suspense boundary you would use for data fetching. The behavior is identical: throw a Promise to signal "not ready," catch it at the nearest Suspense boundary, show fallback while waiting, render real content when ready.

// Suspense can wrap individual routes or the entire app
// Wrapping the whole app is simpler; wrapping per-route allows per-route fallbacks

// Per-route fallbacks (more control):
function App() {
  return (

        }
      />
      }>

          </Suspense>
        }
      />
    </Routes>
  );
}

For most applications, a single Suspense boundary around all routes is simpler and sufficient. The fallback can be a generic page loader or even null if you prefer a blank transition. The key constraint is that the Suspense boundary must be an ancestor of the lazy component in the React tree.

Verifying the split actually happened

The most common mistake with code splitting is thinking you have done it when you have not. Before assuming a React.lazy() conversion worked, verify it.

Method 1: Check the build output. Run npm run build and look at the output files. A successful route split produces separate chunk files:

dist/assets/index-a1b2c3.js       (main bundle, ~80KB)
dist/assets/Dashboard-d4e5f6.js   (dashboard chunk, ~45KB)
dist/assets/Settings-g7h8i9.js    (settings chunk, ~22KB)
dist/assets/AdminPanel-j0k1l2.js  (admin chunk, ~38KB)

If you see only one JavaScript file or if all your route components appear in index.js, the split did not happen.

Method 2: Use bundle analysis. With Vite, add the visualizer plugin:

// vite.config.ts

  plugins: [
    visualizer({ filename: 'bundle-stats.html', gzipSize: true })
  ]
};

After building, open bundle-stats.html. If the split worked, you will see your route components in separate rectangles outside the main bundle rectangle. If they are inside the main bundle, something went wrong.

Method 3: Check the Network tab. Open Chrome DevTools, go to the Network tab, filter by JS, and navigate between routes. When you navigate to a route for the first time, you should see a new JS file appear in the network requests. If no new files appear, the code was included in the initial bundle.

Why the split silently fails

Static imports elsewhere in the file. If you import a component from a file that is also imported statically somewhere in the main bundle, the component will be included in the main bundle regardless of your lazy() call. The bundler deduplicates modules, so a module that is reachable through a static import path will not be split out.

// This file statically imports Dashboard, so Dashboard is in the main bundle

// This lazy() call does nothing useful because Dashboard is already included
const DashboardLazy = lazy(() => import('./pages/Dashboard'));

Check that the component you are splitting is not imported anywhere else in the main bundle's dependency chain.

Eager imports in the entry point. The entry point (usually main.tsx or App.tsx) must not have static imports for the components you want to split.

// main.tsx: these static imports pull everything into the initial bundle

// All of these are now in the initial bundle regardless of lazy() usage below

If your entry file imports these components, remove those imports and rely entirely on React.lazy() for the route components.

Shared dependencies. If Dashboard and Settings both import a large shared library, that library goes into the main chunk (or a separate vendor chunk) rather than being duplicated in each route chunk. This is correct behavior and not a failure. The route chunks will be smaller than you expect because shared code is extracted automatically.

Named chunks for production debugging

By default, bundlers generate hash-based chunk names like chunk-d4e5f6.js. These are stable for caching but unreadable in production error logs.

Add a magic comment to name chunks:

const Dashboard = lazy(() =>
  import(
    /* webpackChunkName: "dashboard" */
    './pages/Dashboard'
  )
);

// In Vite, use vitePreload (Vite handles naming automatically based on file names in most cases)
// But you can also add rollupOptions in vite.config.ts to control chunk naming

With named chunks, your build output becomes:

dist/assets/dashboard-d4e5f6.js
dist/assets/settings-g7h8i9.js
dist/assets/admin-panel-j0k1l2.js

Production stack traces and network logs become readable.

Preloading chunks on hover to eliminate waterfall

The biggest UX issue with lazy loading is the delay when a user first navigates to a route. The sequence is: user clicks link, React renders null (Suspense fallback), browser fetches chunk, chunk executes, component renders. That network fetch adds latency.

The standard fix is to preload the chunk before the user clicks, triggered on hover or focus:

// Preload helper
function preloadComponent(factory) {
  const Component = lazy(factory);
  // Trigger the import() immediately (while hovering)
  // React.lazy caches the result, so when Suspense renders it, the chunk is ready
  Component.preload = factory;
  return Component;
}

const Dashboard = lazy(() => import('./pages/Dashboard'));

// In your nav link:
function NavLink({ to, children }) {
  const navigate = useNavigate();

  const handleMouseEnter = () => {
    // Trigger the chunk fetch when user hovers the link
    import('./pages/Dashboard');
  };

  return (
    <a
      href={to}
      onMouseEnter={handleMouseEnter}
      onFocus={handleMouseEnter}
    >
      {children}
    </a>
  );
}

When the user hovers a navigation link, the chunk download starts. By the time they click and React tries to render the route, the chunk is already in the browser's cache. The Suspense fallback either never shows or shows for under 100ms.

React Router v6 handles this through the loader pattern in the data router API. Next.js has built-in prefetching for <Link> components. For custom setups, the hover-triggered import approach above covers most cases.

The numbers in practice

Here is a realistic example from a mid-size React application before and after route splitting:

Route	Before (included in initial bundle)	After (separate chunk, loaded on demand)
Homepage	1.2MB total initial JS	85KB initial bundle
Dashboard	(already loaded)	245KB, loads when user navigates
Settings	(already loaded)	78KB, loads when user navigates
Admin Panel	(already loaded)	312KB, loads when user navigates
Reports	(already loaded)	168KB, loads when user navigates

A user who only uses the homepage never downloads the Dashboard chunk. A user who does use the dashboard downloads 245KB for it specifically, rather than getting it bundled with everything else. The browser can also cache each chunk separately, so after a first visit to the dashboard, subsequent visits serve it from cache regardless of whether the main bundle changed.

The improvement in Time to Interactive for first-time visitors is proportional to how much of the pre-split bundle was route-specific code. In applications with many routes and large per-route dependencies, the improvement can be dramatic. In small applications with 3 routes and shared components, the split saves less. Measure your bundle before and after to know if the split is worth the added complexity.

Read the original article on Renderlog.in:
https://renderlog.in/blog/react-lazy-route-code-splitting-guide/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Skeleton Screens vs Spinners: Perceived Load Time

Ashish Kumar — Sun, 10 May 2026 00:30:00 +0000

Related: Core Web Vitals and Lighthouse Explained covers how Google measures performance in the field, including how perceived performance metrics like INP differ from load metrics.

Two pages load in exactly the same amount of time. One shows a spinner. The other shows a skeleton screen. Users consistently rate the skeleton screen page as faster, even when it is not. This is not a quirk or a fluke. LinkedIn documented it, researchers replicated it, and it has a straightforward neurological explanation. Understanding why it works also explains when it does not, and why getting this wrong can make a genuinely fast page feel slow.

What this covers: Why spinners and skeleton screens produce different perceived wait times at identical actual load times, what LinkedIn's research found, when to use each pattern, and a CSS-only skeleton implementation that does not require a library.

The LinkedIn research

In 2013, LinkedIn redesigned their mobile apps and faced a choice about loading states. Their design team, led by Luke Wroblewski who later wrote about this extensively, ran studies comparing spinner-based loading with skeleton screens.

The finding: users perceived pages with skeleton screens as loading faster than identical pages with spinners, even when measured load time was exactly the same.

The explanation comes from cognitive psychology. A spinner communicates "something is happening, wait." It gives no information about what is coming. The brain is in an open-ended wait state, which feels longer than a wait with a defined endpoint.

A skeleton screen communicates structure. The brain sees a page layout without content and begins filling in predictions about what will appear. By the time the content arrives, the brain has already partially processed the layout. The content arrival feels more like "confirmation" than "loading complete." The subjective experience of waiting is compressed.

This is the same principle that makes progress bars feel faster than indefinite spinners, and why seeing "2 minutes remaining" on a file download feels better than "calculating..." even though knowing the duration does not change it.

What the brain actually does during a skeleton screen

When users see a skeleton screen, they are not passively waiting. They are pattern-matching.

The brain's visual system recognizes layout shapes before it recognizes content. When you see gray rectangles in the shape of a card with a title area and a thumbnail placeholder, you already know you are looking at a list of articles or products. Your attention moves to where the interesting content will appear. When the content loads, your eye is already in position.

With a spinner, there is nothing to pattern-match against. No layout information has arrived. The entire page is an unknown. The user's attention has nowhere to go.

The practical result: skeleton screens reduce the cognitive cost of waiting, even when they do not reduce the actual wait. The user feels more in control of the interaction, and perceived control reduces perceived wait time.

When spinners are correct

Skeleton screens are not always better. There are situations where a spinner is the right choice and a skeleton screen would be wrong or even counterproductive.

Short waits under 300ms. Skeleton screens require the user to notice the skeleton, process it, and then see it replaced by content. For operations that complete very quickly, this flicker of skeleton-then-content is more disruptive than a brief spinner, or nothing at all. The general rule is that anything under 300ms should show no loading state, anything between 300ms and 1 second can use a skeleton, and only operations that reliably take more than 1 second benefit clearly from the skeleton pattern.

Unpredictable content shapes. Skeleton screens only work when you know roughly what the loaded content will look like. If the content shape depends on the data (for example, a query that might return a single result or a table of 50 results), you cannot sketch a meaningful skeleton. A generic gray rectangle that looks nothing like the eventual content provides no layout preview benefit.

Actions with binary outcomes. For a form submission that either succeeds or shows an error, a skeleton screen is misleading. The user does not want a preview of the success state while waiting for confirmation that the action worked. A spinner correctly communicates "outcome is pending."

Destructive or confirmation operations. "Deleting..." should show a spinner. Showing a skeleton of the content-less state while a delete processes would be confusing.

The three-tier timing model

A practical framework for choosing loading states based on expected wait time:

Wait time	Pattern	Reason
Under 100ms	Nothing	Response feels instant, loading state adds flicker
100ms to 300ms	Optional subtle fade	May be perceived as lag; brief indicator acceptable
300ms to 1000ms	Skeleton screen	Long enough to notice; layout preview reduces anxiety
Over 1000ms	Skeleton screen with progress hint	User needs reassurance that something is happening
Indeterminate long wait	Progress bar or spinner with status text	When skeleton does not map to the content shape

The key insight is that loading states are not about communicating "loading." They are about managing user anxiety during a gap. Skeleton screens manage anxiety by filling the gap with useful information. Spinners manage anxiety by confirming that the system is working. Both are valid anxiety-management tools, just for different scenarios.

A CSS-only skeleton implementation

Skeleton screens do not require a library. A pulsing animation with CSS is sufficient for most use cases.

/* Base skeleton styles */
.skeleton {
  background-color: #e2e8f0;
  border-radius: 4px;
  position: relative;
  overflow: hidden;
}

/* The shimmer animation */
.skeleton::after {
  content: '';
  position: absolute;
  top: 0;
  left: 0;
  right: 0;
  bottom: 0;
  background: linear-gradient(
    90deg,
    transparent 0%,
    rgba(255, 255, 255, 0.4) 50%,
    transparent 100%
  );
  animation: shimmer 1.5s ease-in-out infinite;
  transform: translateX(-100%);
}

@keyframes shimmer {
  to {
    transform: translateX(100%);
  }
}

<!-- Article card skeleton -->
<div class="skeleton-card">
  <div class="skeleton" style="width: 100%; height: 200px; margin-bottom: 12px;"></div>
  <div class="skeleton" style="width: 80%; height: 20px; margin-bottom: 8px;"></div>
  <div class="skeleton" style="width: 60%; height: 16px; margin-bottom: 8px;"></div>
  <div class="skeleton" style="width: 40%; height: 14px;"></div>
</div>

The shimmer effect (the light that sweeps across the skeleton) serves a purpose beyond aesthetics. It signals motion, which confirms to the user that the page is alive and loading. A static gray block with no animation is harder to distinguish from a broken or empty state.

Skeleton screens in React

In a React application, skeleton screens are typically implemented as separate components that match the shape of the loaded content.

// The loaded state
function ArticleCard({ article }) {
  return (
    <div className="card">
      ![](https://renderlog.in)
      <h2>{article.title}</h2>
      <p>{article.excerpt}</p>
      <span>{article.readingTime} min read</span>
    </div>
  );
}

// The skeleton state -- same layout structure, no real content
function ArticleCardSkeleton() {
  return (
    <div className="card">
      <div className="skeleton" style={{ width: '100%', height: '200px' }} />
      <div className="skeleton" style={{ width: '80%', height: '24px', marginTop: '12px' }} />
      <div className="skeleton" style={{ width: '100%', height: '16px', marginTop: '8px' }} />
      <div className="skeleton" style={{ width: '40%', height: '14px', marginTop: '8px' }} />
    </div>
  );
}

// The parent component that chooses which to render
function ArticleFeed() {
  const { data, isLoading } = useArticles();

  return (
    <div className="feed">
      {isLoading
        ? Array.from({ length: 3 }).map((_, i) => )
        : data.map(article => )
      }
    </div>
  );
}

The skeleton component mirrors the layout structure of the real component. The closer the skeleton matches the eventual content shape, the stronger the cognitive priming effect. A skeleton that looks nothing like the content (generic gray blocks with wrong proportions) provides little benefit over a spinner.

The mistake that makes skeletons worse than spinners

The biggest failure mode for skeleton screens is showing them when the data loads fast enough that the skeleton is visible for under 200ms. The sequence becomes: blank page, skeleton flash, content. That flash is worse than a spinner because it represents unnecessary visual complexity.

The fix is a minimum display time or a delayed render:

function ArticleFeed() {
  const { data, isLoading } = useArticles();
  const [showSkeleton, setShowSkeleton] = useState(false);

  useEffect(() => {
    if (isLoading) {
      // Only show skeleton if loading takes more than 300ms
      const timer = setTimeout(() => setShowSkeleton(true), 300);
      return () => clearTimeout(timer);
    } else {
      setShowSkeleton(false);
    }
  }, [isLoading]);

  if (isLoading && !showSkeleton) return null;
  if (isLoading && showSkeleton) return ;
  return data.map(article => );
}

With this approach, fast data loads (under 300ms) show nothing and content appears cleanly. Slow loads show the skeleton after the threshold. Users never see the flash.

Perceived performance is real performance

Lighthouse scores and Core Web Vitals measure objective timing. They matter and correlate with user satisfaction at scale. But the experience of waiting is subjective, and subjective experience is what determines whether a user comes back.

A page with a 2 second LCP and a well-implemented skeleton can feel faster than a page with a 1.5 second LCP and a spinner, if the skeleton communicates layout structure clearly and the content arrival matches the preview. That gap between measured and perceived performance is where skeleton screens operate.

LinkedIn bet their mobile redesign on this insight. The research held up. The pattern has been standard practice at every major product company since.

Read the original article on Renderlog.in:
https://renderlog.in/blog/skeleton-screens-vs-spinners-perceived-performance/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

srcset and sizes: How the Browser Picks Images

Ashish Kumar — Sat, 09 May 2026 00:30:00 +0000

Related: What loading="lazy" Does and Why Google Added It to the HTML Spec covers the other half of image loading behavior that pairs with responsive image selection.

A user on a 375px iPhone with a 3x retina display viewing your site on 4G should get a different image file than a user on a 1440px desktop with a 1x monitor on a slow hotel WiFi connection. These two users have completely different needs: one wants a sharp image at a small size, the other wants a smaller file at a large size. Without srcset and sizes, they both get the same file, and at least one of them is getting it wrong.

What this covers: Why a single image URL cannot serve all devices correctly, what the srcset and sizes attributes actually tell the browser, how the browser's selection algorithm works, and the common mistakes that make the whole system silently fail.

The problem with a single image URL

When you write <img src="/hero.jpg">, every visitor to your page downloads the same file regardless of their device, screen size, or connection speed.

For a full-bleed hero image that looks good on a 4K monitor, you might need a 2400px wide image. On a 375px phone, that same image takes four times more bandwidth to download than needed. The phone then scales it down to 375px, discarding all that extra data. You paid for data that was thrown away.

The inverse is also a problem. If you serve a small image to save bandwidth, it looks blurry on high-density displays like Retina screens because those screens pack 2x or 3x more pixels into the same physical space and need a proportionally larger image to fill them sharply.

<!-- Every device gets the same 2400px image. Wrong. -->
![Hero image](https://renderlog.in/hero-2400.jpg)

The solution is not to pick one compromise image. The solution is to tell the browser about all your image options and let it pick the right one based on information it already has: the viewport size, the device pixel ratio, and the connection speed.

What srcset actually tells the browser

The srcset attribute is a comma-separated list of image candidates. Each candidate has a URL and a width descriptor that tells the browser how wide that image file is in pixels.

![Hero image](https://renderlog.in/hero-800.webp)

The w unit after each number is the intrinsic width of that image file. It is not the display width. It is saying: "this file, when you open it, is 800 pixels wide." That is a fact about the file, not an instruction to the browser.

The src attribute is the fallback for browsers that do not understand srcset. Old browsers ignore srcset and use src instead. Always include it.

Without a sizes attribute, the browser assumes the image will be displayed at 100% of the viewport width. That assumption is wrong for almost every real layout, which is why sizes exists.

What sizes tells the browser

sizes tells the browser how wide the image will actually appear on screen at different viewport sizes. It uses the same media query syntax as CSS.

![Hero image](https://renderlog.in/hero-800.webp)

Reading the sizes value here: if the viewport is 768px or narrower, the image takes up 100% of the viewport width. If the viewport is between 768px and 1200px, the image takes up 50% of the viewport width. Otherwise, the image is exactly 1200px wide (capped by a max-width container).

The browser reads sizes before it has applied any CSS. This is intentional. The browser preloader runs very early in the parsing process, before stylesheets are downloaded, to get image requests into the network queue as soon as possible. It cannot wait for CSS to be parsed to know image display sizes. So you, the developer, tell it the answer ahead of time through sizes.

The selection algorithm

Given srcset and sizes, the browser calculates which image to fetch like this:

Evaluate the sizes conditions against the current viewport width to get the rendered width (call it W)
Multiply W by the device pixel ratio (DPR) to get the needed pixels (call it P)
Pick the smallest image from srcset that is at least P pixels wide

For a concrete example: viewport is 375px wide, DPR is 3x, sizes says 100vw at this breakpoint.

Rendered width W = 375px
Needed pixels P = 375 x 3 = 1125px
Available candidates: 400w, 800w, 1200w, 2400w
Smallest that is at least 1125px wide: 1200w
Browser fetches /hero-1200.webp

Without srcset and sizes, that same device would fetch /hero-2400.webp, downloading 4x more data than it needs to render a sharp image.

On a 1440px desktop with 1x DPR where the image appears at 50% viewport width:

Rendered width W = 720px
Needed pixels P = 720 x 1 = 720px
Smallest candidate at least 720px: 800w
Browser fetches /hero-800.webp

A desktop user on a 1x monitor is downloading a smaller file than an iPhone user, because the desktop user does not need the extra pixels that a retina display requires.

The picture element for format switching

srcset on a plain <img> handles size selection but not format selection. For that, you use the <picture> element, which lets you offer different formats with explicit priority order.

<picture>
  <source
    type="image/avif"
    srcset="
      /hero-400.avif   400w,
      /hero-800.avif   800w,
      /hero-1200.avif 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  <source
    type="image/webp"
    srcset="
      /hero-400.webp   400w,
      /hero-800.webp   800w,
      /hero-1200.webp 1200w
    "
    sizes="(max-width: 768px) 100vw, 1200px"
  />
  ![Hero image](https://renderlog.in/hero-1200.jpg)
</picture>

The browser works through <source> elements in order, picks the first one it supports, and applies the same size selection algorithm from srcset. A browser that supports AVIF gets AVIF at the right size. A browser that does not falls through to WebP. If neither is supported, the <img> fallback loads the JPEG.

Common mistakes that make this silently fail

Using pixel density descriptors instead of width descriptors. There is a second descriptor syntax that uses x instead of w, like srcset="/hero-2x.jpg 2x". This only handles DPR, not viewport size. It is the older syntax and far less flexible. Use w descriptors with sizes instead.

<!-- Older approach: only handles DPR, ignores viewport size -->
![Hero](https://renderlog.in/hero.jpg)

<!-- Better: handles both DPR and viewport size -->
![Hero](https://renderlog.in/hero-800.jpg)

Wrong sizes values. If your sizes attribute says 100vw but the image is actually displayed at 50% of the viewport inside a two-column layout, the browser will fetch a file twice as large as needed. Get the rendered width right, even if it means inspecting the layout in DevTools to measure the actual computed width at each breakpoint.

Skipping sizes entirely. Without sizes, the browser assumes the image is 100vw. On a 1440px desktop with a two-column layout where your image is actually 600px wide, the browser fetches a 1440px image. The default assumption is almost always too large for content images.

Not including the image dimensions. Without width and height on the <img> element, the browser cannot reserve space for the image before it loads. When the image arrives, the page reflows and you get Cumulative Layout Shift. This applies whether you use srcset or not, but it is especially visible with lazy-loaded responsive images because the load is intentionally deferred.

What about CSS background images?

srcset and sizes only work on <img> elements and <source> elements inside <picture>. CSS background images do not benefit from this system at all.

For responsive CSS background images, the only native option is image-set():

.hero {
  background-image: image-set(
    url('/hero-800.webp') 1x,
    url('/hero-1600.webp') 2x
  );
}

image-set() is less flexible than srcset because it only handles DPR, not viewport size. For hero sections or any prominent image, using an <img> element with proper srcset and sizes is almost always the better choice over a CSS background image.

Generating responsive images in practice

Manually creating and maintaining multiple resized versions of every image is not practical at scale. The standard approach is to generate them automatically:

Vite and Astro both have image optimization plugins that generate multiple sizes at build time from a single source image. Astro's <Image> component handles srcset generation automatically when you specify a widths prop.

Next.js provides an <Image> component that generates srcset and handles format selection automatically, including on-demand resizing through its image optimization API.

CDN image optimization services like Cloudinary, Imgix, and Cloudflare Images let you request any size via URL parameters and serve the optimal format based on the Accept header. You store one original image, the CDN handles the rest.

The common thread is that the developer should not be manually maintaining five versions of every image. The build tool or CDN should generate them. What the developer needs to understand is srcset and sizes so they know what the tool is doing and can write the right configuration.

The performance case in numbers

Device	Without srcset	With srcset	Savings
iPhone 13 (375px, 3x)	2400px image, ~420KB	1200px image, ~95KB	77%
iPad (768px, 2x)	2400px image, ~420KB	1600px image, ~165KB	61%
1080p desktop (1x)	2400px image, ~420KB	1200px image, ~95KB	77%
4K desktop (2x)	2400px image, ~420KB	2400px image, ~420KB	0%

The only device in this table that should download the full 2400px image is the 4K display with a 2x DPR where the image fills the viewport. Every other device is paying for data that gets discarded after the browser scales the image down. srcset and sizes stop that from happening.

Read the original article on Renderlog.in:
https://renderlog.in/blog/srcset-sizes-responsive-images-explained/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

What loading=lazy Does: Browser Lazy Loading

Ashish Kumar — Fri, 08 May 2026 00:30:00 +0000

Related: Images, Fonts, and Third-Party Scripts: LCP and CLS Killers covers the full image performance picture including format selection and preloading strategies.

If you have ever added loading="lazy" to an image tag without knowing exactly what it does, you are not alone. Most developers copy it from tutorials and move on. But there is a specific reason Google added it to the HTML spec, there is a specific mechanism that makes it work, and there are two situations where using it will actively hurt your performance scores instead of helping them.

What this covers: Where the browser's default image loading behavior falls short, what Google found in their 2019 profiling study, how the browser calculates when to start fetching a lazy image, and the two cases where loading="lazy" should never appear.

Why this attribute exists at all

Before loading="lazy" was part of the HTML spec, developers who wanted to defer offscreen image loads had to write JavaScript. The standard approach was to use IntersectionObserver, set the real src on a data attribute, and swap it in when the image entered the viewport.

// The JavaScript-based lazy loading pattern from before 2019
const images = document.querySelectorAll('img[data-src]');

const observer = new IntersectionObserver((entries) => {
  entries.forEach(entry => {
    if (entry.isIntersecting) {
      const img = entry.target;
      img.src = img.dataset.src;
      observer.unobserve(img);
    }
  });
});

images.forEach(img => observer.observe(img));

This pattern worked, but it had a problem: the JavaScript had to be downloaded and executed before any images could be lazily loaded. If the script was render-blocking or deferred, you had a window where images loaded eagerly anyway. If the user had JavaScript disabled, every image loaded immediately regardless.

Google's Chrome team looked at how images were actually being loaded across the web. Their profiling found that images below the fold were responsible for 30 to 50 percent of initial bandwidth on median web pages. These are images the user may never see, especially on long pages where the majority of visitors never scroll past the first two screens.

They proposed a native solution: a browser-level attribute that requires no JavaScript, loads before any scripts run, and degrades gracefully when JavaScript is unavailable. The W3C standardized it, and Chrome shipped it in version 77 in September 2019. Firefox followed in version 75. Safari added it in 15.4.

How the browser decides when to fetch a lazy image

When you add loading="lazy" to an image, the browser does not simply wait until the image is in the viewport to start fetching it. It uses a distance-from-viewport threshold that varies based on the connection speed.

On a fast connection, Chrome starts fetching a lazy image when it is within 1250px of the viewport. On a slow connection (2G, slow-3G), that threshold drops to 2500px. The idea is that on a slow connection, the browser needs more lead time to fetch the image before the user scrolls to it.

This is why lazy loading does not cause a visible flash or delay on most scroll interactions. By the time most users scroll down, the browser has already started fetching the image that is about to appear.

<!-- This image starts loading when it is ~1250px below the viewport -->
![Article thumbnail](https://renderlog.in/blog/thumbnail.webp)

The threshold is implemented inside the browser's network stack, not in JavaScript. That means it runs before any of your application code, and it runs even when JavaScript is completely disabled.

What the browser does with the saved bandwidth

The bandwidth saved from not loading below-fold images is not wasted. The browser reallocates it to higher-priority resources: your CSS, your fonts, your LCP image, and your JavaScript. On pages with many images, the cascade effect is significant.

A page with 12 images where only 3 are above the fold saves 9 image fetches from the initial network queue. Those freed connections let critical resources load faster. First Contentful Paint improves. LCP improves. Time to Interactive improves.

The exact gains depend on the page and the connection, but Google's own measurements showed that adding loading="lazy" to below-fold images on the Chrome developer documentation site reduced the total bytes downloaded on the initial load by around 40 percent.

The two situations where you should never use it

The LCP image. The Largest Contentful Paint element is usually the hero image or the first content image on the page. If you add loading="lazy" to it, the browser will defer fetching it until it calculates that the image is close to the viewport, which happens after layout is complete, which is after CSS is parsed, which can be several hundred milliseconds into the page load.

On a fast connection with a small HTML document, this barely matters. On a slow connection or a page with a large HTML document, this difference can push LCP from 2 seconds to 5 seconds.

<!-- Never do this for your LCP image -->
![Hero](https://renderlog.in/hero.webp)

<!-- Do this instead -->
![Hero](https://renderlog.in/hero.webp)

Images in the first screenful without a known position. If an image is placed early in the HTML but its final position depends on CSS that has not loaded yet, the browser cannot calculate whether it is in the viewport. It may incorrectly defer the fetch. If the image turns out to be above the fold once layout completes, you will see a visible pop-in.

The fix in both cases is loading="eager", which is the browser's default for images anyway. You are not doing anything special with it, you are just being explicit that this image should not be deferred.

The width and height attributes are required

When you defer an image load, the browser does not know the image dimensions until it fetches the image. If it does not know the dimensions, it renders the image as 0x0 and then expands it when the image loads. That expansion shifts the content below it, causing Cumulative Layout Shift.

The fix is straightforward: always include width and height on every image, lazy or not.

![Diagram showing the rendering pipeline](https://renderlog.in/article/diagram.png)

With explicit dimensions, the browser reserves the exact space for the image before it loads. When the image arrives, nothing shifts. This applies to all images, but it matters most for lazy-loaded ones because the fetch is deferred and the gap between "image slot appears" and "image arrives" is longer.

Browser support and the polyfill situation

Native loading="lazy" is supported in Chrome 77+, Firefox 75+, Edge 79+, and Safari 15.4+. That covers somewhere around 95 percent of global browser usage as of 2026.

For the remaining 5 percent (primarily older Safari versions and some legacy Android browsers), the browser simply ignores the attribute and loads images normally. This is the correct degraded behavior. The page still works, images still load, you just lose the performance benefit.

No polyfill is required for production use. The progressively enhanced behavior is exactly what you want.

If you specifically need to support very old browsers and want lazy loading there too, the lazysizes library implements the IntersectionObserver approach as a fallback. But for most applications, the native attribute is sufficient and simpler.

Quick reference

Image position	loading attribute	fetchpriority
Hero / LCP image	`eager`	`high`
Above the fold, not LCP	`eager`	(omit)
Below the fold	`lazy`	(omit)
Deep in page (below 2 screens)	`lazy`	(omit)

The rule is simple: anything the user sees without scrolling gets loading="eager". Everything else gets loading="lazy". The default browser behavior without the attribute is to load everything eagerly, which is why the attribute exists in the first place.

One attribute, no JavaScript, no library dependency, immediate performance improvement. The reason Google pushed it into the spec is that this pattern was so universally correct that it should not require developer effort to implement on every site individually.

Read the original article on Renderlog.in:
https://renderlog.in/blog/loading-lazy-html-attribute-how-it-works/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

Lighthouse 100 and Still Crashes: OOM Explained

Ashish Kumar — Thu, 07 May 2026 00:30:00 +0000

A Lighthouse score of 100 means the page loads efficiently in a clean, synthetic test environment; it says nothing about what happens after 6 hours of continuous use — a hundred route navigations, thousands of polling cycles, and a React Query cache holding responses that should have been evicted hours ago.

Why lab metrics miss this: Lighthouse runs a single page load on a clean browser instance. It cannot measure heap growth rate, memory fragmentation, or tab survival probability on a 3GB Android device. OOM tab crashes don't produce JavaScript errors — the renderer process just dies.

What this covers: What OOM crashes actually are and why Chrome's tab limits differ by device, why long-lived SPAs accumulate memory (route state, unbounded caches, subscription leaks), how to monitor heap growth in production, and strategies that keep apps stable over 8-hour sessions.

The Lab vs Field Gap

Lighthouse runs a single, synthetic page load on a clean browser instance with simulated throttling. It measures what happens during that load LCP, CLS, TBT, FID, and overall performance and produces a score. For what it measures, it's accurate and useful.

What it doesn't measure:

Not measured by Lighthouse	Why it matters
Memory growth over time	Long-lived apps accumulate heap
Memory after 100 navigations	SPAs never fully unload between routes
GC pressure under sustained load	Polling loops cause GC pauses over hours
Memory fragmentation	Old generation becomes fragmented; GC is less effective
Tab survival on low-RAM devices	Chrome kills tabs proactively on 2GB-RAM phones

The Core Web Vitals field data in CrUX (Chrome User Experience Report) does capture real users, but it captures the load experience of those users, not their session survival rate. There's no CrUX metric for "tab was killed by the OS after 4 hours." That data simply doesn't exist in any aggregate form you can easily access.

This creates a dangerous blind spot. You can achieve a perfect Lighthouse score and still be shipping software that degrades and crashes for users who use it the way internal tools get used all day, every day, with the same tab.)

What an OOM Tab Crash Actually Is

OOM stands for out of memory. In Chrome, each tab runs in its own renderer process with a memory limit. When the heap grows beyond that limit, Chrome's renderer terminates the process and shows the user an "Aw, Snap!" error page.

The limit isn't a fixed number. Chrome sets it dynamically based on:

The total available system RAM
How many other tabs are open
Chrome's own heuristics for memory pressure

On a desktop machine with 16GB RAM and only a few tabs open, a single tab can use 2-4GB before Chrome kills it. On a mobile device with 3GB RAM running multiple apps, Chrome may proactively kill background tabs (not even the active one) when the system is under memory pressure.

The performance.memory API (Chrome only, non-standard) exposes some of these limits:

if (performance.memory) {
  console.log({
    // Total heap size V8 has allocated (committed memory)
    totalJSHeapSize: performance.memory.totalJSHeapSize,
    // How much of that heap is actually in use by JS objects
    usedJSHeapSize: performance.memory.usedJSHeapSize,
    // The hard limit  heap cannot grow beyond this
    jsHeapSizeLimit: performance.memory.jsHeapSizeLimit,
  });
}

On a typical desktop Chrome, jsHeapSizeLimit is around 4GB. On Android Chrome on a 3GB device, it's often 512MB-1GB. When usedJSHeapSize approaches jsHeapSizeLimit, the tab is on the edge of an OOM crash.

Mobile RAM: The Real Constraint

The operations team using the dashboard I mentioned were on desktop machines. But the majority of web traffic globally is on mobile, and mobile RAM constraints are severe.

Chrome on Android uses the following rough thresholds for tab killing (these aren't official numbers they're inferred from behavior and reported by developers and researchers):

Device RAM	Approx. tab heap limit	Background tab kill threshold
1 GB	~150-200MB	~50MB
2 GB	~250-350MB	~100MB
3 GB	~400-500MB	~200MB
4 GB+	~700MB+	~300MB

On a 2GB Android device still common in many markets a tab that uses 300MB of heap will be proactively killed by Chrome when the user switches to another app. When they switch back, Chrome reloads the tab from scratch, losing all state. Users experience this as "the page keeps refreshing."

For apps that need to survive on mobile, 150-200MB is a realistic heap budget to aim for in steady state. This is much tighter than desktop, and it rules out certain architectural decisions like caching every API response in memory indefinitely.

Why Long Sessions Break Apps That Pass Lighthouse

Accumulated Route State

React Router and Next.js don't fully unmount pages on navigation in SPAs. The framework manages route transitions, but unless you're explicitly code-splitting and unloading modules, the JavaScript for visited routes stays loaded. More importantly, React components that were mounted may hold state in closures, context, or stores.

Consider a dashboard with 20 different report views. After visiting all 20, the user has accumulated the component trees, data structures, and side effects of all 20 pages. If any of those pages has a memory leak (even a small one), it compounds with each visit.

Cache Without Eviction

React Query and SWR are excellent data fetching libraries. Their defaults are also memory-addictive for long-running apps. React Query, by default, keeps cached data in memory for 5 minutes after it's no longer actively used. In a dashboard that queries 200 unique order IDs over a day of use, that's 200 cached responses held in memory simultaneously.

// React Query default: caches everything for 5 minutes
const queryClient = new QueryClient();

// Tuned for long-lived apps
const queryClient = new QueryClient({
  defaultOptions: {
    queries: {
      staleTime: 30_000,     // data is fresh for 30s
      gcTime: 60_000,        // remove from cache after 1 minute of disuse (was cacheTime in v4)
    },
  },
});

Reducing gcTime from 5 minutes to 1 minute sounds minor. Over 8 hours of active use, it's the difference between holding thousands of cached responses and holding only the last few minutes of data.

Event Listener and Subscription Accumulation

Even small leaks compound over time. An event listener that's not removed on component unmount is tiny maybe a few KB of retained closures. After 500 route navigations (common in a full workday), those small leaks add up to hundreds ofMB.

I covered this in detail in the React Memory Leaks post, but the time dimension is what makes it a production crash issue vs a development curiosity. In a unit test or Lighthouse run, the component mounts once and unmounts once. In 8 hours of use, it might mount and unmount 300 times.

Diagnosing Production OOM

OOM crashes are hard to diagnose because they don't produce a JavaScript error. The renderer process just dies. There's no stack trace, no error boundary trigger, no Sentry event.

Field signals to watch for:

Session duration distribution: if your analytics shows a spike in session ends at 3-4 hours, users are being kicked out (either by OOM or by giving up on a slow app)
Navigation abandonment: if users stop navigating after a certain number of route changes, the app may be degrading
performance.memory logging: log usedJSHeapSize periodically (every 5 minutes) to your analytics service. Over time this builds a picture of heap growth rate per user type

// Log memory usage every 5 minutes to your analytics service
function startMemoryMonitoring() {
  if (!performance.memory) return; // Chrome only

  setInterval(() => {
    const { usedJSHeapSize, jsHeapSizeLimit } = performance.memory;
    const usagePercent = (usedJSHeapSize / jsHeapSizeLimit) * 100;

    analytics.track("memory_usage", {
      usedMB: Math.round(usedJSHeapSize / 1024 / 1024),
      limitMB: Math.round(jsHeapSizeLimit / 1024 / 1024),
      usagePercent: Math.round(usagePercent),
    });

    // Warn if approaching limit
    if (usagePercent > 80) {
      console.warn(`Heap at ${usagePercent.toFixed(0)}% of limit`);
    }
  }, 5 * 60 * 1000);
}

The PerformanceObserver type: 'memory' API (Chrome M89+) provides a more event-driven approach:

if (PerformanceObserver.supportedEntryTypes.includes("memory")) {
  const observer = new PerformanceObserver((list) => {
    for (const entry of list.getEntries()) {
      console.log("Memory entry:", entry);
    }
  });
  observer.observe({ type: "memory" });
}

As of 2026 this API is still Chrome-only and not widely used, but it's the right long-term direction for memory monitoring.

Strategies for Long-Lived Apps

Route-Based Code Splitting and Proper Unmounting

React Router v6's <Outlet> and lazy loading ensure that route components are code-split. But code-splitting only controls the initial load once a module is loaded, it stays in memory. The more important mechanism is ensuring components fully unmount and release their state.

In practice this means auditing that route components don't hold global references, that their useEffect cleanups fire correctly, and that stores don't accumulate data from visited routes indefinitely.

LRU Cache Eviction

For any client-side cache, implement maximum size with LRU (least recently used) eviction:


const detailCache = new LRUCache({
  max: 50,                     // keep at most 50 items
  ttl: 1000 * 60 * 5,          // expire items after 5 minutes
  maxSize: 50 * 1024 * 1024,   // cap at 50MB total
  sizeCalculation: (value) => JSON.stringify(value).length,
});

lru-cache is the standard choice in the Node/browser ecosystem well-maintained, tiny, fast. For React Query, use the gcTime option as shown earlier.

Page Visibility API: Reduce Background Work

When the user switches tabs or minimizes the browser, there's no reason to keep polling APIs at full speed. The Page Visibility API lets you detect visibility changes:

document.addEventListener("visibilitychange", () => {
  if (document.hidden) {
    // Tab is hidden  reduce or stop background work
    queryClient.pauseMutations();
    stopPolling();
  } else {
    // Tab is visible again  resume
    queryClient.resumeMutations();
    startPolling();
    queryClient.invalidateQueries(); // fetch fresh data
  }
});

Stopping API polling when the tab is hidden also prevents stale data from accumulating in caches that aren't being actively evicted.

Idle Reload for Kiosks and Operational Dashboards

For dashboards that need to be 100% reliable over long periods, the nuclear option is a scheduled reload during periods of inactivity. This sounds crude but is genuinely effective for kiosk displays, NOC dashboards, and ops tooling:

function scheduleIdleReload(idleMinutes = 120) {
  let idleTimer;

  function resetTimer() {
    clearTimeout(idleTimer);
    idleTimer = setTimeout(() => {
      // User has been inactive for `idleMinutes`  reload the page
      window.location.reload();
    }, idleMinutes * 60 * 1000);
  }

  // Reset on any user interaction
  ["mousedown", "keydown", "touchstart", "scroll"].forEach((event) => {
    document.addEventListener(event, resetTimer, { passive: true });
  });

  resetTimer();
}

// Reload if idle for 2 hours
scheduleIdleReload(120);

With a 2-hour idle reload, a tab that's been left open all night reloads when the ops team comes in the morning. Fresh state, no accumulated heap. Combined with proper session restoration (saving the current view to sessionStorage), this is invisible to users.

A Memory Budget for Long-Running SPAs

Based on my experience with internal tools and operations dashboards, here's a rough budget that keeps long-running apps stable:

Category	Desktop Target	Mobile Target
Initial page load heap	< 50MB	< 30MB
Steady-state heap (after 1 hour)	< 150MB	< 80MB
Maximum acceptable heap	< 400MB	< 150MB
API response cache size	< 50MB	< 20MB

If your app exceeds the "maximum acceptable" column, it's at elevated risk of OOM on the target device class. Use performance.memory logging in production to measure where your real users actually land.

Lighthouse will never tell you about these numbers. It can't it doesn't run for an hour. But they're what determines whether your users can actually use your app through a full working day.

Reducing React Query gcTime from 5 minutes to 90 seconds, pausing polling on tab hide, and deploying an idle reload (4-hour threshold) are the three changes that keep most long-lived dashboards stable. Heap stays under 200MB for the full working day. Lighthouse score stays 100. It just isn't the metric that matters for this class of problem.

Read the original article on Renderlog.in:
https://renderlog.in/blog/lighthouse-100-still-crashes-memory/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in

How to Answer Frontend Performance Questions in Interviews

Ashish Kumar — Wed, 06 May 2026 00:30:00 +0000

"How do you optimize a slow React app?" is deceptively open-ended. Answer without structure and you'll spend five minutes on memoization, forget to mention network or memory, and leave the interviewer unsure whether you have a repeatable process or just a collection of tricks.

The framework that works is seven distinct problem areas, each with different root causes, different debugging tools, and different solutions. The right answer to a performance question starts with identifying which area is the actual bottleneck, because optimizing re-renders when the problem is network is wasted effort, and chasing bundle size when the tab is leaking memory doesn't move the needle.

What this covers: A complete framework for answering frontend performance questions in interviews, organized as seven areas that mirror how performance problems actually present in production code.

The framing I always start with

Before I get into any specific technique, I say something like this:

"I approach performance as seven distinct problem areas. Each has different root causes, different debugging tools, and different solutions. When I join a slow app, the first thing I do is identify which area is actually the bottleneck, because optimizing rendering when the problem is network is a waste of time."

That sentence alone signals structured thinking. Interviewers are pattern-matching for "does this person have a repeatable process, or do they just know individual tricks?"

Then I walk through the seven areas. Here's exactly how I explain each one.

How measurement ties the seven buckets together

Interviewers often like hearing that you classify before you optimize. I map symptoms to buckets so I do not “fix” re-renders when the real problem is LCP, or chase bundle size when the tab is leaking memory.

If the symptom looks like…	I look here first
Slow first paint, blank screen, huge JS	Build (#5), assets (#6), network (#3)
Janky scroll, input lag, stuttering animations	Main thread, frame budget, long tasks, re-renders (#2), sometimes huge DOM (#1, #4)
Fine in Lighthouse, bad on a cheap phone	Mobile DOM and paint cost (#4), images/fonts (#6)
Fine for five minutes, awful after an hour	Long-session memory (#7)

That table is not a script—it is a debugging compass. In a real job I confirm with DevTools (Performance, Network, Memory) or RUM. On the blog I wrote up the underlying models here:

The browser’s main thread and rendering pipeline: what actually runs per frame
The ~16.6 ms frame budget at 60 Hz: why “fast load” and “smooth runtime” are different problems
Core Web Vitals and Lighthouse: what LCP, CLS, and INP reward and what they miss
Long tasks and main-thread blocking: why INP and “jank” often trace to the same root cause
Performance hub: quick “how / why” reference: layout thrashing, will-change, passive listeners, and other one-liners you can name-check in an interview

1. Rendering large datasets

The situation: You have a list, table, or feed with thousands of rows (an order book, a data grid, an activity log). You render them all and the browser slows to a crawl.

How I explain the trade-offs:

The first thing I do is separate the three approaches, because teams often conflate them:

Approach	What it does	Best for
Pagination	Renders only one page of data at a time; user explicitly navigates	Read-heavy tables, URL-addressable records, SEO content
Infinite scroll	Appends more items as user scrolls; old items stay in DOM	Social feeds, content discovery, low-importance archives
Virtualization	Only renders viewport rows; DOM count stays constant regardless of data size	Real-time dashboards, large data grids, performance-critical lists

I always point out what most candidates miss: infinite scroll has a hidden DOM growth problem. Every appended batch stays in the DOM. After 50 batches, you have the same performance problem as rendering everything up front — just delayed by a few minutes of scrolling. I've seen "infinite scroll" ship as a performance fix that actually made things worse.

Virtualization is the real answer for truly large datasets. Libraries like react-window and TanStack Virtual render only the rows inside (or near) the viewport, keeping the DOM node count constant at ~20-50 nodes regardless of whether the dataset has 500 or 500,000 items.

The trade-offs worth mentioning in an interview: variable-height rows are harder to virtualize (you need a measurement strategy), screen readers can behave unexpectedly with windowed lists (you need aria-rowcount and aria-rowindex), and SSR hydration needs thought.

When the dataset is huge on the client or work is CPU-heavy, I briefly mention moving work off the main thread and using fast local I/O so the UI thread stays responsive—then I only go deep if they bite:

Web Workers in frontend and React: parsing, transforms, isolation from the DOM
Origin Private File System (OPFS): large blobs, streaming, pairing with workers

That keeps the answer honest for dashboards and editors without derailing a 45-minute loop into File System Access API details.

Deep dive: Large Lists: Pagination, Infinite Scroll, and Virtualization

2. Re-rendering issues

The situation: The app is slow during interaction — not on load. Something is causing too many components to re-render too often.

How I explain the debugging process:

I always start with the profiler, not the code. React DevTools Profiler shows you exactly which components re-rendered, how long each took, and, critically, why each re-rendered (prop change, state change, context change, parent re-render). Until you've looked at the profiler output, you're guessing.

The re-rendering mental model I use:

A component re-renders when:
1. Its own state changes
2. Its props change (by reference, not value — objects and functions are recreated every render)
3. A context it subscribes to changes
4. Its parent re-renders (unless wrapped in React.memo with stable props)

The most common production issue I find is context broadcasting — a context that changes frequently (live data, user interaction state) is consumed by a large subtree, causing everything to re-render on every update. The fix is splitting contexts by update frequency: separate the fast-changing data context from the slow-changing config context.

On React.memo, useMemo, and useCallback:

These are referential stability tools, not magic performance switches. React.memo wraps a component in a shallow prop comparison — if all props are the same reference as last render, the re-render is skipped. useCallback gives you a stable function reference across renders. useMemo memoizes a computed value.

The trap I see constantly: developers add useMemo and useCallback everywhere preemptively, adding overhead without benefit. You pay the cost of memoization (comparison + memory) on every render regardless of whether the memoization ever saves a re-render. Profile first. Memoize second.

If the conversation turns to keeping inputs responsive while a subtree is expensive, I add one layer: React 18’s concurrent features defer non-urgent updates so the main thread can still process typing and clicks. That is a different tool from memoization: scheduling**, not skipping work entirely.

Deep dives:

React Re-rendering: When and Why Component Trees Update
React.memo, useMemo, useCallback — When They Help vs Hurt
Concurrent React for perceived performance: startTransition, useDeferredValue, urgent vs deferred updates

3. Network optimization

The situation: The app makes too many requests, or makes them at the wrong time, or fetches data that's already available from a previous request.

How I explain the SPA network problem:

Single-page apps have a structural disadvantage vs server-rendered pages: data fetching happens in the browser, sequentially. You navigate to a route → component mounts → useEffect fires → fetch starts → data arrives → render. That's a full round-trip after every navigation. Stack nested routes that each fetch their own data and you get a waterfall — each fetch waits for the parent component's render before it even starts.

The pattern I always mention: move fetches out of components and into route loaders (React Router 6.4+ loaders, Next.js getServerSideProps/RSC). A route loader can start the fetch immediately when the user navigates — before the component tree even renders — and pass the data down as a resolved value. No useEffect, no loading spinner, no waterfall.

For data that doesn't change on every page load, stale-while-revalidate is the principle I use most. TanStack Query implements it well: return cached data immediately, revalidate in the background, update if something changed. Users see instant data; freshness is maintained. The key config knob is staleTime: how long before a cache entry is considered stale.

Caching strategy	Latency	Freshness	Right for
No cache (fetch on mount)	Network RTT on every load	Always fresh	Auth state, financial data
Stale-while-revalidate	Instant (cached) + background update	Slightly stale	Most UI data — profiles, feeds, configs
Cache-first with TTL	Instant until TTL expires	Stale until TTL	Mostly-static data — categories, settings
Immutable (by URL hash)	Instant indefinitely	Never updates	Build artifacts, versioned API responses

Other points I always bring up: request deduplication (two components requesting the same URL in the same render cycle should hit the network once, not twice; TanStack Query does this automatically), prefetching on hover before the user clicks, and fetchpriority="high" on LCP-critical resources.

Deep dive: Network Optimization for React SPAs

4. Mobile view optimization

The situation: The app works on a MacBook and a high-end phone. It's unusable on a mid-range Android. You've never actually tested it on one.

How I explain the mobile performance gap:

Desktop performance profiling is misleading. A MacBook Pro has 8–16 fast cores. A Redmi Note 9, which represents a huge portion of actual smartphone users globally, has 4 slower cores, 4GB RAM, and a V8 JavaScript engine running at maybe 20% the throughput of a desktop Chrome instance. The 6x CPU throttle preset in Chrome DevTools is a useful approximation but still optimistic for low-end devices.

The areas I focus on for mobile:

DOM size. Every DOM node has a cost: memory, style matching, hit testing. A style recalculation on a page with 500 nodes is fast. On a page with 5,000 nodes it's slow. On mobile it's noticeably slow. I audit DOM size with document.querySelectorAll('*').length and target under 1,500 nodes for complex pages.

content-visibility: auto is the highest-impact single CSS property I reach for on content-heavy mobile pages. It tells the browser to skip layout and paint for off-screen sections entirely; they're calculated only when they scroll into view. Combined with contain-intrinsic-size to give the browser a height estimate, it can cut initial render time dramatically on long pages.

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 400px; /* approximate height, prevents layout shift */
}

Passive event listeners. Touch and wheel event listeners delay scroll by default because the browser waits to see if preventDefault() is called. Adding { passive: true } tells the browser it can start scrolling immediately. This is one of the cheapest scroll performance wins available:

document.addEventListener('touchstart', handler, { passive: true });

Images. loading="lazy" for below-fold images, decoding="async", correct width and height attributes to prevent layout shift, and properly sized srcset so mobile devices don't download desktop-resolution images.

Deep dive: Mobile Web and DOM Performance

5. Build optimizations

The situation: The initial JavaScript payload is too large. Time to Interactive is slow because the browser is parsing and executing megabytes of JS before the app is usable.

How I explain the bundle problem:

Most apps I've worked on that had large bundles had the same root causes: no code splitting, importing entire libraries when they only needed one function, and barrel files that prevented tree shaking from working.

I always mention three things:

Bundle analysis first. Before optimizing anything, visualize what's actually in the bundle. rollup-plugin-visualizer (for Vite) and webpack-bundle-analyzer produce a treemap showing exactly how much each dependency contributes. Nine times out of ten, there's one or two giant libraries that shouldn't be there in their entirety: moment.js with all locale files, an unshaken icon library, a full lodash import.

Tree shaking requires ES modules. Tree shaking is static dead code elimination — the bundler can only remove exports that are provably unused. This only works with import/export syntax. CommonJS require() is dynamic, so bundlers can't statically analyze it. Libraries that ship CommonJS only are not tree-shakeable. Also critical: barrel files (index.js that re-exports everything) break tree shaking even for ES module libraries. The bundler sees an import chain to all exports and can't determine what's unused.

Route-level code splitting. React.lazy() + Suspense lets you split your bundle at route boundaries so users only download the code for the page they're on:

const Dashboard = React.lazy(() => import('./pages/Dashboard'));
const Settings = React.lazy(() => import('./pages/Settings'));

}>

</Suspense>

The impact is significant: a 2MB bundle becomes multiple 200-400KB chunks, and users only pay for the chunks they actually navigate to.

I also mention vendor splitting — separating stable third-party dependencies (React, router, component library) from frequently-changing app code. Stable vendor chunks get long-lived cache headers and don't invalidate when you ship a feature.

Deep dive: Build Bundles, Tree-shaking, and Code Splitting

6. Asset optimization

The situation: Large images are tanking LCP. Web fonts are causing layout shift. Third-party scripts are blocking the main thread.

How I explain each asset type:

Images and LCP. The largest contentful paint element is almost always an image. The most impactful single change for LCP is adding fetchpriority="high" to the hero image and a <link rel="preload"> in the <head>. The browser's preload scanner discovers the image earlier and prioritizes its download. Additionally: use WebP or AVIF (30-50% smaller than JPEG at equivalent quality), always set width and height to prevent CLS, and use loading="eager" on above-fold images (don't lazy-load your LCP element; I've seen this mistake in production).

Fonts and CLS. Web fonts cause two problems: invisible text during load (FOIT) and layout shift when the font swaps in. font-display: swap makes text immediately visible using the system fallback font, then swaps to the web font when it loads. This eliminates FOIT but can cause a brief layout shift. font-display: optional skips the swap entirely if the font isn't cached. There is no layout shift, but users may never see the custom font on a first visit. Which you choose depends on whether the brand cares more about CLS or visual consistency.

The highest-ROI font optimization most teams skip: subsetting. A full Latin font file might be 400KB. If your content only uses basic Latin characters, a subset can be 30-50KB. pyftsubset from the fonttools package does this at build time.

Third-party scripts. Google Tag Manager, chat widgets, analytics: these are often the biggest main-thread bottleneck on marketing sites. A GTM container that loads 12 tags synchronously in the <head> will block rendering for hundreds of milliseconds. The fix: load all third-party scripts with async or defer, move analytics to server-side where possible, and use the facade pattern for heavy embeds (YouTube, Intercom, maps): show a static thumbnail until the user interacts, then load the real widget on click.

Deep dive: Images, Fonts, and Third-Party Performance

7. Long session memory optimization

The situation: The app works fine on first load. After an hour of use, it's sluggish. After three hours, the tab crashes. Lighthouse still scores 100.

Why I always end with this:

Memory is the area most candidates don't mention at all, which makes bringing it up a reliable signal of production experience. Lighthouse doesn't catch memory problems — it runs a short synthetic test on a clean page. A tab that leaks 20MB per minute will crash in two hours but score perfectly in the lab.

The leak patterns I've hit in production React apps:

The most common one: a WebSocket or SSE subscription set up in a useEffect that doesn't clean up on unmount. The subscription holds a reference to the component's state setter, which holds a reference to the component's closure, which may hold references to large data structures. The component unmounts and navigation happens, but the subscription keeps firing and accumulates references that the GC can't collect.

useEffect(() => {
  const ws = new WebSocket(url);
  ws.onmessage = (e) => setState(JSON.parse(e.data));

  return () => ws.close(); // cleanup is critical — without this, you leak
}, [url]);

Other patterns: setInterval without clearInterval in cleanup, global Map or Set caches that grow unboundedly (store 100 items max, then evict the oldest), and third-party library subscriptions that need explicit unsubscribe() calls.

For long-running internal tools (dashboards that ops teams leave open all day), I also recommend:

Listening to the Page Visibility API and pausing heavy polling when the tab is hidden
Clearing inactive route caches on a timer (TanStack Query's gcTime does this automatically)
As a last resort: reload the tab after a configurable idle period (aggressive but effective for kiosk-style deployments)

Deep dives:

How I put it all together in the interview room

When the question is asked, I don't just list these seven areas — I sequence my answer to show how I actually work through a performance problem:

Clarify the scenario (15–20 seconds). “Is this first load, repeat navigation, or long-lived session?” “Mobile, desktop, or both?” “Do we have RUM or only lab?” That signals senior judgment—you are not solving a different company’s app than the one they described.
Identify the symptom first. Slow load? Runtime jank? Crashes after extended use? Each points to a different area from the table above.
Measure before touching code. Chrome DevTools Performance panel for runtime, Network panel for requests, Memory panel for heap growth. I always say "I never optimize what I haven't measured."
Prioritize by user impact. A 500ms LCP improvement on the landing page affects every new visitor. A memory leak fix affects users who stay for hours. Both matter but they have different urgency.
Go area by area, don't thrash. Fixing re-renders while ignoring a 2MB bundle doesn't move the needle. Fixing network while the DOM has 10,000 nodes is partial progress. The seven areas interact — understand which one is the real bottleneck for your specific app.

Timeboxing: For a short behavioral question (“how do you approach performance?”), I hit the seven buckets + measurement in under two minutes and offer one concrete example from a past project. For a deep system design or debugging exercise, I walk one path end-to-end (e.g. “I’d open Performance, find long tasks, then inspect commit times in React Profiler…”) and name which bucket I ruled out and why.

STAR without sounding rehearsed: I keep Situation → bottleneck signal → what I measured → fix → outcome in my head. I do not say “STAR” out loud; I just tell the story in that order so the interviewer hears cause, evidence, and trade-offs.

The interviewer isn't looking for someone who knows every API. They're looking for someone who can look at a slow production app and work through it systematically without panicking. This framework is how I do that.

For the full index and deep dives, see the series hub.

Read the original article on Renderlog.in:
https://renderlog.in/blog/frontend-performance-interview-approach/

If you found this helpful, I've also built some free tools for developers and everyday users. Feel free to try them once:

JSON Tools: https://json.renderlog.in
Text Tools: https://text.renderlog.in
QR Tools: https://qr.renderlog.in