Forem: Ashish Kumar

Images, Fonts, Third-Party Scripts: LCP and CLS

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

Images, fonts, and third-party scripts are the three categories responsible for the most field LCP and CLS regressions. They interact: a 12KB GTM tag firing synchronously in <head> blocks the parser for 200ms, which means your hero image (already the LCP candidate) now loads 200ms later. LCP jumps from 1.8s to 4.2s. CrUX data reflects it three weeks later.

What this covers: fetchpriority and <link rel="preload"> for LCP images, WebP vs AVIF trade-offs, srcset/sizes resolution selection, font-display values and what each costs, font subsetting, and the facade pattern that eliminates third-party script cost entirely until user interaction.

Images and LCP: Why Your Hero Image Is Almost Always the Culprit

Largest Contentful Paint (LCP) measures when the largest visible element in the viewport finishes rendering. In most marketing sites, e-commerce pages, and landing pages, that element is an image: specifically the hero image above the fold.

The browser's default behavior for images is loading="lazy", which means it defers fetching images until they're near the viewport. For images below the fold, this is exactly right. For the LCP image, it is catastrophic.

<!-- Wrong: browser waits until layout is done to decide whether to fetch -->
![Hero](https://renderlog.in/hero.jpg)

<!-- Right: fetch immediately, highest network priority -->
![Hero](https://renderlog.in/hero.webp)

fetchpriority="high" is the piece most developers miss. Even with loading="eager", the browser's resource prioritization algorithm might assign the image a lower network priority if it's discovered late in the HTML parse: for example, if it's inside a JS-rendered component. fetchpriority="high" overrides this and tells the browser: this resource competes with critical CSS, treat it accordingly.

The most aggressive technique is a <link rel="preload"> in the document head. This fires before the HTML parser even reaches the <img> tag:

<head>
  <link
    rel="preload"
    as="image"
    href="/hero.webp"
    fetchpriority="high"
    imagesrcset="/hero-400.webp 400w, /hero-800.webp 800w, /hero-1200.webp 1200w"
    imagesizes="(max-width: 600px) 100vw, 1200px"
  />
</head>

Note the imagesrcset and imagesizes attributes on the <link>: these match your <img> element's srcset and sizes so the browser can preload the correct resolution rather than a size it won't use.

Image Formats: WebP vs AVIF: When to Use Each

Format	Compression vs JPEG	Browser Support	Encoding Speed	Best For
JPEG	Baseline	Universal	Fast	Legacy fallback
WebP	~30% smaller	97%+ (all modern)	Fast	General use, default choice
AVIF	~50% smaller	~90% (Chrome, Firefox, Safari 16+)	Slow	High-quality images where encoding time is acceptable
PNG	Lossless	Universal	Fast	Transparency, screenshots

WebP is the pragmatic default for 2026. Browser support is effectively universal, encoding is fast enough for CI pipelines, and the ~30% size reduction over JPEG is consistent across photo content. If you're only serving one format, it should be WebP.

AVIF gets you another 20-25% on top of WebP for photographic content. The tradeoff is encoding time: an AVIF encode can be 10-20x slower than WebP for the same image. In practice this means pre-generating AVIF at build time or through a CDN image optimization service (Cloudinary, Imgix, Vercel Image Optimization all support it). Don't attempt AVIF on-demand at request time on a small server.

Browser support for AVIF is around 90% and Safari added support in version 16. For the remaining ~10%, you always fall back with <picture>.

`srcset` and `sizes`: How the Browser Picks the Right Image

The srcset attribute provides a list of candidate images at different widths. The sizes attribute tells the browser how wide the image will be rendered at different viewport widths. The browser uses both to pick the optimal image for the current viewport and device pixel ratio.

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

On a 375px-wide iPhone with a 3x retina display, the browser sees: the image will render at 375px (because max-width: 768px → 100vw), and the DPR is 3, so it needs an image that's at least 1125px wide. It picks /hero-1200.webp. Without srcset, it would fetch the full 2400px image: 4x more data than needed.

The src attribute is the fallback for browsers that don't understand srcset, which at this point is essentially nothing. But always include it.

CLS From Images: Width, Height, and the `aspect-ratio` Trick

Cumulative Layout Shift (CLS) from images has one root cause: the browser doesn't know the image dimensions before it loads, so it allocates zero height for it. When the image loads, the layout shifts down pushing content that was already visible.

The fix is declaring dimensions:

<!-- Without dimensions: layout shift guaranteed -->
![Product photo](https://renderlog.in/photo.webp)

<!-- With explicit dimensions: browser reserves space -->
![Product photo](https://renderlog.in/photo.webp)

The browser uses the width and height attributes to calculate the intrinsic aspect ratio and reserves the right amount of space before the image loads. You don't need to make the image exactly 800x600: the attributes communicate the ratio, and CSS can resize the image freely.

For responsive images where you want CSS to control the rendered size:

img {
  width: 100%;
  height: auto;
  aspect-ratio: 4 / 3; /* explicit fallback if width/height attributes not present */
}

The aspect-ratio CSS property is the backup when you genuinely don't know the image dimensions ahead of time, but width and height attributes are still the preferred mechanism because they're understood by the browser before CSS parses.

The `<picture>` Element: Art Direction vs Format Selection

The <picture> element serves two distinct purposes that are easy to conflate.

Format selection serving different formats with a fallback:

<picture>
  <source srcset="/hero.avif" type="image/avif" />
  <source srcset="/hero.webp" type="image/webp" />
  ![Hero](https://renderlog.in/hero.jpg)
</picture>

The browser picks the first <source> it supports. If it supports AVIF, it uses that. Otherwise WebP. Otherwise JPEG. The <img> tag is always required as the final fallback and carries the alt, width, height, and any loading attributes.

Art direction serving different crops for different viewports:

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

On mobile, you serve a portrait-cropped version where the subject fills the frame. On desktop, the wide landscape version. This is different from responsive sizing: it's serving a different image, not a different resolution of the same image.

You can combine both: use media for art direction and type for format selection within the same <picture> element.

Font Loading and CLS: The FOUT/FOIT Trade-off

Web fonts are one of the most misunderstood sources of CLS and layout instability. There are two phenomena:

FOIT (Flash of Invisible Text) text is invisible until the font loads. The browser reserves the space but shows nothing. CLS score is zero, but users see invisible content.
FOUT (Flash of Unstyled Text) text renders immediately in a fallback font, then swaps to the web font when it loads. Users see content immediately, but the font swap can cause a layout shift if the metric sizes differ.

The font-display descriptor controls this behavior:

`font-display` value	Block period	Swap period	Best for
`auto`	Browser decides	Browser decides	Don't use
`block`	~3s	Unlimited	Icon fonts that must not show fallback
`swap`	Minimal	Unlimited	Body text always shows text
`fallback`	~100ms	~3s	Balance of FOUT and FOIT
`optional`	~100ms	None	Non-essential decorative fonts

For body text, font-display: swap is the right call: users see text immediately, and the font swap happens quickly enough that most users don't perceive it. For hero/headline fonts where the metrics difference between your web font and system font would cause a large CLS, font-display: fallback is better it gives the font a short window to load before swapping, and if it doesn't arrive in time, it stays on the fallback for that page view.

font-display: optional is underused. It tells the browser: if the font is already cached, use it; otherwise, don't bother for this page view. For non-critical decorative fonts, this is ideal: no CLS, no FOIT, and cached users get the full experience.

`preconnect` and `preload` for Fonts

If you're loading fonts from Google Fonts or another CDN, preconnect eliminates the DNS + TCP + TLS handshake latency:

<head>
  <!-- For Google Fonts: preconnect to both origins -->
  <link rel="preconnect" href="https://fonts.googleapis.com" />
  <link rel="preconnect" href="https://fonts.gstatic.com" crossorigin />

  <!-- The actual font stylesheet -->
  <link
    href="https://fonts.googleapis.com/css2?family=Inter:wght@400;600;700&display=swap"
    rel="stylesheet"
  />
</head>

The crossorigin attribute on the second preconnect is critical: font files are fetched with CORS headers, so the connection must also be established as a CORS connection. Missing this means the preconnect establishes a non-CORS connection that can't be reused for the actual font fetch.

For self-hosted fonts, preload is more aggressive:

<link
  rel="preload"
  href="/fonts/inter-v13-latin-regular.woff2"
  as="font"
  type="font/woff2"
  crossorigin
/>

Preload the specific font file that renders above-fold text, usually the regular weight of your body font. Preloading every weight and style defeats the purpose and wastes bandwidth on weights that may not even render on the current page.

System Font Stacks: The Right Answer More Often Than You Think

Before reaching for a web font, ask whether a system font stack meets the design requirement. In 2026, -apple-system, Segoe UI, and Roboto are genuinely good fonts that ship with the OS:

body {
  font-family:
    -apple-system,
    BlinkMacSystemFont,
    "Segoe UI",
    Roboto,
    Oxygen,
    Ubuntu,
    sans-serif;
}

No font file downloads. No FOUT. No CLS. Zero font-related LCP impact. For internal tools, dashboards, documentation sites, and developer-facing products, system fonts are often indistinguishable from a web font in practice and eliminate an entire category of performance problems.

If your brand absolutely requires a specific typeface, then use web fonts. But default to system fonts and add custom fonts when there's a genuine design need, not as a reflexive choice.

Subsetting Fonts: Removing Glyphs You Don't Need

A full-weight Inter or Roboto font file can be 150-300KB. The Latin subset you actually render on an English-language site uses maybe 250 of those glyphs. Subsetting removes the unused glyphs and can reduce font size by 60-80%.

Using pyftsubset from the fonttools package:

pip install fonttools brotli

# Subset to Latin characters only
pyftsubset inter-regular.woff2 \
  --output-file=inter-regular-latin.woff2 \
  --flavor=woff2 \
  --unicodes="U+0000-00FF,U+0131,U+0152-0153,U+02BB-02BC,U+02C6,U+02DA,U+02DC,U+2000-206F,U+2074,U+20AC,U+2122,U+2191,U+2193,U+2212,U+2215,U+FEFF,U+FFFD"

Google Fonts does this for you automatically when you include &subset=latin in the URL: it's one of the real performance benefits of using their CDN. If you're self-hosting, run subsetting as part of your build pipeline.

For sites with only ASCII content, you can subset even more aggressively, often getting font files down to 15-25KB.

Third-Party Scripts: How They Block the Main Thread

Every third-party script you add to a page comes with a real performance cost. The third-party-web dataset (maintained by Patrick Hulce) aggregates real-world data on how long third-party scripts block the main thread. Some numbers from the dataset:

Third Party	Median Blocking Time
Google Tag Manager	~70ms
Intercom chat widget	~130ms
Hotjar	~90ms
Facebook Pixel	~50ms
Drift chat	~140ms

These are medians: individual sites see much worse. And these costs are additive. If you add GTM + Intercom + Hotjar, you're looking at 300ms of main thread blocking before the user can interact with anything.

The problem is compounded by Tag Manager: GTM itself blocks for 70ms, then it fires additional tags that each have their own cost. A poorly governed GTM container can fire 15-20 tags synchronously, each making additional network requests, each running arbitrary JavaScript.

Deferring Third-Party Scripts

The simplest fix for most third-party scripts is using async or defer:

<!-- Blocks HTML parsing: never do this for third parties -->
<script src="https://analytics.example.com/script.js"></script>

<!-- Downloads in parallel, executes after parse: use this -->
<script async src="https://analytics.example.com/script.js"></script>

<!-- Downloads in parallel, executes after DOM is ready: use this for non-critical -->
<script defer src="https://analytics.example.com/script.js"></script>

For GTM specifically, the container snippet they provide uses async by default, but the tags fired inside GTM often don't. The real lever is auditing your GTM container and ensuring tags fire on events (scroll, interaction, DOMContentLoaded) rather than firing immediately on page load.

Moving analytics to server-side is the most impactful option for privacy-focused teams and those who need accurate data without affecting client performance. Server-side GTM routes events through your own server rather than sending data client-side. Setup is more complex but eliminates the client-side script entirely for analytics.

The Facade Pattern for Heavy Embeds

Facades are lightweight placeholders that replace heavy third-party embeds until user interaction. The most common example is YouTube embeds:

// Heavy: embeds the full YouTube player iframe on page load (~500KB)
<iframe
  src="https://www.youtube.com/embed/dQw4w9WgXcQ"
  width="560"
  height="315"
/>

// Facade: shows a thumbnail and play button, loads the real embed on click
function YouTubeFacade({ videoId, title }) {
  const [loaded, setLoaded] = React.useState(false);

  if (loaded) {
    return (
      <iframe
        src={`https://www.youtube.com/embed/${videoId}?autoplay=1`}
        width="560"
        height="315"
        title={title}
        allow="autoplay"
      />
    );
  }

  return (
    <div
      style={{ position: "relative", cursor: "pointer", aspectRatio: "16/9" }}
      onClick={() => setLoaded(true)}
    >
      ![](https://renderlog.in)
      <button
        style={{
          position: "absolute",
          top: "50%",
          left: "50%",
          transform: "translate(-50%, -50%)",
        }}
        aria-label={`Play ${title}`}
      >
        ▶
      </button>
    </div>
  );
}

The lite-youtube-embed web component is a production-ready version of this pattern: a single small script that renders a YouTube thumbnail and loads the real embed on click. It saves ~500KB of JavaScript that would otherwise execute on page load.

The same pattern applies to Google Maps (use a static map image as placeholder), Intercom and Drift (use a custom "Chat" button that loads the SDK on click), and Calendly embeds (open in a modal on demand).

Lighthouse's Facade audit specifically flags third-party embeds that have known lightweight alternatives and quantifies the time savings. It's one of the most actionable audits in the report.

Putting It Together: A Pre-Launch Checklist

Every page I ship now goes through a quick mental checklist before it hits production:

LCP image has loading="eager", fetchpriority="high", explicit width and height, and is preloaded in <head>
LCP image is served in WebP (AVIF if the CDN supports it), with JPEG fallback via <picture>
All images have srcset and sizes for responsive resolution selection
No image is missing width and height attributes
Web fonts use font-display: swap or fallback; preconnect to font CDN is in <head>
Font files are subsetted to the character ranges actually used
GTM container is audited; no tags fire synchronously on page load
YouTube/maps/chat embeds use a facade
third-party-web data checked for any new scripts added in the last sprint

The facade pattern, combined with deferring GTM tags to DOMContentLoaded, is consistently the highest-leverage fix for third-party script LCP impact: the marketing team's tags still fire correctly, just after the user has already seen the page.

Read the original article on Renderlog.in:
https://renderlog.in/blog/images-fonts-third-party-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

Tree Shaking and Code Splitting in JavaScript

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

A 2MB gzipped JavaScript bundle is ~7MB for V8 to parse and compile. On a mid-range Android at 3G, that is 12 seconds before a single interaction is possible. Bundle size is not an abstract metric — it is directly proportional to Time to Interactive on real hardware.

Why bundle bloat happens silently: Every convenient import adds to the module graph. moment.js locale files, full lodash imports, icon libraries with 1000 icons — none of these produce visible errors. They just make the app slower on devices you don't test on.

What this covers: How bundlers construct the module graph, where tree shaking fails silently, how sideEffects in package.json controls elimination, and how dynamic import() splits the bundle into chunks that load on demand.

What a bundle actually is

When you run npm run build, your bundler (Rollup inside Vite, Webpack, esbuild) does roughly this:

Starting from your entry point (main.tsx), it follows every import statement
It builds a module graph a directed graph of every file that's reachable from the entry
It merges all those files into one or more output files, resolving module boundaries
It applies tree shaking to remove code that's imported but never called
It minifies (removes whitespace and shortens names) and optionally compresses

The default result is one file containing your entire application: every component, every utility, every vendor library. That single file must be downloaded, parsed, and compiled before anything runs.

The reason everything ends up in one file by default is performance optimization for the common case: one large file is often faster than dozens of small ones, because each file requires a separate HTTP request (with its own connection overhead), and the browser's HTTP cache is most effective when file names are stable. One bundle = one cache entry = minimal request overhead.

But "one big file" becomes a liability when:

The bundle contains code for routes the user will never visit
It contains multiple large vendor libraries that could be split into separate caches
Any change to the app (even one line) invalidates the entire bundle cache

This is why code splitting matters.

Bundle analysis: seeing what's actually in there

Before optimizing, you need to understand the bundle's contents. Three tools I actually use:

rollup-plugin-visualizer (for Vite/Rollup projects) generates an interactive treemap:

// vite.config.ts

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

After npm run build, open bundle-stats.html. You see a rectangle-packed treemap where each rectangle's area is proportional to the module's size in the bundle. Scan for large vendor rectangles that surprise you. A common discovery is that moment.js is taking 300KB because someone imported it for date formatting once.

webpack-bundle-analyzer does the same for Webpack:

npm install --save-dev webpack-bundle-analyzer
npx webpack --profile --json > stats.json
npx webpack-bundle-analyzer stats.json

source-map-explorer is useful when you have source maps but not a plugin-compatible build setup:

npx source-map-explorer dist/assets/index-abc123.js

What to look for when reading a bundle visualization:

Unexpectedly large single modules often a library you didn't know was that big
Duplicate packages the same library appearing twice at different versions
Code you thought was excluded development utilities or storybook code in production builds
Polyfills for modern browsers if your target browsers support native features, polyfills are dead weight

Tree shaking: how it works and why it fails silently

Tree shaking is the process of eliminating code from the bundle that is imported but never actually called. The term comes from "shaking a tree and letting the dead leaves fall."

Tree shaking relies on ES module static analysis. The key insight: import and export statements are static: the module graph is fully knowable at build time without executing any code.

// ES Module: statically analyzable

// Bundler knows: only formatDate and parseDate are used.
// Any other exports from dates.js can be eliminated.

Compare to CommonJS:

// CommonJS: NOT statically analyzable
const dates = require('./dates.js');
// Bundler cannot know which properties of 'dates' are used at build time.
// require() could be called conditionally, so the entire module must be included.

This is why mixing CommonJS and ES modules causes tree shaking to silently fail. The bundler falls back to including the entire module.

The `sideEffects` field

Even with ES modules, tree shaking requires one more thing: the sideEffects field in package.json.

A side effect is code that runs when a module is imported, regardless of whether you use its exports. CSS imports, polyfills, global registrations: these are side effects. If the bundler assumes a module has side effects, it can't eliminate it even if none of its exports are used.

// package.json
{
  "name": "my-library",
  "sideEffects": false
}

"sideEffects": false tells bundlers: "every file in this package is pure. If nothing imports from it, it can be eliminated." Without this, even unused modules from a dependency are included in the bundle.

For your own application code, you can be more precise:

{
  "sideEffects": ["*.css", "src/polyfills.js"]
}

This says: CSS files and the polyfills file have side effects (they must be included), but all other JavaScript files are pure. The bundler can tree-shake the JavaScript while preserving the CSS imports.

Common tree shaking failures

Barrel files

A barrel file is an index.js that re-exports everything from a directory:

// components/index.js (barrel file)

// ... 50 more exports

// Using it

The problem: some bundlers (particularly older Webpack configurations and certain Rollup setups) cannot tree-shake barrel files reliably. When you import Button from the barrel, the bundler may include the entire barrel all 50+ components because it can't prove the barrel itself doesn't have side effects from the re-export pattern.

The fix is to import directly from the source file:

Or configure your bundler explicitly to handle barrels. Vite handles this well in modern versions, but it's worth verifying with the bundle analyzer that barrel imports aren't inflating your output.

lodash

Importing lodash like this includes the entire 70KB library:

The fix is either lodash-es (which uses ES modules and tree-shakes correctly) or direct cherry-picking:


// or

moment.js locale problem

moment.js has a notorious bundling issue: it includes all locale files by default. If you're using moment at all, you're pulling in ~300KB of locale data for languages you'll never use.

// This pulls in ALL locales: ~300KB gzipped

The options, ranked by recommendation:

Replace with date-fns tree-shakeable, only includes what you import
Replace with dayjs 2KB gzipped, locale files are separate optional imports
Use Webpack IgnorePlugin to exclude locale files from moment (if migration is not feasible)

Code splitting

Code splitting is the practice of splitting your bundle into multiple files that load on demand. Instead of one 2MB bundle, you might have:

A 200KB core bundle that loads immediately
A 400KB dashboard chunk that loads when the user navigates to /dashboard
A 100KB admin chunk that loads only if the user is an admin

The result: users only download code for the features they actually use.

React.lazy() and Suspense

The canonical React code splitting pattern:


// Instead of: import Dashboard from './Dashboard';
const Dashboard = lazy(() => import('./Dashboard'));
const AdminPanel = lazy(() => import('./AdminPanel'));

function App() {
  return (
    }>

    </Suspense>
  );
}

React.lazy() takes a function that returns a dynamic import(). The bundler sees the dynamic import and automatically creates a separate chunk for Dashboard.tsx and all its unique dependencies. That chunk is not downloaded until the user navigates to /dashboard.

The Suspense boundary shows `` while the chunk is downloading. For route-level splits, this is typically the loading spinner or skeleton you'd show during data fetching anyway.

Dynamic import() and chunk naming

Under the hood, lazy() uses dynamic import(). You can use it directly for non-component code:

`js // Loads only when called, not at app startup async function processSpreadsheet(file) { const { read, utils } = await import('xlsx'); // 400KB library, only loaded when needed const workbook = read(await file.arrayBuffer()); return utils.sheet_to_json(workbook.Sheets[workbook.SheetNames[0]]); } `

Magic comments let you control chunk names:

`js const Dashboard = lazy(() => import( /* webpackChunkName: "dashboard" */ /* vite: { chunkName: "dashboard" } */ './Dashboard' )); `

Without magic comments, bundlers generate hash-based names like chunk-abc123.js. Named chunks make your build output readable and help with debugging production issues.

Vendor splitting for cache utilization

Libraries like React, React DOM, and React Router change infrequently, maybe once every few months when you upgrade. Your application code changes with every deployment.

If they're all in one bundle, every deployment invalidates the browser's cache for React even though React itself hasn't changed.

Vendor splitting keeps stable libraries in separate chunks with content-hash filenames:

`js
// vite.config.ts

build: {
rollupOptions: {
output: {
manualChunks: {
'vendor-react': ['react', 'react-dom', 'react-router-dom'],
'vendor-query': ['@tanstack/react-query'],
'vendor-ui': ['@radix-ui/react-dialog', '@radix-ui/react-dropdown-menu'],
}
}
}
}
};
`

Now vendor-react-[hash].js stays cached across deployments. Users who visited yesterday already have React cached. They only download your application code when you deploy.

Bundle type	Changes on every deploy?	Cache lifetime
App code	Yes	Short (invalidated on every deploy)
Vendor (React etc.)	No (until you upgrade)	Long (months between upgrades)
Feature chunks	Only when that feature changes	Medium

The entry point waterfall

One anti-pattern that's easy to overlook: eagerly importing all routes in the entry point.

`js
// main.tsx (WRONG): eager imports defeat code splitting

Even if you use React Router to only render one route at a time, Webpack/Vite will see these static imports and include all pages in the initial bundle. The dynamic import pattern only works when import() is actually dynamic:

`js // main.tsx (RIGHT): all routes are lazily loaded const Dashboard = lazy(() => import('./pages/Dashboard')); const Settings = lazy(() => import('./pages/Settings')); const Admin = lazy(() => import('./pages/Admin')); const Reports = lazy(() => import('./pages/Reports')); `

Check your bundle visualizer. If all your route components appear in the main chunk, this is why.

Measuring bundle impact in CI

Ad-hoc bundle analysis after the fact is better than nothing, but the real win is preventing bundle bloat in CI before it reaches production.

size-limit is a package that fails your CI build if the bundle exceeds defined limits:

`json // package.json { "size-limit": [ { "path": "dist/assets/index-*.js", "limit": "300 KB", "gzip": true }, { "path": "dist/assets/vendor-react-*.js", "limit": "150 KB", "gzip": true } ] } `

`yaml

.github/workflows/build.yml

name: Check bundle size run: npx size-limit `

With this in place, a PR that inadvertently adds a 500KB dependency (say, someone imports moment instead of date-fns) will fail CI with a clear error message:

`plaintext
dist/assets/index-abc123.js
Size: 487 KB with all dependencies, minified and gzipped

Package size limit has exceeded the limit.
Size limit: 300 KB
Size: 487 KB
Try to reduce size or increase the limit.
`

Performance budgets go beyond just JS size. Lighthouse CI lets you set budgets on LCP, TTI, and total transfer size:

`json // lighthouserc.js module.exports = { assert: { assertions: { 'first-contentful-paint': ['warn', { maxNumericValue: 2000 }], 'interactive': ['error', { maxNumericValue: 5000 }], 'total-byte-weight': ['error', { maxNumericValue: 1000000 }], } } }; `

The bundle optimization checklist

Step	Tool	Expected win
Analyze current bundle	rollup-plugin-visualizer	Identify large dependencies
Find duplicate packages	`npm dedupe`, `bundlesize`	Eliminate redundant copies
Fix lodash imports	`lodash-es` or cherry-pick	Save 50–70KB
Add `sideEffects: false`	package.json	Enable tree shaking for your code
Route-level code splitting	`React.lazy()`	Defer non-critical routes
Vendor splitting	Rollup `manualChunks`	Improve cache utilization
Dynamic import for heavy libs	`import()`	Only load when needed
Set size limits in CI	`size-limit`	Prevent future regressions

Bundles don't bloat all at once. They bloat incrementally — one convenient import at a time. The defense is measurement, budgets, and a clear understanding of what each dependency actually costs to download, parse, and compile on real hardware.

Read the original article on Renderlog.in:
https://renderlog.in/blog/build-bundles-treeshaking-code-splitting/

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

Web Workers in React: Heavy Work Off Main Thread

Ashish Kumar — Thu, 30 Apr 2026 00:30:00 +0000

Heavy CPU work — parsing large binary files, sorting 50,000 records, running ML inference — belongs on a separate thread, not the main thread. The main thread has one job: keep the UI responsive. Every millisecond it spends on computation: a millisecond it cannot spend processing input events or painting frames.

What Web Workers give you: JavaScript running in a separate OS thread, completely isolated from the main thread's event loop. While the worker processes data, the main thread handles clicks, renders frames, and runs React's reconciler, unblocked.

What this covers: The Worker communication model and structured clone limits, when Workers help vs when they don't, Comlink for ergonomic async APIs: the React custom hook pattern for Worker lifecycle management, Worker pools, and OffscreenCanvas (rendering off-thread).

What Web Workers actually are

A Web Worker is JavaScript running in a separate OS thread from the browser's main thread. It has its own global scope (self instead of window), its own event loop, and cannot directly access the DOM, document, window, or any browser APIs that require the main thread.

The communication model is message passing: the main thread and the worker communicate by calling postMessage() and listening to message events. The data passed between them is structured cloned serialized into a binary format and deserialized on the other side. No shared memory by default.

// main.js
const worker = new Worker(new URL("./my-worker.js", import.meta.url));

worker.postMessage({ type: "PARSE", payload: rawData });

worker.addEventListener("message", (event) => {
  const { result } = event.data;
  setProcessedData(result);
});

// my-worker.js
self.addEventListener("message", (event) => {
  const { type, payload } = event.data;

  if (type === "PARSE") {
    const result = heavyParseFunction(payload);
    self.postMessage({ result });
  }
});

The worker runs heavyParseFunction in its own thread. The main thread is free to handle user events, paint frames, and run React's reconciler while the work happens.

The structured clone algorithm: what can cross the boundary

Not everything can be passed to a Worker via postMessage. The structured clone algorithm defines what's serializable. Understanding its limits saves debugging time.

What can be cloned:

Primitives (string, number, boolean, null, undefined, BigInt)
Arrays and plain objects (deeply nested, recursively)
Map, Set, Date, RegExp
ArrayBuffer, TypedArray (Uint8Array, Float32Array, etc.)
Blob, File, ImageData
MessagePort (via transfer, not clone)

What cannot be cloned:

Functions (cannot be serialized this is a fundamental limit)
DOM nodes or element references
Proxy objects
Objects with circular references (will throw)
Class instances with custom prototypes (only own enumerable properties are cloned, prototype chain is lost)

// This will throw  functions can't be cloned
worker.postMessage({ callback: () => console.log("hi") }); // DataCloneError

// This works  plain data
worker.postMessage({ data: [1, 2, 3], config: { threshold: 0.5 } });

Transferable objects are a different mechanism: instead of cloning data, you transfer ownership. The sending side loses access; the receiver gains it. This is zero-copy and critical for large buffers.

const buffer = new ArrayBuffer(1024 * 1024 * 10); // 10MB
// Transfer the buffer  main thread can no longer access it
worker.postMessage({ buffer }, [buffer]);

ArrayBuffer, MessagePort, OffscreenCanvas, ImageBitmap, and ReadableStream are all transferable.

CPU-bound vs I/O-bound: the right use cases

The mistake I see most often is reaching for Workers for the wrong kind of work.

Web Workers help with CPU-bound tasks work where the CPU is the bottleneck, computation takes significant wall-clock time, and the result can be returned asynchronously:

Good Worker candidate	Why
Parsing large CSV/JSON/binary files	Pure CPU, no DOM needed
Image processing (resizing, filtering, color transforms)	Pixel math is CPU-intensive
Cryptographic operations (hashing, encryption)	Compute-heavy, available via `crypto.subtle` in workers
Data compression/decompression	CPU-bound, libraries like `pako` work in workers
Machine learning inference (`onnxruntime-web`, `transformers.js`)	Matrix math is exactly what workers are for
Sorting/filtering/aggregating large datasets	Heavy transforms on thousands of records

Workers don't help with I/O-bound tasks:

Bad Worker candidate	Why
`fetch` calls	`fetch` is non-blocking on the main thread already; async/await handles this
Waiting for user input	No DOM access in workers
Updating React state	You still have to `postMessage` back to main thread; the bottleneck is in the message handler
Fast, small computations	Worker setup cost + clone overhead exceeds the computation time

The test: if your operation would be fast but for the raw CPU cycles it consumes, a Worker will help. If it's slow because it's waiting for network or disk, a Worker adds overhead without solving anything.

Worker lifecycle management

Workers have a lifecycle: you create them, communicate with them, and eventually terminate them. Forgetting to terminate workers is a memory leak.

// Create
const worker = new Worker(new URL("./parser.worker.js", import.meta.url));

// Communicate
worker.postMessage(data);
worker.addEventListener("message", handler);

// Terminate when done
worker.terminate();

// Error handling
worker.addEventListener("error", (event) => {
  console.error("Worker error:", event.message, event.filename, event.lineno);
});

worker.addEventListener("messageerror", (event) => {
  console.error("Failed to deserialize message from worker:", event);
});

Unhandled exceptions inside a worker fire the error event on the worker object in the main thread. The worker continues running after an error unless you call terminate(). Errors inside workers don't propagate to window.onerror you must handle them explicitly.

Comlink: making Workers feel like normal async functions

The raw postMessage API gets verbose fast. You end up building a request/response protocol with message types, correlation IDs, and manual promise management. Comlink (a small Google library) abstracts all of that into a clean async function interface.

// parser.worker.js

const api = {
  async parseCSV(csvString) {
    // heavy parsing work
    return parsedRows;
  },

  async transformData(rows, config) {
    // heavy transformation
    return transformedRows;
  },
};

Comlink.expose(api);

// main thread

const worker = new Worker(new URL("./parser.worker.js", import.meta.url));
const api = Comlink.wrap(worker);

// Feels like a regular async call  no postMessage, no event listeners
const rows = await api.parseCSV(csvString);
const transformed = await api.transformData(rows, { threshold: 0.5 });

Comlink handles the message correlation, promise wrapping, and error propagation under the hood. The result is Worker code that reads like normal async JavaScript.

The limitation: Comlink's proxy still relies on structured clone, so your function arguments and return values must be serializable. You can use Comlink.transfer() to pass Transferable objects explicitly.

Vite/webpack integration

Modern bundlers handle Worker imports natively. In Vite, the new URL pattern is the standard:

// Vite: recognized as a Worker by the bundler
const worker = new Worker(
  new URL("./heavy-computation.worker.js", import.meta.url),
  { type: "module" } // enables ES module syntax in the worker
);

Vite bundles the worker file separately, handles its imports, and outputs a separate chunk. The worker can import npm packages normally.

For Webpack 5, workers are similarly first-class:

// Webpack 5: same URL pattern
const worker = new Worker(new URL("./worker.js", import.meta.url));

Avoid the older string-URL pattern (new Worker("/worker.js")) in modern builds it bypasses the bundler and forces you to manually manage the worker file in your public directory.

React integration: custom hook wrapping a Worker

The cleanest pattern for using a Worker in React is a custom hook that manages the Worker lifecycle and exposes a simple async interface.

// useCSVParser.js

  const workerRef = useRef(null);
  const apiRef = useRef(null);

  useEffect(() => {
    const worker = new Worker(
      new URL("./csv-parser.worker.js", import.meta.url),
      { type: "module" }
    );
    workerRef.current = worker;
    apiRef.current = Comlink.wrap(worker);

    return () => {
      worker.terminate();
      workerRef.current = null;
      apiRef.current = null;
    };
  }, []);

  const parseCSV = useCallback(async (csvString) => {
    if (!apiRef.current) throw new Error("Worker not initialized");
    return apiRef.current.parseCSV(csvString);
  }, []);

  return { parseCSV };
}

// Component using the hook
function DataUploader() {
  const { parseCSV } = useCSVParser();
  const [rows, setRows] = useState([]);
  const [isParsing, setIsParsing] = useState(false);

  async function handleFileUpload(file) {
    setIsParsing(true);
    try {
      const text = await file.text();
      const parsed = await parseCSV(text); // runs in worker thread
      setRows(parsed);
    } finally {
      setIsParsing(false);
    }
  }

  return (
    <div>
      <input type="file" accept=".csv" onChange={e => handleFileUpload(e.target.files[0])} />
      {isParsing && <p>Parsing {/* spinner */}</p>}
      {rows.length > 0 && }
    </div>
  );
}

The useEffect cleanup calls worker.terminate() critical for preventing memory leaks when the component unmounts.

Worker pools for parallelism

A single Worker runs one task at a time. If you have multiple independent tasks, a Worker pool lets you run them in parallel across multiple Worker instances.

// Simple worker pool
class WorkerPool {
  constructor(workerUrl, size = navigator.hardwareConcurrency || 4) {
    this.workers = Array.from(
      { length: size },
      () => Comlink.wrap(new Worker(workerUrl, { type: "module" }))
    );
    this.index = 0;
  }

  // Round-robin dispatch
  getWorker() {
    const worker = this.workers[this.index];
    this.index = (this.index + 1) % this.workers.length;
    return worker;
  }

  async run(method, ...args) {
    return this.getWorker()[method](...args);
  }

  terminate() {
    this.workers.forEach(w => Comlink.releaseProxy(w));
  }
}

navigator.hardwareConcurrency returns the number of logical CPU cores. Using it as the pool size avoids over-subscribing the CPU. On a 4-core machine, 4 workers can genuinely run in parallel; 16 workers won't be faster, just more memory-hungry.

OffscreenCanvas: rendering off the main thread

OffscreenCanvas lets you do canvas rendering (charts, WebGL scenes, image processing) entirely in a Worker. You transfer the canvas to the worker and it renders directly no main-thread involvement after the initial transfer.

// main.js
const canvas = document.getElementById("chart-canvas");
const offscreen = canvas.transferControlToOffscreen();
const worker = new Worker(new URL("./chart-worker.js", import.meta.url));

// Transfer ownership  main thread can no longer access the canvas
worker.postMessage({ canvas: offscreen }, [offscreen]);

// chart-worker.js
self.addEventListener("message", ({ data }) => {
  const { canvas } = data;
  const ctx = canvas.getContext("2d");

  // Draw whatever you want  this runs off the main thread
  function draw() {
    // ... heavy chart rendering
    requestAnimationFrame(draw); // yes, rAF works in workers with OffscreenCanvas
  }
  draw();
});

This is particularly useful for live-updating charts (trading data, metrics dashboards) where the chart render work is expensive enough to cause jank on the main thread.

SharedArrayBuffer and Atomics

SharedArrayBuffer enables true shared memory between the main thread and workers no cloning, no transfer. Both threads read and write the same memory region.

// main.js
const sharedBuffer = new SharedArrayBuffer(4 * 1024); // 4KB
const sharedArray = new Int32Array(sharedBuffer);

worker.postMessage({ buffer: sharedBuffer });

// worker.js
self.addEventListener("message", ({ data }) => {
  const array = new Int32Array(data.buffer);
  // Both main thread and worker can now read/write array
  Atomics.store(array, 0, 42);
});

Atomics provides atomic operations (compare-and-swap, load, store, wait/notify) for coordinating access to shared memory without data races.

The catch: SharedArrayBuffer requires cross-origin isolation headers on your server:

Cross-Origin-Opener-Policy: same-origin
Cross-Origin-Embedder-Policy: require-corp

These headers limit what can be embedded in your page (no arbitrary cross-origin iframes or images without explicit CORP headers), which is a meaningful constraint for apps with third-party integrations.

SharedArrayBuffer is the right tool for high-throughput real-time scenarios streaming telemetry, audio processing, game physics where the clone overhead of postMessage is itself a bottleneck. For most application use cases, structured clone is fast enough.

Before/after: moving CSV parsing to a Worker

Here's the concrete impact of moving a 50,000-row CSV transform to a Worker.

Before (main thread):

Main thread task: 1,847ms
  ├── CSV string parse: 340ms
  ├── Row validation: 420ms
  ├── Data normalization: 680ms
  └── Aggregation: 407ms

Result: Input frozen, no frames painted, spinner doesn't spin

After (Worker):

Main thread task: 12ms (postMessage + state update)
Worker thread: 1,847ms (same work, different thread)

Result: Input responsive, spinner animates, results arrive async

The total computation time didn't change. But the user experience went from "frozen app" to "responsive app with an async operation in progress." That's the entire value proposition of Web Workers.

Metric	Before	After
Main thread block time	1,847ms	~12ms
User input response	Frozen	Immediate
Spinner animation	Stutters	Smooth
Total computation time	1,847ms	1,847ms (in worker)
Bundle complexity	None	Worker file + Comlink

Read the original article on Renderlog.in:
https://renderlog.in/blog/web-workers-frontend-react/

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

OPFS: The Browser's Built-in Filesystem Explained

Ashish Kumar — Wed, 29 Apr 2026 00:30:00 +0000

localStorage caps at 5MB. IndexedDB writes a 50MB buffer in ~850ms — slow enough to feel it. The Cache API is effectively read-only. The File System Access API requires user permission prompts every session. None of these were designed for what serious client-side applications actually need: large, fast, random-access binary storage that persists across sessions without permission prompts.

The Origin Private File System (OPFS) fills that gap. It is a real, sandboxed filesystem per origin, invisible to the OS file manager, persistent across sessions, and accessible with a synchronous API from within Workers that makes large sequential I/O genuinely fast.

What this covers: The OPFS API in detail, the synchronous access handle (and why it only works in Workers), streaming network responses directly to OPFS, the performance difference vs IndexedDB, and how SQLite runs in the browser using OPFS as its backing store.

The storage landscape problem

Before OPFS existed, the browser gave you four options for persistent storage, and each one was the wrong tool for at least one important job:

localStorage is synchronous (which feels nice), but the 5–10MB limit is a hard wall. It is also string-only, so storing binary data means base64 encoding which inflates size by ~33% and makes a 5MB limit feel like 3.7MB.

IndexedDB can handle gigabytes in theory, is asynchronous, and supports structured objects and binary blobs. But the API is callback-hell wrapped in a transaction model that wasn't designed for ergonomics. More practically: writing large sequential blobs to IndexedDB is slow. The implementation serializes data through the structured clone algorithm on every write, and for large files you feel that cost. I measured ~400ms to write a 50MB buffer in Chrome on M2 fine once, unbearable repeatedly.

Cache API (Service Worker caches) is designed for HTTP responses and works well for caching network resources. But it is fundamentally read-after-write: you cannot partially update a cached entry or seek to an offset. Building a writable file system on top of it is like building a database on top of a log file possible in theory, miserable in practice.

File System Access API lets you open actual OS files with a picker. That's useful for "open a video from your desktop" flows, but it's not sandboxed the user sees the file in their Downloads folder, file paths can leak, and the permission model requires a user gesture every session. It's the wrong tool for internal app storage.

OPFS is the missing piece: a sandboxed filesystem per origin, invisible to the OS file manager, persistent across sessions, and critically accessible with a synchronous API from within Workers.

What OPFS actually is

The Origin Private File System is a real filesystem exposed to web pages through the StorageManager API. Every origin gets its own isolated root directory. Files you create there are not visible in the OS Finder/Explorer. Other origins cannot access them. Clearing site data removes them.

You access the root with:

const root = await navigator.storage.getDirectory();

That returns a FileSystemDirectoryHandle. From there you navigate a real directory tree:

// Create or open a subdirectory
const cacheDir = await root.getDirectoryHandle('datasets', { create: true });

// Create or open a file
const fileHandle = await cacheDir.getFileHandle('analytics-v3.bin', { create: true });

To write to that file, you create a writable stream:

const writable = await fileHandle.createWritable();
await writable.write(myArrayBuffer);
await writable.close();

To read it back:

const file = await fileHandle.getFile(); // returns a File object
const buffer = await file.arrayBuffer();
// or: const stream = file.stream();
// or: const text = await file.text();

The File object you get from getFile() is the same File type you'd get from an <input type="file">. You can pass it directly to new Response(file), pipe its .stream() into a TransformStream, or just read it as an ArrayBuffer. This composability is one of the things I genuinely like about the API.

The synchronous access handle why it matters

Here is the part that makes OPFS genuinely different from everything else: inside a Web Worker, you can open a file in synchronous mode.

// Inside a Worker
const root = await navigator.storage.getDirectory();
const fileHandle = await root.getFileHandle('dataset.bin', { create: true });

// This is a synchronous handle  only available in Workers
const syncHandle = await fileHandle.createSyncAccessHandle();

// Synchronous read
const buffer = new ArrayBuffer(1024 * 1024);
const bytesRead = syncHandle.read(buffer, { at: 0 });

// Synchronous write
const data = new Uint8Array([1, 2, 3, 4]);
syncHandle.write(data, { at: 0 });

// You must flush and close explicitly
syncHandle.flush();
syncHandle.close();

The createSyncAccessHandle() method is only available in dedicated Workers it deliberately cannot be called on the main thread, because synchronous I/O on the main thread would block rendering. But in a Worker, synchronous access is exactly what you want: no Promise overhead, no microtask queue, just a tight read/write loop that runs at native speed.

The performance difference is meaningful. In my testing, writing a 100MB ArrayBuffer with createSyncAccessHandle took ~90ms. The equivalent IndexedDB write took ~850ms. The gap comes from two places: OPFS bypasses the structured clone algorithm for raw binary data, and the synchronous handle avoids the async event loop overhead that accumulates across thousands of small writes.

Worker + OPFS patterns

The right architecture is: all OPFS work in a Worker, communicate with the main thread via messages.

Here's the pattern I ended up with:

// opfs-worker.js
self.onmessage = async (event) => {
  const { type, payload } = event.data;

  if (type === 'WRITE_FILE') {
    const { path, buffer } = payload;
    const root = await navigator.storage.getDirectory();
    const handle = await root.getFileHandle(path, { create: true });
    const syncHandle = await handle.createSyncAccessHandle();

    syncHandle.truncate(0);
    syncHandle.write(new Uint8Array(buffer), { at: 0 });
    syncHandle.flush();
    syncHandle.close();

    self.postMessage({ type: 'WRITE_DONE', path });
  }

  if (type === 'READ_FILE') {
    const { path } = payload;
    const root = await navigator.storage.getDirectory();
    const handle = await root.getFileHandle(path);
    const file = await handle.getFile();
    const buffer = await file.arrayBuffer();

    // Transfer the buffer (zero-copy)
    self.postMessage({ type: 'READ_DONE', path, buffer }, [buffer]);
  }
};

// main thread
const worker = new Worker('/opfs-worker.js');

worker.postMessage({
  type: 'WRITE_FILE',
  payload: { path: 'analytics-v3.bin', buffer: myArrayBuffer }
}, [myArrayBuffer]); // transfer ownership  zero copy

worker.onmessage = (event) => {
  if (event.data.type === 'READ_DONE') {
    processData(event.data.buffer);
  }
};

The key here is Transferable objects. When you pass [myArrayBuffer] as the second argument to postMessage, ownership transfers to the Worker no copy is made. For a 150MB buffer, this matters. Without transfer, the browser would serialize and copy the data twice (once into the Worker's memory, once back). With transfer, it's a pointer swap essentially free.

Streaming writes from the network

One of the most useful patterns is streaming a network response directly to OPFS, without ever materializing the full response in memory:

// Stream a large file from the network directly to OPFS
async function streamToOPFS(url, filename) {
  const root = await navigator.storage.getDirectory();
  const fileHandle = await root.getFileHandle(filename, { create: true });
  const writable = await fileHandle.createWritable();

  const response = await fetch(url);

  if (!response.body) throw new Error('ReadableStream not supported');

  // Pipe the response body directly to OPFS
  await response.body.pipeTo(writable);
  // writable is automatically closed when pipeTo() resolves
}

createWritable() returns a FileSystemWritableFileStream, which implements the WHATWG WritableStream interface. That means you can pipeTo() any ReadableStream directly into it including response.body. The data flows through without a single full-buffer copy in JavaScript land. For large WASM binaries or video files, this is the right way to download and cache them.

Real use case: caching a 200MB WASM binary

This was essentially what we were doing. We had a data-processing WASM module that was 200MB and updated infrequently. On first load, we streamed it from the CDN into OPFS. On subsequent loads, we checked if the cached version was current (compared an ETag stored in localStorage), and if so, read it straight from OPFS:

async function getWasmModule(url, etag) {
  const root = await navigator.storage.getDirectory();
  const cacheDir = await root.getDirectoryHandle('wasm-cache', { create: true });

  try {
    const storedEtag = localStorage.getItem('wasm-etag');
    if (storedEtag === etag) {
      const handle = await cacheDir.getFileHandle('module.wasm');
      const file = await handle.getFile();
      return WebAssembly.compileStreaming(new Response(file.stream(), {
        headers: { 'Content-Type': 'application/wasm' }
      }));
    }
  } catch {
    // File doesn't exist yet, fall through to fetch
  }

  // Fetch and cache
  const response = await fetch(url);
  const [stream1, stream2] = response.body.tee();

  const handle = await cacheDir.getFileHandle('module.wasm', { create: true });
  const writable = await handle.createWritable();

  // Write to OPFS and compile simultaneously
  const [wasmModule] = await Promise.all([
    WebAssembly.compileStreaming(new Response(stream1, {
      headers: { 'Content-Type': 'application/wasm' }
    })),
    new Response(stream2).arrayBuffer().then(buf => writable.write(buf)).then(() => writable.close())
  ]);

  localStorage.setItem('wasm-etag', etag);
  return wasmModule;
}

The ReadableStream.tee() lets us split one response body into two one piped into WASM compilation, one saved to OPFS. The module compiles and caches in a single network round trip.

OPFS + SQLite: the surprising use case

One of the most interesting production uses of OPFS is as a backing store for SQLite in the browser. The sqlite-wasm project (the official SQLite WASM build) uses the synchronous OPFS access handle to implement POSIX-style file I/O:


const sqlite3 = await sqlite3InitModule({ print: console.log });

// Use OPFS-backed database (runs in a Worker)
const db = new sqlite3.oo1.OpfsDb('/myapp.sqlite3');
db.exec('CREATE TABLE IF NOT EXISTS events (id INTEGER PRIMARY KEY, data TEXT)');
db.exec("INSERT INTO events(data) VALUES('hello')");
const rows = db.exec({ sql: 'SELECT * FROM events', returnValue: 'resultRows' });

This is a full SQLite database, persisted to OPFS, with ACID transactions, SQL queries, and all the features you'd expect running entirely in the browser. The sync handle's random-access read/write is what makes this possible: SQLite needs to be able to seek to arbitrary byte offsets and do partial writes, which is exactly what syncHandle.read(buffer, { at: offset }) provides.

Storage comparison table

	localStorage	IndexedDB	Cache API	OPFS
Size limit	~5MB	Hundreds of MB / GB	Hundreds of MB / GB	Hundreds of MB / GB
API style	Synchronous	Async (promises)	Async (promises)	Async main / Sync in Worker
Binary support	No (base64 only)	Yes (Blob/ArrayBuffer)	Yes (Response body)	Yes (native)
Random access	No	No (seek via cursors)	No	Yes (`{ at: offset }`)
Write speed (100MB)	N/A	~850ms	N/A	~90ms (sync handle)
Streaming writes	No	No	Via fetch	Yes (WritableStream)
Worker access	Yes	Yes	Yes	Yes (sync handle in Worker)
Best for	Small key-value config	Structured app data	HTTP response caching	Large blobs, binary files, SQLite

Quota management

OPFS storage counts toward the origin's storage quota, shared with IndexedDB and the Cache API. The browser manages this as a pool. You can query it:

const estimate = await navigator.storage.estimate();
console.log(`Used: ${estimate.usage} bytes`);
console.log(`Available: ${estimate.quota - estimate.usage} bytes`);

// Breakdown by storage type
console.log(estimate.usageDetails);
// { indexedDB: 1234567, caches: 0, fileSystem: 208000000 }

On Chrome, the quota is typically around 60% of available disk space. On mobile, it can be much smaller, and the browser can evict storage under pressure unless you've called navigator.storage.persist() and the user granted permission.

// Request persistent storage (shows a permission prompt or is auto-granted based on engagement)
const isPersisted = await navigator.storage.persist();
if (!isPersisted) {
  console.warn('Storage may be evicted under disk pressure');
}

For a production app, always check estimate() before writing large blobs and handle the case where quota is insufficient gracefully.

Browser support

Browser	OPFS Available	Sync Access Handle	Notes
Chrome 102+	Yes	Yes (Chrome 108+)	Full support
Firefox 111+	Yes	Yes	Full support
Safari 15.2+	Yes	Yes (Safari 16+)	Full support
Edge 102+	Yes	Yes	Chromium-based
iOS Safari 15.2+	Partial	Yes (16+)	Storage limits tighter
Chrome Android	Yes	Yes	Same as desktop

The main gap to watch is iOS Safari storage limits Apple's browsers on iOS are more aggressive about quota eviction and the persist() permission is harder to get. If you're targeting iOS for large offline datasets, test on actual iOS hardware and check estimate() before assuming you have the space.

Wrapping up

OPFS is not glamorous. It doesn't show up in "top 10 web APIs" listicles. But if you've ever hit the limits of IndexedDB for large binary data, or tried to build an offline-capable app with complex storage needs, it's the API that should have been there all along.

The mental model is simple: it's a real filesystem, sandboxed per origin, with a synchronous API available in Workers that makes large sequential I/O genuinely fast. Pair it with Transferable objects for zero-copy messaging, stream network responses directly into it, and use sqlite-wasm if you need a full relational layer.

The storage landscape went: localStorage → IndexedDB → Cache API → File System Access API → OPFS. Each one fills a different gap. OPFS fills the one that matters most for serious client-side data: fast, large, random-access binary storage that you actually control.

Read the original article on Renderlog.in:
https://renderlog.in/blog/origin-private-file-system-opfs/

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

Network Optimization in React SPAs: Prefetching

Ashish Kumar — Tue, 28 Apr 2026 00:30:00 +0000

SPAs bypass the browser's built-in HTTP caching by routing in JavaScript: the page never reloads, so the browser never re-evaluates cache headers on the HTML. Every component instance fetches its own data. Two components on the same page requesting /api/user fire two separate network requests. Navigating back to a route you visited 30 seconds ago triggers a full refetch.

Why this matters: Each useEffect-based fetch introduces a render-then-fetch waterfall. Stacked across multiple nested route components, this compounds to seconds of latency on navigations that could be instant with correct caching.

What this covers: HTTP cache headers and stale-while-revalidate, how React Query implements client-side SWR, request deduplication, avoiding request waterfalls with route loaders, prefetch-on-hover, and Service Worker caching strategies.

The SPA network problem

Server-rendered apps get HTTP caching for free the browser caches the HTML response, and subsequent navigations can be served from the browser cache. SPAs bypass this by routing in JavaScript: the page never reloads, so the browser never re-evaluates cache headers on the HTML. The app controls its own data fetching, and by default, React components have no shared cache every component instance fetches its own data.

The consequences compound:

Waterfall fetches on navigation a route component mounts, kicks off a useEffect, waits for the response, then maybe kicks off more fetches based on the result
No deduplication two components on the same page both requesting /api/user will fire two separate network requests
Cache amnesia navigating back to a page you visited 10 seconds ago triggers a full refetch
Loading states everywhere because you're always waiting for network, even for data you theoretically already have

Fixing this properly requires thinking at multiple levels: HTTP caching, in-memory client-side caching, and request coordination.

HTTP cache headers: the foundation you're probably skipping

Before reaching for a library, it's worth understanding what HTTP caching can do for you. Most React apps I've seen send API responses with Cache-Control: no-cache or no cache headers at all effectively opting out of one of the most powerful performance mechanisms in the web platform.

The Cache-Control header controls how long a response can be cached:

# Cache for 60 seconds, no revalidation needed
Cache-Control: max-age=60

# Cache but always revalidate with If-None-Match before using
Cache-Control: no-cache
ETag: "abc123"

# Serve cached version immediately, revalidate in background
Cache-Control: max-age=60, stale-while-revalidate=300

max-age tells the browser it can use the cached response for N seconds without hitting the network at all. For data that changes infrequently (user settings, feature flags, navigation structure), setting max-age=300 (5 minutes) eliminates unnecessary network round trips on every navigation.

ETag lets the server say "this is version X of this resource." On subsequent requests, the browser sends If-None-Match: "abc123". If the resource hasn't changed, the server responds with 304 Not Modified and no body the browser uses its cached copy. You save bandwidth but still pay the round-trip latency. Useful for data that changes unpredictably.

stale-while-revalidate is the most useful directive for SPA data. It means: serve the cached version immediately (no network wait), but in the background revalidate with the server. If the server has fresh data, update the cache for the next request. The user never sees a loading state they see the old data instantly, and if anything changed, it updates on the next navigation.

The actual HTTP stale-while-revalidate directive requires server-side support. But even if your API doesn't support it, you can implement the same pattern in client-side JavaScript which is exactly what React Query and SWR do.

Stale-while-revalidate in JavaScript: React Query internals

React Query (now TanStack Query) implements the stale-while-revalidate pattern in the browser's memory. Here's the mental model:

On the first request for a query key, fetch from the network and cache the result
On subsequent requests for the same key, return the cached result immediately
If staleTime has elapsed, fire a background revalidation request
When revalidation completes, update the cache and re-render components that are subscribed to this key

// Basic React Query setup
const { data, isLoading, isFetching } = useQuery({
  queryKey: ['user', 'profile'],
  queryFn: () => fetch('/api/user/profile').then(r => r.json()),
  staleTime: 60 * 1000,      // Data is "fresh" for 60 seconds
  gcTime: 5 * 60 * 1000,     // Keep in memory for 5 minutes after last use
});

// isLoading: true only on the very first fetch (no cached data)
// isFetching: true whenever a network request is in flight (including background)

The key distinction is isLoading vs isFetching. isLoading is true only when there's no cached data at all the initial state. isFetching is true during any network activity, including background revalidations. If you show your loading spinner on isFetching instead of isLoading, you'll show a spinner during every background revalidation, which is the bug we started with.

// WRONG: shows spinner during background refetches
if (isFetching) return ;

// RIGHT: only shows spinner when there's genuinely no data to show
if (isLoading) return ;
return ;

Request deduplication

Request deduplication means that if two components both request the same query key simultaneously, only one network request fires. React Query handles this automatically:

// Both of these components can exist on the same page simultaneously.
// React Query fires exactly ONE network request for ['user', 'profile'].

function Header() {
  const { data } = useQuery({ queryKey: ['user', 'profile'], queryFn: fetchProfile });
  return ;
}

function Sidebar() {
  const { data } = useQuery({ queryKey: ['user', 'profile'], queryFn: fetchProfile });
  return ;
}

Under the hood, React Query maintains a query cache keyed by the serialized query key. When the second component calls useQuery with the same key while the first request is still in-flight, it subscribes to the same pending Promise. Both components re-render when the single request resolves.

Without this, a page with 3 components all fetching the user profile would fire 3 API calls on every mount. With React Query, it's always 1. At scale across hundreds of components, dozens of users, millions of navigations this is a meaningful reduction in API server load, not just network performance.

Avoiding request waterfalls in React

The most expensive network pattern in React SPAs is the request waterfall: a component mounts, fetches data, receives the response, then fetches more data based on what it received.

// WATERFALL: this pattern creates a network chain
function UserDashboard() {
  const [user, setUser] = useState(null);
  const [posts, setPosts] = useState(null);

  useEffect(() => {
    fetchUser().then(u => {
      setUser(u);
      // Can't fetch posts until we have the userId  creates a waterfall
      fetchPostsByUser(u.id).then(setPosts);
    });
  }, []);
}

If fetchUser takes 200ms and fetchPostsByUser takes 150ms, total load time is 350ms. If you parallelize them (when you know the userId ahead of time), it's 200ms. The waterfall cost compounds with every additional sequential fetch.

React Router loaders solve this by moving data fetching outside the component tree:

// React Router v6.4+ loaders

  // These run in parallel  no waterfall
  const [user, posts] = await Promise.all([
    fetchUser(params.userId),
    fetchPostsByUser(params.userId)
  ]);
  return { user, posts };
}

function UserDashboard() {
  const { user, posts } = useLoaderData();
  // Data is already here when the component mounts
  return ;
}

Loaders run as soon as the route transition begins before the component mounts, and in parallel with each other if multiple routes load simultaneously. The component never needs a loading state for the initial data.

Prefetching strategies

Prefetching is fetching data before the user navigates to it so when they do navigate, the data is already in cache.

React Query exposes queryClient.prefetchQuery() for this:

const queryClient = useQueryClient();

// Prefetch on hover  user is probably about to click
function NavLink({ to, queryKey, queryFn, children }) {
  const prefetch = () => {
    queryClient.prefetchQuery({ queryKey, queryFn, staleTime: 10000 });
  };

  return (

  );
}

The trick with hover prefetching is that the human reaction time from hover to click is typically 100–200ms. A fast API response takes 50–150ms. If you kick off the prefetch on hover, the data is often already in cache by the time the navigation happens.

For less predictable navigation, prefetch on requestIdleCallback:

// Prefetch the most likely next routes when the browser is idle
function prefetchLikelyRoutes(queryClient) {
  requestIdleCallback(() => {
    LIKELY_NEXT_ROUTES.forEach(({ queryKey, queryFn }) => {
      queryClient.prefetchQuery({ queryKey, queryFn, staleTime: 30000 });
    });
  }, { timeout: 2000 });
}

Resource hints: preconnect, prefetch, preload

HTML resource hints give the browser signals about what to load before the page needs it:

<!-- Preconnect: establish TCP/TLS with the API domain early -->
<link rel="preconnect" href="https://api.myapp.com" />

<!-- Prefetch: download a resource in the background for future navigations -->
<link rel="prefetch" href="/dashboard" />

<!-- Preload: download a resource needed for THIS page, high priority -->
<link rel="preload" href="/fonts/inter.woff2" as="font" crossorigin />

Hint	Priority	When to use
`preconnect`	High	Known API domains you'll fetch from on page load
`dns-prefetch`	Low	Domains you might fetch from (lower cost than preconnect)
`preload`	High	Resources needed for current page (LCP image, critical font, main JS)
`prefetch`	Idle	Resources needed for likely next page (low-priority, uses idle time)
`modulepreload`	Medium	JavaScript modules needed for next route

preconnect is the easiest win. Your API domain requires DNS lookup + TCP handshake + TLS handshake before the first byte that's typically 100–300ms. With <link rel="preconnect">, that work happens while the HTML is being parsed, not when your JavaScript first calls fetch().

Priority Hints

fetchpriority tells the browser how to prioritize resource downloads:

<!-- LCP image: fetch immediately, high priority -->
![](https://renderlog.in/hero.jpg)

<!-- Below-fold image: deprioritize -->
![](https://renderlog.in/footer-decoration.jpg)

// High-priority fetch for critical data
const criticalData = await fetch('/api/critical-config', {
  priority: 'high'
});

// Low-priority fetch for analytics or non-blocking data
fetch('/api/track-view', { priority: 'low' });

The browser has a limited number of simultaneous connections per domain (typically 6 for HTTP/1.1, effectively unlimited for HTTP/2). Without priority hints, it fetches in order of discovery which might mean your LCP image is queued behind a dozen low-priority requests. fetchpriority="high" ensures the browser front-runs it.

Service Workers for network interception

A Service Worker sits between your app and the network and can implement sophisticated caching strategies:

// service-worker.js
const CACHE_NAME = 'api-cache-v1';
const CACHEABLE_APIS = ['/api/user/profile', '/api/feature-flags'];

self.addEventListener('fetch', (event) => {
  const url = new URL(event.request.url);

  if (CACHEABLE_APIS.some(path => url.pathname.startsWith(path))) {
    event.respondWith(staleWhileRevalidate(event.request));
  }
});

async function staleWhileRevalidate(request) {
  const cache = await caches.open(CACHE_NAME);
  const cached = await cache.match(request);

  // Always kick off a revalidation in the background
  const networkFetch = fetch(request).then(response => {
    if (response.ok) {
      cache.put(request, response.clone());
    }
    return response;
  });

  // Return cached immediately if available, else wait for network
  return cached || networkFetch;
}

The Service Worker pattern is more powerful than React Query alone for one reason: it works across page loads. React Query's cache lives in memory it's cleared when the user closes the tab. A Service Worker cache persists across navigations and can serve data offline.

Connection-aware fetching

The Network Information API gives you the user's connection type, which lets you adapt what you fetch:

const connection = navigator.connection;

function getImageQuality() {
  if (!connection) return 'high'; // API not supported, assume fast

  if (connection.saveData) return 'low'; // User explicitly wants to save data
  if (connection.effectiveType === '2g') return 'low';
  if (connection.effectiveType === '3g') return 'medium';
  return 'high';
}

// Adaptive image loading
const quality = getImageQuality();
const imageUrl = `/api/image/${id}?quality=${quality}`;

The API is available in Chrome and Android browsers but not Safari. Always check for its existence before using it, and never use it as the only signal fall back to a sensible default.

What the network tab tells you

When diagnosing SPA network performance, I filter the Chrome DevTools Network tab to XHR/Fetch and look for:

Duplicate requests same URL called multiple times in rapid succession (deduplication needed)
Sequential requests requests starting only after previous ones complete (waterfall pattern)
Cache misses on repeat visits Status: 200 on requests you'd expect to be 304 Not Modified (cache headers misconfigured)
Unthrottled polling the same request firing every few seconds even when nothing changed
Stacking spinners multiple loading states visible at once (data needs to be fetched in parallel, not sequentially)

The rule of thumb I use: if you see the same URL more than once in a 10-second window without explicit user action, you have a caching problem.

Putting it together

The layered approach to SPA network performance:

Layer	Mechanism	Wins
HTTP	`Cache-Control`, `ETag`, `stale-while-revalidate`	Eliminates round trips for stable data
Resource hints	`preconnect`, `preload`	Reduces connection and load latency
Client cache	React Query / SWR	Deduplication, stale-while-revalidate, garbage collection
Routing	Route loaders, parallel fetches	Eliminates sequential waterfall fetches
Prefetching	On hover, on idle	Populates cache before navigation
Service Worker	Cache-first / network-first strategies	Persistence across page loads, offline support

Each layer is independent you can add them incrementally. Start with React Query and staleTime: 60000 on your most-fetched queries, add <link rel="preconnect"> for your API domain, and measure. The 800ms spinner on every navigation usually disappears after just the first two steps.

Read the original article on Renderlog.in:
https://renderlog.in/blog/network-optimization-spa-react/

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

DOM Performance on Mobile: Lab vs Real Device Reality

Ashish Kumar — Mon, 27 Apr 2026 00:30:00 +0000

Style recalculation on a page with 10,000 DOM nodes takes ~180ms on a budget Android — 10x the entire 16.6ms frame budget. The exact same scroll that is imperceptible on a developer MacBook drops 90% of frames on a Redmi Note 9 or Samsung A-series device.

Why desktop profiling is misleading: The V8 engine on a budget Android runs at 5–10x lower throughput than on a developer laptop. Chrome's 6x CPU throttle preset is still optimistic for real low-end hardware. The only reliable signal is remote debugging on physical budget devices.

What this covers: DOM size and style recalculation benchmarks on real hardware, content-visibility: auto, CSS contain, passive touch event listeners, IntersectionObserver vs scroll events, and the full mobile debugging workflow.

The mobile hardware reality

Before getting into fixes, it's worth internalizing exactly why budget phones are so much slower not as an abstraction, but as a design constraint.

A typical mid-range Android in 2026 (Redmi Note series, Samsung A-series, Motorola G-series) has:

2–4 CPU cores running at 1.5–2.0 GHz, compared to your MacBook's 8–10 cores at 3–4 GHz
3–4GB RAM (often shared with the OS, background apps, and the GPU)), with aggressive memory pressure killing background tabs
No separate GPU memory the integrated GPU (shares RAM bandwidth with the CPU
Thermal throttling: after 2–3 minutes of heavy load, the chip throttles to 60–70% of its peak frequency to avoid overheating
A **V8 JavaScript engine: that's the same version as desktop but running on a fraction of the hardware

The V8 engine on a budget Android is typically 5–10x slower at JS execution than on a developer laptop. Not because the software is different it's the same engine but because the hardware is so much weaker. The JIT compiler has less time budget, inline caches fill differently, and garbage collection pauses are longer in relative terms.

The consequence: performance profiling on your development machine is actively misleading. You will mark tasks as "fast" that are catastrophically slow on real user hardware.

Chrome DevTools CPU throttling isn't enough

Chrome's "6x slowdown" CPU throttle in DevTools is a software throttle: it introduces artificial delays in the main thread scheduling. It doesn't simulate reduced memory bandwidth, it doesn't simulate thermal throttling, and it doesn't simulate the actual V8 JIT behavior on ARM hardware with constrained memory.

It's better than nothing. But I've found that even the 6x throttle is optimistic compared to a Redmi Note 9 or a Realme 8. Real users are often on hardware that would show up as 8–12x slower in practice.

The only reliable signal is remote debugging on real hardware.

# On Android: enable Developer Options, enable USB Debugging
# On your laptop:
chrome://inspect/#devices

Connect your phone, open the app in Chrome on the phone, and it shows up in chrome://inspect. You get the full DevTools Performance panel Timeline, flame charts, frame rate running against the real hardware. I've started keeping a Redmi Note 9 on my desk specifically for this.

DOM size and style recalculation cost

Here's the fundamental problem with large DOM trees that most developers don't feel until they test on mobile: CSS selector matching is O(n) per element per style recalculation, and it scales badly.

When you invalidate styles on a node (by adding a class, changing a property, or causing a reflow), the browser must re-run selector matching for potentially large subtrees. Selectors are matched right-to-left the browser finds all elements that match the rightmost part of the selector, then walks up the tree checking each parent. A selector like .sidebar .nav-item a:hover can be surprisingly expensive if .sidebar contains hundreds of elements.

Chrome's DevTools calls this "Recalculate Style" in the Performance panel. When you see it taking 50ms+ on a frame, you have a DOM size / selector complexity problem.

Some real numbers from my testing (Redmi Note 9, Chrome 122):

DOM node count	Recalc Style time (class toggle)
500 nodes	~4ms
1,500 nodes	~14ms
3,000 nodes	~35ms
6,000 nodes	~90ms
10,000 nodes	~180ms

At 10,000 nodes, a single class toggle on a parent element costs 180ms 10x the entire 16.6ms frame budget. This is directly why our user's phone was "unusable."

The fix is straightforward in principle: fewer nodes. In practice, this means:

Virtualizing long lists (only render what's in the viewport)
Not using deep nesting for layout purposes that could be flattened
Avoiding display: none containers that still exist in the DOM they still participate in style matching
Auditing third-party components that inject dozens of wrapper divs for no structural reason

Mounting discipline: deferring below-fold components

One of the highest-leverage changes on the scroll path is deferring the mounting of below-fold components. If a component isn't visible when the page loads, you don't need it in the DOM immediately.

The naive approach is requestIdleCallback:

// Don't mount everything at once
function BelowFoldSection() {
  const [mounted, setMounted] = useState(false);

  useEffect(() => {
    const id = requestIdleCallback(() => setMounted(true), { timeout: 3000 });
    return () => cancelIdleCallback(id);
  }, []);

  if (!mounted) return <div style={{ minHeight: '400px' }} />;
  return ;
}

The better approach for scroll-triggered content is IntersectionObserver:

function LazySection({ children, placeholder }) {
  const [visible, setVisible] = useState(false);
  const ref = useRef(null);

  useEffect(() => {
    const observer = new IntersectionObserver(
      ([entry]) => { if (entry.isIntersecting) setVisible(true); },
      { rootMargin: '200px' } // Start loading 200px before it enters viewport
    );
    if (ref.current) observer.observe(ref.current);
    return () => observer.disconnect();
  }, []);

  return <div ref={ref}>{visible ? children : placeholder}</div>;
}

The 200px rootMargin gives you a buffer: components start mounting before the user scrolls to them, so there's no visible loading flash. Measure the actual mount cost of each section in the Performance panel before deciding which ones to defer.

`content-visibility: auto`

CSS content-visibility: auto is a one-liner that tells the browser to skip layout and paint for off-screen content entirely. It's essentially the CSS-native version of the above IntersectionObserver pattern, but implemented at the rendering engine level rather than in JavaScript.

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: 0 500px; /* Hint for placeholder height */
}

When an element with content-visibility: auto is off-screen, the browser skips its layout and paint entirely. It doesn't remove it from the DOM (the content is still there and accessible), but the browser treats it as if it has visibility: hidden for rendering purposes. When it scrolls into view: the browser renders it on demand.

The contain-intrinsic-size property gives the browser a fallback size to use for layout calculations while the content isn't rendered. Without it, the element collapses to 0 height, which makes scrollbar sizing wrong and can cause layout jumps as content renders.

The limitation: if your sections have genuinely variable heights and you don't know them ahead of time, contain-intrinsic-size requires estimation. Google shipped a auto keyword (contain-intrinsic-size: auto 500px) that remembers the last rendered size, which handles this in most cases.

The performance improvement is real. The Chrome team's case study showed 7x rendering improvement on a long article page. On mobile hardware with 3,000+ nodes in a long-form page, this is one of the highest-ROI CSS changes you can make.

CSS `contain` property

content-visibility uses CSS containment under the hood. Understanding containment directly gives you finer-grained control.

.card {
  contain: layout style paint;
}

The contain property tells the browser that changes inside this element cannot affect anything outside it. There are four containment types:

Containment	What it does
`layout`	Layout inside this element cannot affect outside layout. Enables layout isolation.
`style`	CSS counters and quotes are scoped to this element.
`paint`	Content outside this element's bounds is not painted. Enables paint isolation.
`size`	The element's size is independent of its children. Required for intrinsic-size guarantees.

The practical value of contain: layout paint on card components is that a re-layout inside one card doesn't trigger a full page reflow. On mobile, where reflows are expensive, this is meaningful.

`contain: strict: is shorthand for all four types use it for truly isolated widgets like ads, embeds, or sidebar components that have fixed sizes and no cross-document layout relationships.

Touch scroll performance

iOS has a history with scrolling that explains several CSS properties you'll see in older codebases:

css /* This was required in iOS <13 for momentum scrolling */ .scroll-container { overflow: scroll; -webkit-overflow-scrolling: touch; /* Deprecated but still seen */ }

-webkit-overflow-scrolling: touch was originally required on iOS to get the native momentum scroll behavior inside overflow containers. It's been deprecated since iOS 13 (the browser now handles it automatically), but it still appears in codebases. You can safely remove it today.

What still matters is passive event listeners for touch handlers:

`js
// BAD: blocks scroll until handler returns
element.addEventListener('touchstart', handler);

// GOOD: tells browser the handler won't call preventDefault()
element.addEventListener('touchstart', handler, { passive: true });
`

When a touch event listener is registered without { passive: true }, the browser must wait for your handler to return before it can scroll because your handler might call e.preventDefault() to cancel the scroll. This waiting introduces scroll jank. With { passive: true }, the browser knows it can start scrolling immediately without waiting.

Chrome DevTools will warn you about non-passive scroll listeners in the console:

[Violation] Added non-passive event listener to a scroll-blocking event

This is one of the easiest performance wins on mobile: just add { passive: true } to every touchstart, touchmove, and wheel listener that doesn't need to block the scroll.

Scroll jank: the full picture

Scroll jank sources ranked by how often I see them in real apps:

Source	Cause	Fix
Non-passive listeners	Browser waits for JS before scrolling	`{ passive: true }`
Layout reads during scroll	`getBoundingClientRect()` / `offsetTop` in scroll handler	Batch reads, use IntersectionObserver
Heavy onscroll handlers	DOM manipulation, state updates every pixel	Throttle with `requestAnimationFrame`
Large DOM	Style recalc dominates frame time	Virtualize lists, reduce node count
Compositor-layer overflow	Too many `will-change` / `transform: translateZ(0)`	Audit GPU memory usage

The requestAnimationFrame pattern for scroll handlers is worth knowing:

`js
let lastScroll = 0;
let ticking = false;

window.addEventListener('scroll', () => {
lastScroll = window.scrollY;

if (!ticking) {
requestAnimationFrame(() => {
updateUI(lastScroll);
ticking = false;
});
ticking = true;
}
}, { passive: true });
`

This ensures your scroll handler runs at most once per frame, aligned with the browser's render schedule, rather than potentially dozens of times between frames.

IntersectionObserver vs scroll events

IntersectionObserver is off the main thread. The browser handles the intersection calculations in a separate process and delivers callbacks to your JavaScript only when intersection ratios change. This means it doesn't fire dozens of times per scroll only when something actually enters or exits the viewport.

`js
const observer = new IntersectionObserver((entries) => {
entries.forEach(entry => {
// This callback is batched and off-main-thread for intersection math
entry.target.classList.toggle('visible', entry.isIntersecting);
});
}, { threshold: 0.1 });

document.querySelectorAll('.animate-on-scroll').forEach(el => observer.observe(el));
`

Compare this to the scroll event approach that was common five years ago:

js // Don't do this on mobile window.addEventListener('scroll', () => { document.querySelectorAll('.animate-on-scroll').forEach(el => { const rect = el.getBoundingClientRect(); // Forces layout! if (rect.top < window.innerHeight) { el.classList.add('visible'); } }); });

The scroll version runs on the main thread, calls getBoundingClientRect() on every element (which forces a layout flush), and executes potentially hundreds of times per second. On a Redmi Note 9, this will stutter.

Input latency: the 300ms tap delay

Until around 2017, mobile browsers introduced a 300ms delay before firing click events from taps. The reason: the browser needed to wait to see if the tap was the first tap of a double-tap zoom gesture. This is now mostly resolved, but the fix is worth knowing:

css /* Eliminates 300ms tap delay on elements */ .button { touch-action: manipulation; }

touch-action: manipulation tells the browser this element supports tap and pan but not double-tap-to-zoom, so the 300ms wait isn't needed. Modern browsers (Chrome 55+, Safari 13+) have removed the delay globally for pages with a <meta name="viewport" content="width=device-width"> tag, but touch-action: manipulation is belt-and-suspenders for interactive elements on older devices.

Images on mobile

Image rendering is a surprising source of main thread cost on mobile:

`html

The three attributes that matter for mobile performance:

loading="lazy": defers fetching images outside the viewport. On a page with 20 images, this can save 5–10MB of initial load on mobile.
decoding="async": tells the browser to decode the image off the main thread. Without this, large image decodes happen synchronously and can spike frame times.
sizes: tells the browser which image to download based on the viewport width. Without accurate sizes, the browser guesses wrong and often downloads the full-size image on a phone.

Always specify explicit width and height on images. Without them, the browser can't reserve space for the image before it loads, causing Cumulative Layout Shift which is even more jarring on mobile where reflows are slower.

Putting it together

The mobile performance debugging workflow I follow now:

Profile on real hardware don't trust desktop throttle
Check DOM node count anything over 1,500 nodes in the initial render deserves scrutiny
Add content-visibility: auto to long-page sections
Add { passive: true } to all scroll/touch listeners
Replace scroll listeners with IntersectionObserver where possible
Check for getBoundingClientRect() in scroll handlers (it forces layout)
Virtualize any list over 100 items use react-virtuoso or @tanstack/virtual
Set explicit image dimensions and add loading="lazy" + decoding="async"

Budget mobile devices are not edge cases: they're often the majority of your users' hardware outside of North America and Western Europe. Building with that constraint in mind from the start is dramatically cheaper than retrofitting it after your analytics start showing high bounce rates on Android.

Read the original article on Renderlog.in:
https://renderlog.in/blog/mobile-web-dom-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

React Re-rendering: When and Why Component Trees Update

Ashish Kumar — Sun, 26 Apr 2026 00:30:00 +0000

Related: Long Tasks and Main Thread Blocking heavy React renders are one of the most common sources of Long Tasks.

React's default re-render behavior is intentionally conservative: when a parent re-renders, all children re-render too. This is correct by default — React prioritizes correctness over performance, and render-phase work (function calls, hook execution) is cheap enough that unnecessary re-renders are often harmless. But "often harmless" is not "always harmless."

What this covers: The exact four triggers that cause a component to re-render, how reconciliation and the fiber tree work, why referential equality matters for memoization, the context performance trap, and how to read the React DevTools Profiler to find the root cause of unexpected re-renders.

Render phase vs commit phase

React's work of "updating the UI" is split into two fundamentally different phases. Confusing them is the root of a lot of performance misconceptions.

The render phase

The render phase is when React calls your component functions and figures out what the UI should look like. When you call setState, React schedules a render. During the render phase, React:

Calls the component function (your function component body executes).
Calls all the hooks in order (useState, useEffect, useMemo, etc.).
Gets the returned JSX.
Does this recursively for any child components that also need updating.
Diffs the new output against the previous output (reconciliation).

Critical insight: the render phase is pure work: React is just computing what the UI should be. **It doesn't touch the DOM yet.* Your component function can be called and produce output that React then decides to discard (this is what StrictMode's double-render exploits see below).

The commit phase

The commit phase is when React actually applies changes to the DOM. It has three sub-phases:

Before mutation: fires getSnapshotBeforeUpdate lifecycle and captures current DOM state.
Mutation: applies DOM insertions, updates, and deletions. This is the only time React directly touches the DOM.
Layout: fires useLayoutEffect and componentDidMount/componentDidUpdate synchronously. This is why useLayoutEffect can measure DOM layout the DOM is updated but the browser hasn't painted yet.
After the commit, useEffect callbacks are scheduled for after the browser has painted.

Understanding this split matters because: render phase work is cheap to do multiple times (it's just function calls and object comparisons). Commit phase work touches the DOM and can trigger browser reflow. React is clever about doing as little DOM work as possible.

Reconciliation and the fiber tree

React doesn't just compare new JSX against a flat list of DOM elements. It maintains an internal data structure called the fiber tree a graph of objects representing every component instance in your app, including their state, hooks, and pending work.

Each fiber corresponds to one component instance. When a state update is triggered, React creates an alternative "work in progress" fiber tree and starts reconciling it against the current tree. This is the reconciliation algorithm.

What reconciliation does:

Compares new JSX element type against the existing fiber's type.
If the type changed (e.g., <Button> became <a>), React unmounts the old component tree and mounts a fresh one.
If the type is the same, React updates the existing fiber with new props, runs hooks again, and recurses into children.
For lists, it uses keys to match new elements to existing fibers.

The key performance insight: reconciliation is proportional to the size of the fiber tree that gets re-rendered. If you trigger a re-render high in the tree, React walks down through all descendants. This is why the settings checkbox caused 47 re-renders the useState was placed in a component that was the parent of almost everything.

What triggers a re-render

There are exactly four causes of a React component re-rendering:

Trigger	Description
setState call	Calling the setter from `useState` or `useReducer` dispatch
Props change	Parent re-renders and passes new prop values (by reference)
Context value changes	Any consumer of a context re-renders when the context value changes
Parent re-renders	A component re-renders when its parent re-renders, even if props didn't change

The fourth one surprises people the most. In React's default behavior, if a parent re-renders, all children re-render too regardless of whether their props changed. This is the default: without memoization, the component tree re-renders in a cascade from the component that triggered the state change, downward.

This is actually a deliberate design choice. React assumes that re-rendering is cheap (it's just function calls) and that computing whether to skip a render is sometimes more expensive than just doing the render. The defaults are optimized for correctness, not maximum performance.

Re-renders don't mean DOM updates

This is a crucial clarification that trips up a lot of performance investigations.

When 47 components re-render, React calls 47 component functions and gets back 47 JSX trees. Then it diffs those against the previous output. If the output is identical, React makes zero DOM changes for that component. No DOM mutations, no browser reflow, nothing.

So "47 components re-rendered" in React DevTools means "47 component functions were called, not "47 DOM nodes were updated." The actual DOM impact depends on how many of those components produced different output.

This distinction matters because: pure render cost (function calls, hook execution) is usually cheap. DOM mutation cost is what triggers browser layout and paint. If your 47 re-rendering components all produce the same output as before, you might have wasted 2ms of JavaScript time, but you've caused zero additional browser rendering work.

That said, 47 function calls isn't free: if any of those functions do expensive computations inline (without useMemo), or if React itself has to run through complex reconciliation logic, you'll feel it.

Why referential equality matters

This is where function components differ fundamentally from the mental model of "props changed = new values." React uses referential equality (===) to compare props and determine if a memoized component should skip its render.

function Parent() {
  const [count, setCount] = useState(0);

  // ⚠️ New object reference created on every render
  const config = { theme: 'dark', size: 'medium' };

  // ⚠️ New function reference created on every render
  const handleClick = () => setCount(c => c + 1);

  return (
    <>


    </>
  );
}

Every time Parent re-renders, config and handleClick are brand new objects. They're deeply equal to the previous values (same shape, same content) but config === previousConfig is false because they're different object references.

If Settings is wrapped in React.memo, it will still re-render because its config prop is a new reference, even though nothing meaningfully changed.

// useMemo stabilizes the reference between renders
const config = useMemo(() => ({ theme: 'dark', size: 'medium' }), []);

// useCallback stabilizes function references
const handleClick = useCallback(() => setCount(c => c + 1), []);

useMemo and useCallback are not about avoiding "expensive computations: they're primarily about referential stability. Their main job is to prevent downstream re-renders caused by new object/function references.

The context performance problem

Context is often described as a solution for "prop drilling: passing data through many levels of components. It is that. It's also a performance footgun if you're not careful about what you put in it.

Context is a broadcast. When the context value changes, every component that consumes that context re-renders, regardless of whether the specific piece of data it reads changed.

// ⚠️ This context re-renders ALL consumers when ANYTHING in the object changes
const AppContext = createContext({
  user: null,
  theme: 'light',
  notifications: [],
  sidebarOpen: false,
});

function App() {
  const [sidebarOpen, setSidebarOpen] = useState(false);

  // New object reference when sidebarOpen changes
  // → Every context consumer re-renders, including deep UI components that only care about `user`
  const value = { user, theme, notifications, sidebarOpen };

  return <AppContext.Provider value={value}>{children}</AppContext.Provider>;
}

Toggling the sidebar causes every consumer of AppContext to re-render, including components that only ever read user. The fix is to split context by update frequency:

// Stable values that rarely change
const UserContext = createContext(null);
// Dynamic values that change often
const UIStateContext = createContext({ sidebarOpen: false });

// Now sidebar state changes only affect UIStateContext consumers

A useful mental model: each context should have one reason to change. If your context value object contains both stable auth data and frequently-changing UI state, you'll cause unnecessary re-renders across the entire consumer tree.

Keys in lists: what they actually do

Keys serve a specific mechanical purpose during reconciliation. React uses keys to match new list elements to existing fibers when the list changes. Without keys (or with incorrect keys), React falls back to matching by position.

// Without keys  React matches by index
// Adding an item to the beginning: React thinks EVERY item changed
{items.map((item, index) => (

))}

// With stable IDs: React correctly identifies which item was added
{items.map(item => (

))}

When you use key={index} and prepend an item to the list, React sees:

Position 0: had {id: 1}, now has {id: 0} → update this fiber
Position 1: had {id: 2}, now has {id: 1} → update this fiber
etc.

Every fiber gets updated because positions changed, even though only one item was added. With stable IDs, React sees that existing fibers just shifted position and correctly reconciles with minimal work.

The random-key anti-pattern is even worse:

// ⚠️ Generates a new key on every render  destroys all reconciliation benefits
{items.map(item => (

))}

With random keys, every render unmounts all existing Card components and mounts fresh ones. You lose all component state, all DOM node reuse, and get maximum mount/unmount work on every render.

React 18 automatic batching

Before React 18, state updates inside setTimeout, Promise.then, or native event handlers were processed individually: one setState = one re-render.

// React 17: 2 renders
setTimeout(() => {
  setCount(c => c + 1); // Render 1
  setLoading(false);    // Render 2
}, 1000);

// React 18: 1 render (automatic batching)
setTimeout(() => {
  setCount(c => c + 1); // Batched
  setLoading(false);    // Batched → single render
}, 1000);

React 18's automatic batching extends the existing batching behavior (which previously only worked in React event handlers) to all asynchronous contexts. This is a free performance improvement that many apps benefit from immediately after upgrading.

The cases where this matters most: fetch callbacks that update multiple state values, async event handlers that set loading + data states together, and any code that does multiple setState calls in a row in async code.

If you need to explicitly opt out of batching (rare), flushSync from react-dom forces synchronous processing:


// Forces immediate render after each setState
flushSync(() => setCount(1));
flushSync(() => setLoading(false));

StrictMode's double-render in development

If you're using React.StrictMode (you should be in development), your component functions are called twice during the render phase in development mode. This is intentional and a source of confusion for developers who see their console.log appearing twice.

What StrictMode is doing: it deliberately calls your component function twice to check that the function is pure that calling it multiple times with the same inputs produces the same output. If your component has side effects in the render phase (network requests, direct DOM mutations, setting external variables), the double-render will expose them because those effects will fire twice.

function BadComponent() {
  // ⚠️ Side effect in render  this fires twice in StrictMode development
  someGlobalCounter++;

  return <div>{someGlobalCounter}</div>;
}

The double-render only happens in development mode. Production builds render once. If something works in development but breaks in production differently, StrictMode's double-render is not the cause but the bugs it exposes in development might surface as subtle issues in production.

Reading the React Profiler

The React DevTools Profiler is the right tool for understanding re-renders. Open DevTools → Components → Profiler. Hit Record, do the interaction that feels slow, stop recording.

The flame chart shows every component that rendered, how long it took, and crucially why it rendered:

Props changed one or more props have a different reference than the previous render.
State changed a useState or useReducer hook in this component changed.
Context changed a context this component subscribes to changed.
Parent re-rendered no local reason, but the parent rendered so this did too.
Hooks changed a hook produced a different value than before.

The "why did this render?" information is invaluable for diagnosing unnecessary re-renders. When you see "parent re-rendered" for a component that shouldn't care about its parent's state change, that's the target for React.memo. When you see "props changed" for a memoized component that's receiving an object prop, that's the target for useMemo.

Profiler "Why"	Likely fix
"Parent rendered" on a pure display component	Wrap with `React.memo`
"Props changed" on a memoized component	Stabilize prop reference with `useMemo`/`useCallback`
"Context changed" but component only reads one field	Split context by update frequency
"State changed" unexpected	Check if the state is co-located at the right level

The Profiler also shows total render duration per component. If a single component consistently takes 15ms+ to render, that's a component-level optimization opportunity either memoizing expensive calculations inside it or splitting it into smaller pieces.

Read the original article on Renderlog.in:
https://renderlog.in/blog/react-rerendering-when-trees-update/

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

OCR in the Browser: How Tesseract.js Makes PDF Text Extraction Free

Ashish Kumar — Sat, 25 Apr 2026 13:49:28 +0000

You've got a 200-page PDF that someone scanned years ago. It's just images of pages — Cmd-F finds nothing. You need to extract the text, search through it, maybe paste a paragraph into a doc.

Five years ago, this meant a cloud OCR API at $1.50 per 1,000 pages, plus uploading your potentially-sensitive PDF to a third-party service. Now it means dropping the file into a tab and waiting two minutes. The thing that made the difference is Tesseract.js — and understanding what it does, where it shines, and where it falls short is worth knowing whether you're building a tool or just trying to get text out of a scan.

This post walks through how browser-based OCR actually works, what to expect from the open-source state of the art, and the engineering decisions that go into shipping it well.

What OCR is, briefly

Optical character recognition takes an image of text and produces actual text characters. Modern OCR engines do this in two stages:

Layout analysis — figure out where the text regions are on the page, in what order they should be read, and where lines and words break.
Character recognition — for each detected word, classify the visual pattern as one of the characters it could be.

Step 2 used to use rule-based image processing (look at the shape, match against templates). Modern engines including Tesseract use neural networks (LSTMs, mostly) trained on huge corpora of text in different fonts and conditions.

The accuracy of a modern OCR engine on clean printed text is 95–99%. On handwriting, multi-column layouts, tables, or low-quality scans, it drops fast. We'll come back to that.

Tesseract: 30 years of OCR, now in your browser

Tesseract is the open-source OCR engine that's been around since 1985. HP wrote it, then it sat unused for a decade, then Google rescued it in 2005, rewrote the engine in 2018 to use LSTMs, and kept improving it. It supports 100+ languages, runs as a command-line tool, and is the engine behind a huge fraction of OCR products you've used.

Tesseract.js is Tesseract compiled to WebAssembly. Same accuracy as the desktop version, runs in any modern browser, no server required. The whole thing is about 8MB compressed (engine + a single language pack), loads on demand, and processes pages at maybe 1–3 seconds each on a typical laptop.

The basic usage is comically simple:

import Tesseract from 'tesseract.js'

const { data: { text } } = await Tesseract.recognize(
  imageOrCanvasOrUrl,
  'eng',
  { logger: m => console.log(m) }
)

console.log(text)

That's it. Pass an image, get back text. The logger is useful because OCR isn't instant — typical pages take a few seconds, and you want a progress bar.

The PDF-to-text pipeline

Tesseract operates on images, not PDFs. So the full pipeline for "OCR a scanned PDF" is:

Open the PDF (use pdf.js)
Render each page to a canvas
Pass the canvas to Tesseract.js
Concatenate the results

The skeleton looks like:

import * as pdfjs from 'pdfjs-dist'
import Tesseract from 'tesseract.js'

async function ocrPdf(file) {
  const buffer = await file.arrayBuffer()
  const pdf = await pdfjs.getDocument(buffer).promise
  const pages = []

  for (let i = 1; i <= pdf.numPages; i++) {
    const page = await pdf.getPage(i)
    const viewport = page.getViewport({ scale: 2 })  // 2x for OCR accuracy
    const canvas = document.createElement('canvas')
    canvas.width = viewport.width
    canvas.height = viewport.height
    await page.render({ canvasContext: canvas.getContext('2d'), viewport }).promise

    const { data: { text } } = await Tesseract.recognize(canvas, 'eng')
    pages.push(text)
  }

  return pages.join('\n\n')
}

A few details that matter:

Render at 2× or 3× scale. OCR accuracy correlates strongly with resolution. The native PDF DPI (72 or 96) is usually too low; bumping to 2× makes a noticeable difference.
Process pages sequentially. Tesseract.js can run multiple workers in parallel, but each worker loads ~8MB of language data, so on memory-constrained devices, sequential is safer.
Show progress. OCR is slow. A 50-page document at 2 seconds/page is 100 seconds — without a progress indicator, users think the page froze.

Web Workers for the UI

If you call Tesseract.recognize directly on the main thread, the page becomes janky during processing. Tesseract.js comes with built-in Worker support — every recognize call runs in a worker by default, but you can also pre-spin workers and reuse them:

const worker = await Tesseract.createWorker('eng')
for (const canvas of canvases) {
  const { data: { text } } = await worker.recognize(canvas)
  // ...
}
await worker.terminate()

Reusing one worker for multiple pages avoids repeated language-data loading. For batches, this is 3–5× faster than the simple form above.

Language packs

Tesseract supports 100+ languages, but each language is a separate trained data file (5–25MB compressed). You don't bundle them — you download on demand:

const worker = await Tesseract.createWorker(['eng', 'spa'])  // English + Spanish

For a multilingual OCR app, the data-loading strategy matters. Don't ship all 100 language packs in your bundle; let users select languages and lazy-load.

A few practical notes:

English is by far the best-tuned. CJK languages (Chinese, Japanese, Korean) work but are slower and slightly less accurate.
Mixed-language documents are tricky. Tesseract supports passing multiple languages, but it tries to apply all of them to every word — this is slower and sometimes less accurate than running it in single-language mode.
Math and code are recognized poorly. OCR engines were trained on natural-language text. Variable names, equations, and code samples often come out scrambled.

Where OCR falls down

Even on clean printed text, you'll hit cases that break:

Low-resolution scans. Anything below 200 DPI gets unreliable. Below 150 DPI, accuracy drops to 70–80%. If your input is a phone photo of a printed page taken in dim light, OCR will struggle.

Multi-column layouts. Tesseract has a layout analyzer, but it sometimes reads across columns instead of down them, producing scrambled output. Newspapers and academic papers are the classic problem cases.

Tables. Tesseract can extract the text from a table, but it loses the structure. You get a flat stream of cell contents in some order. For real tabular data extraction you need a different tool entirely (or a model fine-tuned on table layouts).

Handwriting. Out of scope for Tesseract. Use a model trained for handwriting (Google Cloud Vision, AWS Textract, or specialized libraries). The accuracy gap is enormous.

Low-contrast or skewed pages. Pre-processing helps a lot. Convert to grayscale, increase contrast, deskew. There are JavaScript libraries (opencv.js, cv-tools) that do these transformations in the browser before OCR.

Forms and structured documents. OCR gives you text. It doesn't tell you "this string is the patient's date of birth and this one is the diagnosis." For structured extraction, you need OCR + a separate parsing step (regex, NER models, or templated extraction).

Cloud OCR vs Tesseract.js — when to pick which

Cloud OCR services (Google Cloud Vision, AWS Textract, Azure Computer Vision) are still better than Tesseract on hard cases. They handle handwriting, complex tables, multilingual documents, and edge cases that Tesseract struggles with. They're trained on far more data.

But Tesseract.js wins on three axes:

Privacy — files never leave the browser
Cost — free, no per-page pricing, no API keys
Simplicity — no signup, no auth, no rate limits

The decision rule: for printed-text OCR where you control the inputs (PDFs, screenshots, document scans), Tesseract.js is good enough most of the time. For high-stakes accuracy on edge-case inputs (handwritten forms, mixed handwriting/print, low-quality phone photos of receipts), use a cloud API.

A practical caveat: PDFs that already have text

A surprising fraction of "scanned" PDFs actually have text in them — they were scanned, then put through an OCR pass at the printer or by another tool, and the text is embedded but invisible because the visual layer is the scan. Before running expensive OCR, check:

const page = await pdf.getPage(1)
const textContent = await page.getTextContent()
if (textContent.items.length > 0) {
  // PDF already has text — skip OCR
}

Saves a lot of CPU when the work is already done.

Where to try OCR right now

For a one-off (you have a scanned PDF, you need the text, you don't want to write code), imagetools.renderlog.in and pdftools.renderlog.in both run Tesseract.js client-side. The PDF tool's OCR feature handles the pdf.js → canvas → Tesseract pipeline described above. Drop a PDF in, get text out, file never leaves the browser.

For the actual implementation in your own app, the Tesseract.js GitHub repo is well-documented and the API hasn't changed much in years.

TL;DR

Tesseract.js puts a battle-tested OCR engine in any modern browser at no per-page cost.
The pipeline for OCRing a PDF is: pdf.js renders pages to canvases → Tesseract.js recognizes each canvas → concatenate the text.
Render at 2–3× scale for accuracy. Use Web Workers (built in) to keep the UI responsive.
Pre-check if PDFs already have a text layer before running OCR; many do.
Tesseract is excellent on clean printed text, weak on handwriting, tables, and very low-quality inputs.
For privacy-sensitive documents (medical, legal, contracts), client-side OCR removes the cloud-API trust problem entirely.

Browser-based OCR went from "tech demo" to "ship this in production" in about three years. If you're still uploading scans to a paid API for printed-text extraction, it's worth a re-evaluation.

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)
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)

Why Client-Side PDF Tools Beat Server Uploads (Privacy, Speed, and Cost)

Ashish Kumar — Sat, 25 Apr 2026 13:48:46 +0000

You need to compress a PDF. You search "compress PDF online", land on a popular site, drag your file in, wait, download the result. Easy.

Now let me ask: what was in that file? A passport scan? A signed contract? Your tax return? A medical report? An NDA from your employer?

You uploaded it to a server. Their server, probably backed up, probably logged, probably handled by a third party. The terms of service almost certainly include something about "we may use your files to improve our service." Even if they delete it after an hour — and you're trusting them to — there's a window where it sat in cleartext on a machine you don't control.

This isn't paranoid. This is what most "free PDF tools" actually do. And it's no longer necessary. Modern browsers can do almost everything those tools do, locally, in your tab, without uploading anything. This post is about why that's a meaningful shift, what made it possible, and what the trade-offs actually are.

How we ended up uploading PDFs to servers

Server-side became the default in the 2010s for a good reason: PDF parsing in JavaScript was awful. The format is decades-old, full of legacy quirks, supports embedded fonts and color profiles and JavaScript and form fields and digital signatures. Implementing even a slice of that in browser JavaScript meant slow, buggy code that worked on simple PDFs and crashed on complex ones.

So PDF tool sites used the obvious workaround: spin up a backend in Python or Java, run a battle-tested library like pdftk, Ghostscript, or iText, and let the browser just upload and download. It worked. Users didn't know — or didn't think about — what their files went through on the way there and back.

Two things changed.

What changed: pdf.js and WebAssembly

pdf.js is the PDF rendering library Mozilla built for Firefox in 2011. It's the engine that displays PDFs natively in the browser without a plugin. Over the years it grew capabilities beyond rendering — extracting text, manipulating pages, handling annotations. It's not perfect, but it's solid for 90% of real PDFs.

WebAssembly changed the second half. Wasm lets you compile high-performance C, C++, and Rust code to a binary format that runs in the browser at near-native speed. Suddenly the same Ghostscript or MuPDF that powered server-side tools could run inside the user's browser. Compression, OCR, format conversion — all the heavy work that used to require a Python service became a Wasm module loaded over HTTP.

By 2022, the toolchain was ready: pdf.js for parsing, Wasm-compiled imaging libraries for compression and conversion, modern browser APIs (Web Workers, OffscreenCanvas) for keeping the UI responsive. A modern browser running on a modern laptop can compress a 50MB PDF faster than a free-tier server can.

The privacy angle

This is the part that matters most to most users.

When you upload a PDF to a server-side tool:

The file traverses your network in plaintext (well, TLS, but it leaves your machine encrypted-in-transit, decrypted-at-rest)
It sits on a third-party machine for some window of time
It may be backed up, cached at a CDN, logged, or analyzed
The provider's privacy policy probably says they delete it after some time, but you have no way to verify
A breach of that provider exposes every file uploaded that day

When you process the same file in a client-side tool:

The file never leaves your browser
No server has a copy, even temporarily
A breach of the tool provider doesn't expose your files
You can use it offline (after the JavaScript loads once)
You can use it with files you legally aren't allowed to upload elsewhere (NDAs, classified-by-contract material, customer PII)

For most personal use, this is "nice to have." For lawyers, medical professionals, government workers, or anyone subject to compliance regimes (HIPAA, GDPR, SOC 2), this is the difference between a tool you can use and one you can't.

The speed angle

Counterintuitively, client-side is often faster than server-side for everyday workflows. The reason: upload time.

A 20MB PDF over a typical home internet upload (10–50 Mbps) takes 4–20 seconds just to reach the server. Then it processes. Then it downloads back. Round-trip on a typical residential connection: 15–45 seconds for processing that takes 2 seconds on the server itself.

A client-side tool skips the round-trip entirely. The same 20MB PDF compresses in 5–10 seconds total, all CPU time, no network. On large files the client-side approach can be 5× faster end-to-end despite using slower hardware.

The exception is genuinely heavy work — OCR on a 500-page scan, batch processing 100 PDFs at once, conversion to obscure formats. There the server's beefier CPU and shared GPUs win. For the 95% of PDF tasks that are merge, split, compress, and basic conversion, the client wins.

The cost angle (for tool builders)

This one's for the developer in you, not the user.

A server-side PDF tool pays per request. Even at $0.0001 per processed file, a tool that handles 100,000 PDFs/day costs $300/month in compute alone. Add bandwidth, storage, and the engineering time to keep the pipeline running. Most "free" PDF tools cover this cost with ads, upsells to premium tiers, or selling user data. None of those align the tool's incentives with yours.

A client-side tool pays for the JavaScript bundle once, hosts static files on a CDN, and serves unlimited users at near-zero marginal cost. Your CPU does the work the server used to. The economics flip from "monetize per user" to "build it once, serve it forever."

This is why client-side tools tend to be free without ads. They cost nothing to run, so they have no pressure to monetize aggressively.

The trade-offs (because there always are some)

Client-side PDF processing isn't a strict upgrade. The honest list:

File size limits. Browser memory is finite. A 500MB PDF that runs fine on a server may crash a tab on a 4GB laptop. Tools usually cap at 100–200MB. If you're regularly working with multi-hundred-MB PDFs, server-side has more headroom.

CPU intensity. Heavy operations spin up the user's CPU. Mobile devices feel it. A 5-minute OCR pass on a 200-page scanned document drains battery and warms up the device.

Browser compatibility. Some operations require modern browser APIs. Old browsers (IE11, Safari before 14, in-app webviews) may not support all features. Modern client-side tools just refuse to load on these — usually fine, occasionally a problem in corporate environments.

Initial load. The Wasm bundle and pdf.js together are 1–3MB of JavaScript. That's a one-time cost (cached after the first visit), but the first load is slower than a thin server-side tool's HTML page.

Genuinely complex documents. Encrypted PDFs with weird DRM, very old PDF/A archival files, ones with embedded JavaScript that interacts with form data — these still trip up client-side libraries more than mature server-side ones. For most real PDFs, it doesn't matter. For some workflows, it does.

How to tell if a "free PDF tool" is actually client-side

Before you upload anything sensitive, do one of these checks:

1. Disconnect from the internet and try to use it. Real client-side tools work offline (after the page has loaded once). Server-side tools fail with a network error.

2. Open browser dev tools, go to the Network tab, and watch what happens when you submit a file. A client-side tool shows zero meaningful network traffic — maybe an analytics ping, no file upload. A server-side tool shows a several-megabyte POST.

3. Read the privacy policy. Server-side tools have to mention file storage, retention, and processing. Client-side tools tend to say "your files never leave your device" and can — that claim is verifiable, not marketing fluff.

4. Check for HTTPS only, no fancy infrastructure. Client-side tools are usually static-hosted (Vercel, Netlify, Cloudflare Pages). The whole site is HTML + JS + Wasm, no backend.

What's possible client-side now

To give a sense of the current state — these are all things modern browsers handle locally without uploading:

Merge, split, and reorder pages
Compress to a target file size (handy for email attachment limits)
Convert PDF to Word or images
OCR scanned PDFs into searchable text
Sign PDFs with a drawn or typed signature
Unlock password-protected PDFs (when you know the password)
Image conversions: HEIC → JPG, WebP → PNG, etc.

pdftools.renderlog.in is one example built this way — everything client-side, no server-side processing of user files, works offline after the first load. It's the kind of tool that would have been impossible in 2015, viable but slow in 2020, and is just normal now.

TL;DR

Server-side PDF tools were a workaround for slow JavaScript that's no longer needed.
Modern browsers + pdf.js + WebAssembly handle 95% of real PDF tasks locally, often faster than upload-process-download workflows.
The privacy implications are real: files you process locally don't end up on someone else's servers.
Cost economics flip from per-user pricing to free static hosting, which removes the pressure to monetize through ads or data.
Trade-offs: file-size limits, CPU intensity on mobile, slightly larger initial bundle.
To tell if a "free" PDF tool is actually client-side: try it offline, watch the Network tab, read the privacy policy.

The next time a PDF tool asks for your file, ask where it's going. With the current state of web tech, the answer should be "nowhere." Anything else is a choice the tool builder made — usually for reasons that don't benefit you.

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)
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)

A Developer's Guide to Image Formats: JPG, PNG, WebP, AVIF, and HEIC

Ashish Kumar — Sat, 25 Apr 2026 13:48:04 +0000

You're checking in 200 product photos. Should they be JPG? PNG? WebP? AVIF? Whatever the designer dragged in?

This is the question every developer ducks until performance reviews force the conversation. The honest answer is "it depends" — but the dependencies are concrete and learnable, and once you know them you stop wasting bandwidth on the wrong format.

This is a practical guide to the five formats you'll actually touch (JPG, PNG, WebP, AVIF, HEIC), plus a quick note on SVG and GIF. File sizes, when each wins, browser support, the conversion gotchas.

The decision tree

Before the deep dive, here's the rough mental model:

You have...	Use...
A photograph (smooth gradients, lots of color)	JPG, or WebP/AVIF if you can serve them
A screenshot, diagram, logo, or any image with hard edges	PNG, or WebP/AVIF
Something that needs transparency	PNG, or WebP/AVIF
An image that needs to scale to any size (icons, logos)	SVG
A short looping animation	WebP, MP4, or GIF as last resort
A photo from an iPhone	HEIC arriving, JPG/WebP serving

That table covers 90% of cases. The other 10% is in the details.

JPG (JPEG) — the workhorse

Released 1992. Lossy compression tuned for photographs. Discards information humans don't notice — fine color variation in skies, tiny details in busy areas — and keeps file sizes small.

Strengths: universal support, excellent compression for photos, predictable behavior.

Weaknesses: lossy (re-saving degrades quality), no transparency, terrible for text and hard edges (compression artifacts make text look fuzzy).

Practical compression: for photos served on the web, quality 75–85 is the sweet spot. Below 70 starts looking obviously compressed; above 90 wastes bytes for invisible quality. Most image tools default to quality 90 — too high.

Gotcha: don't open a JPG, edit it, and re-save it as JPG repeatedly. Each save is another lossy compression pass; after five or six rounds the photo looks visibly degraded. If you're going to edit, save as PNG or TIFF mid-flow, then export to JPG once at the end.

PNG — the lossless backbone

Released 1996. Lossless compression, supports transparency, supports indexed color (palette-based) for tiny file sizes on simple graphics.

Strengths: transparency, lossless (can re-save infinitely), great for screenshots and graphics.

Weaknesses: much larger than JPG for photos. A 1MB photo as JPG might be 4MB as PNG.

The two PNG modes:

PNG-24: 16 million colors plus alpha transparency. What most tools save by default. Best for photos and complex graphics.
PNG-8: 256-color palette plus optional 1-bit transparency. What every old icon and screenshot used. Tiny file sizes for simple images.

If you've got a logo with three colors on it, PNG-8 is often 10× smaller than PNG-24 with no visible difference. Most modern tools auto-pick or let you choose; older ones default to PNG-24 and waste space.

When to use PNG over WebP/AVIF: when you need maximum compatibility (very old browsers, email clients, system-level previews on outdated OSes) or when you need lossless preservation for further editing.

WebP — Google's modern compromise

Released 2010, mainstream-ready by 2018. Both lossy and lossless modes, supports transparency, supports animation. Compresses 25–35% smaller than JPG at equivalent quality, 26% smaller than PNG losslessly.

Strengths: smaller files than JPG/PNG with comparable quality, transparency, animation, supported in every modern browser.

Weaknesses: the encoder is slower than JPG. Not supported in some legacy email clients or very old browsers (IE11, but we don't care). Some image-editing tools still don't open WebP natively.

Browser support: universal in modern browsers as of 2020. Safari was last to adopt it (Safari 14, 2020). If you can require Safari 14+, you can serve WebP unconditionally.

Practical note: WebP wins biggest on photos that have lots of smooth gradients. On hard-edged graphics (UI screenshots, line art) the savings over PNG are smaller — sometimes WebP is even larger. Test both before assuming WebP is smaller.

AVIF — the newest, smallest, slowest to encode

Based on the AV1 video codec. Released 2019, broadly supported by 2023. Compresses 30–50% smaller than JPG at similar quality, often 20% smaller than WebP.

Strengths: the smallest file size of any common format. Supports transparency, HDR, and wide color gamuts.

Weaknesses: slow to encode (5–10× slower than JPG), some image tools and CDNs still don't support it, decoding on low-end devices can be slow.

Browser support: Chrome 85+, Firefox 93+, Safari 16.1+. As of 2026, support is broad enough to ship — but always serve a JPG/WebP fallback for the long tail.

When to use: when you have build-time image optimization, you're shipping a lot of photos, and bandwidth or LCP scores matter. For one-off images uploaded by users at runtime, the encoding cost may not be worth it.

HEIC — the iPhone format your build pipeline doesn't speak

HEIC (High-Efficiency Image Container) is what iPhones save photos as by default since iOS 11 (2017). Compresses about 50% smaller than JPG at equivalent quality. Apple ecosystem treats it as native; everything else treats it as a problem.

Strengths: dramatic file-size savings, supports HDR, transparency, and burst sequences.

Weaknesses: patent-encumbered, no native browser support (Safari supports it system-wide but not in <img> tags), most non-Apple tools can't open it.

The practical issue: users upload HEICs to your web app from iPhones, and your backend can't process them. They show up as broken images, fail to thumbnail, error out in image-processing pipelines.

Solutions:

Server-side conversion to JPG or WebP on upload. Libraries like heif-convert or sharp (with libheif) handle this.
Client-side conversion before upload, using a HEIC-to-JPG tool. There's a browser-based HEIC to JPG converter at imagetools.renderlog.in if you want to test what your users are uploading. It runs entirely in the browser, so the photo never leaves the device.
Configure iPhone to save as JPG. Settings → Camera → Formats → Most Compatible. Most users don't know this exists.

SVG and GIF — quick mentions

SVG (Scalable Vector Graphics). Vector format, scales infinitely, tiny file sizes for icons and logos. Use for: icons, logos, simple illustrations. Don't use for: photographs (impossible) or anything with realistic shading.

GIF. Released 1987. Use for: nothing, ideally. Supports animation but at terrible compression — a 5-second GIF is often 10× larger than the same content as an MP4 or WebP. The only legitimate modern use is as a fallback for environments that don't support video tags.

Serving multiple formats

The browser-friendly way to serve modern formats with fallbacks is the <picture> element:

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img src="hero.jpg" alt="Hero image" width="1200" height="600">
</picture>

Browsers pick the first format they support. If all three are present, modern browsers get AVIF, slightly older ones get WebP, anything else falls back to JPG.

The build pipeline to generate all three is straightforward with tools like sharp, squoosh, or vite-imagetools. If you're not generating multiple formats automatically, you're leaving 20–40% of bandwidth on the floor.

Common conversions and where they bite

A few real-world conversion paths and what to watch for:

JPG → WebP: safe and lossless if you keep quality high; verify color space (some tools accidentally drop sRGB profiles).
PNG → JPG: loses transparency. Anything that was transparent becomes opaque white (or black, depending on the tool).
HEIC → JPG: lossy; once converted, you can't get the HEIC quality back.
WebP → PNG: lossless if the source was lossless WebP; lossy WebP converted to PNG looks fine but doesn't recover detail.
AVIF → anything: generally works, but very high-quality AVIF can produce huge PNGs.

If you're doing one-off conversions while building, imagetools.renderlog.in has dedicated converters for the common pairs — WebP to JPG, HEIC to JPG, JPG to WebP, PNG to WebP, and an image compressor for size targets. All client-side.

TL;DR

Format	When to use	Notes
JPG	Photos, broad compatibility	Quality 75–85 sweet spot; don't re-save repeatedly
PNG	Screenshots, transparency, graphics	PNG-8 for simple images is often 10× smaller
WebP	Modern web replacement for JPG/PNG	25–35% smaller, universal support since 2020
AVIF	Photos with build-time optimization	Smallest, slowest to encode, ship with fallback
HEIC	Receiving from iPhones	Convert to JPG/WebP on upload
SVG	Vector graphics	Icons, logos, never photos
GIF	Legacy fallback only	Use WebP or video instead

Set your build pipeline to generate AVIF + WebP + JPG, serve them through <picture>, and forget about format until the next refactor. Your users save bandwidth, you save Core Web Vitals points, everyone wins.

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)
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)

Building Slugs That Don't Break: Unicode, Diacritics, and Edge Cases

Ashish Kumar — Sat, 25 Apr 2026 13:47:22 +0000

You ship a blog. The first international post is titled "Café au Lait — A Morning Routine." Your slug generator turns that into /caf-au-lait--a-morning-routine. The double hyphen is ugly, the dropped accent is worse, and that's just the start of what naive slug generation gets wrong.

This is one of those problems that looks like it deserves five lines of regex and ends up needing four hours and a battle-tested library. Let's walk through what actually goes wrong, why, and the rules a slug generator should follow.

What a slug needs to be

A slug is the human-readable part of a URL: in /blog/why-rust-matters, the slug is why-rust-matters. Good slugs have four properties:

URL-safe — contains only characters that don't need percent-encoding in a URL path
Readable — a human can guess what the page is about from the slug alone
Stable — the same input produces the same slug, forever
Unique — within whatever scope (your blog, your products) two pieces of content don't collide

The naive approach trips on every single one of these.

The five-line slug generator and why it's broken

Most engineers, including me, the first time, write something like this:

function slugify(input) {
  return input
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')
    .replace(/^-|-$/g, '')
}

It works on "Hello World" → "hello-world". It also produces these:

"Café au Lait" → "caf-au-lait" (lost the accent, ugly)
"100% Pure" → "100-pure" (dropped the meaning)
"C++ Programming" → "c-programming" (lost the distinguishing feature)
"日本語入門" → "" (empty string — the entire title is gone)
"Hello World" → "hello---world" (multiple spaces become multiple hyphens)
"Hello-World" → "hello-world" (collides with the natural slug)

And these are just the easy cases.

Step 1: Unicode normalization

The first thing a real slug generator does is normalize Unicode. The character é can be represented two ways:

NFC (composed): one code point, U+00E9
NFD (decomposed): two code points, e (U+0065) followed by ◌́ (U+0301, combining acute accent)

These look identical on screen but have different byte sequences. If your slug code only handles one form, the other slips through unchanged.

The fix is simple — normalize first, strip the diacritics second:

function stripDiacritics(input) {
  return input.normalize('NFD').replace(/[\u0300-\u036f]/g, '')
}

stripDiacritics("Café au Lait")  // → "Cafe au Lait"
stripDiacritics("naïve")          // → "naive"
stripDiacritics("Renée")          // → "Renee"

The \u0300-\u036f range covers the combining marks block — once é is decomposed into e + combining accent, the regex strips just the accent.

This handles most European languages but not all of them. German ß doesn't decompose; it should be transliterated to ss. Polish ł doesn't decompose either. For broad European coverage you need a transliteration map, not just NFD normalization.

Step 2: Transliteration vs dropping

For non-Latin scripts (Chinese, Japanese, Arabic, Hindi, Cyrillic), you have a real decision to make:

Option A: Transliterate. 日本語 becomes nihongo. The slug is readable to a Latin-alphabet reader, but transliteration is lossy and language-specific (東京 → tokyo requires knowing it's Japanese, not Chinese, where it'd be dongjing).

Option B: Pass through. Modern URLs support Unicode. /日本語 is a valid URL, browsers display it correctly, and search engines index it. The slug becomes meaningful to readers of that language.

Option C: Generate from a separate field. Many blogs let authors set a slug manually for non-Latin titles. The slug is whatever the author types, the title is whatever they meant.

There's no universally right answer. WordPress transliterates by default. Ghost passes through. Most documentation systems use option C. Pick based on your audience.

Step 3: Punctuation that means something

100% off shouldn't become 100-off. The % carries information. Battle-tested slug libraries have a symbol map that converts meaningful punctuation into words:

const symbolMap = {
  '&': 'and',
  '%': 'percent',
  '@': 'at',
  '+': 'plus',
  '$': 'dollar',
  '€': 'euro',
  '£': 'pound',
  '#': 'hash',
}

This is opinionated — 100% off → 100-percent-off is more readable than 100-off, but plenty of teams just drop the symbol. Decide once, document it.

For programming languages and tech terms specifically: C++ → cpp, C# → csharp, .NET → dotnet. These are conventions, not deductions; a generic slug library won't get them right unless you tell it to.

Step 4: The collision problem

You publish "Hello World." The slug is hello-world. Six months later, you publish another "Hello World" — maybe a follow-up, maybe a different topic that happens to share a title. What's the second slug?

Common patterns:

Numeric suffix: hello-world, hello-world-2, hello-world-3
Date suffix: hello-world-2026-04
ID suffix: hello-world-a3f9

The numeric suffix is the most common and almost always wrong. It encourages people to delete and republish to "get the clean URL", which breaks every link to the original. Date suffixes are the most stable. ID suffixes look ugly but never collide.

Whatever you pick, never silently overwrite an existing slug. Either reject the new content with an error, or generate a unique variant. Slugs that change break every backlink, RSS feed, social share, and search index.

Step 5: Reserved words

If your slug generator ever produces admin, api, login, logout, settings, signup, register, or dashboard, you've got a problem. Either:

The slug now masks an actual route (/blog/admin works fine, but /admin doesn't)
Or, worse, the route works and a user can SEO-impersonate your admin page

Real slug libraries maintain a reserved-words list. Yours should too:

const RESERVED = new Set([
  'admin', 'api', 'app', 'auth', 'dashboard', 'login', 'logout',
  'register', 'settings', 'signup', 'help', 'support', 'about',
  // ...add anything specific to your app
])

if (RESERVED.has(slug)) slug = `${slug}-post`  // or reject

Step 6: Length limits

There's no formal URL length limit, but practical ones exist:

Most CDNs and proxies cap at 2KB for the full URL.
Email clients truncate links over 80 characters in plain-text emails.
Search engines display only the first ~60 characters of a slug in results.

Cap slugs at 60–80 characters, truncated at a word boundary:

function truncate(slug, max = 60) {
  if (slug.length <= max) return slug
  const cut = slug.lastIndexOf('-', max)
  return slug.slice(0, cut > 0 ? cut : max)
}

The lastIndexOf('-', max) ensures we cut at a hyphen, not mid-word.

Putting it all together

A real slug function looks like this:

function slugify(input, { maxLength = 60 } = {}) {
  return input
    .normalize('NFKD')
    .replace(/[\u0300-\u036f]/g, '')        // strip diacritics
    .replace(/[&]/g, ' and ')                // expand symbols
    .replace(/[%]/g, ' percent ')
    .toLowerCase()
    .replace(/[^a-z0-9]+/g, '-')             // non-alphanumeric → hyphen
    .replace(/^-+|-+$/g, '')                 // trim hyphens
    .slice(0, maxLength)
    .replace(/-+$/, '')                      // re-trim after slice
}

That's the floor. From there you'd add the reserved-words check, the collision handler, and (for non-Latin support) either transliteration or pass-through Unicode handling.

Use a library — but know what it does

For production use, don't write this yourself. Battle-tested options:

slugify (npm) — handles transliteration for major European languages, fast, good defaults.
@sindresorhus/slugify — more aggressive transliteration, more configuration knobs.
github-slugger — what GitHub uses for anchor links in READMEs. Predictable, simple.
speakingurl — the most thorough, supports the most languages, also the most overhead.

For a one-off — generating a slug while drafting, testing edge cases, or comparing two slug strategies — paste the title into a browser-based slug generator and see what falls out. It runs locally, so internal product names and unreleased post titles don't end up on a third-party server.

TL;DR

The five-line slug regex breaks on Unicode, symbols, collisions, and reserved words.
Normalize Unicode (NFD), strip combining marks, decide between transliterate vs pass-through for non-Latin scripts.
Map meaningful symbols (% → percent, & → and) — don't silently drop them.
Maintain a reserved-words list. Cap slugs at 60–80 chars, cut on word boundaries.
Never silently overwrite a slug; suffix or reject. Backlinks break forever otherwise.
For everything beyond a one-off, use a library — slugify or @sindresorhus/slugify.

Slug generation is one of those problems that's easy to get 80% right and hard to get the last 20%. Worth doing properly once, then forgetting about.

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)
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)

Building Offline-First Web Apps with localStorage: A Practical Guide

Ashish Kumar — Sat, 25 Apr 2026 13:46:32 +0000

You're building a tiny tool. Maybe a notepad. Maybe a settings panel. Maybe a draft autosave for a form. You don't want a database. You don't want a backend. You don't even want a login.

localStorage.setItem(key, value) solves the problem in one line and you go home. Until your tool grows up, the data outgrows 5MB, three browser tabs trip over each other, the user clears their cookies, and suddenly you have a support ticket that boils down to "I lost my work."

This is the localStorage post I wish I'd had three years ago. When it's the right tool, when it isn't, and the specific footguns that make production-grade local persistence harder than it looks.

What localStorage actually is

localStorage is a synchronous key-value store, scoped to an origin (protocol + domain + port), persisted to disk by the browser. Both keys and values are strings. That's the whole interface:

localStorage.setItem('username', 'jane')
const value = localStorage.getItem('username')  // 'jane'
localStorage.removeItem('username')
localStorage.clear()

It's been in every browser since 2009. It has no expiration, survives reboots, and is shared across all tabs of the same origin. It's also the most misunderstood persistence API on the web.

When localStorage is actually the right tool

It's right for:

User preferences — theme, language, layout choices, "I dismissed this banner."
Draft state — a form you want to autosave, a half-written note, an unsaved edit.
Auth-adjacent data — user ID, role, last-known username (NOT auth tokens; we'll come back to that).
Small caches — a list of recent searches, a sidebar's collapsed/expanded state.
Feature flags that the user controls — "I opted into the beta UI."

The pattern: small, simple, doesn't need querying, fits in tens of KB, and losing it is annoying but not catastrophic.

It's wrong for:

Large datasets — anything past 1–2 MB starts to pinch
Structured data you need to query — localStorage is dumb storage; no indexes, no transactions
Anything sensitive — accessible by any JS on the page (XSS = full data theft)
Data shared across origins — localStorage is origin-scoped
High-write-frequency state — synchronous writes block the main thread

The footguns

Most production localStorage bugs come from one of these.

1. Everything is a string

setItem stringifies whatever you pass it, but not in a clever way. Numbers become strings. Booleans become strings. Objects become "[object Object]".

localStorage.setItem('count', 5)
localStorage.getItem('count')  // '5' — string, not number

localStorage.setItem('enabled', true)
localStorage.getItem('enabled')  // 'true' — string

localStorage.setItem('config', { dark: true })
localStorage.getItem('config')  // '[object Object]' — useless

Always JSON.stringify and JSON.parse for non-string data:

localStorage.setItem('config', JSON.stringify({ dark: true }))
const config = JSON.parse(localStorage.getItem('config'))

The wrap functions:

function setJSON(key, value) {
  localStorage.setItem(key, JSON.stringify(value))
}

function getJSON(key, fallback = null) {
  const raw = localStorage.getItem(key)
  if (raw === null) return fallback
  try { return JSON.parse(raw) } catch { return fallback }
}

The try/catch is not optional. If the user (or a previous bug) wrote bad JSON, JSON.parse throws, your app breaks on load, and now you can't even fix it through normal flows because the broken data is the first thing you read.

2. The 5MB limit (which isn't really 5MB)

The spec says "the user agent should limit the total amount of space allowed for storage areas." Most browsers settled on 5MB per origin, but it's not enforced uniformly:

Chrome: ~5MB per origin
Firefox: 5MB per origin, configurable
Safari: ~5MB; sometimes silently caps at less
Mobile Safari in private mode: 0 (writes throw QuotaExceededError)

The 5MB is total — keys + values + a small overhead. Strings are stored as UTF-16, so each character is 2 bytes; a "5MB" budget is really 2.5 million characters.

When you exceed the limit, setItem throws a DOMException. You need to catch it:

try {
  localStorage.setItem(key, bigValue)
} catch (e) {
  if (e.name === 'QuotaExceededError') {
    // Make space, or warn the user, or fall back to IndexedDB
  } else {
    throw e
  }
}

If you're storing user-generated content, this happens in production eventually. Plan for it.

3. The synchronous API blocks the main thread

Every setItem call writes to disk synchronously. For small values, this is microseconds. For large values, especially on mobile, it can be tens of milliseconds — long enough to drop a frame.

If your app is autosaving every keystroke and saving 100KB of state each time, you've got a stutter problem. The fix: debounce.

let saveTimer = null
function scheduleSave(state) {
  clearTimeout(saveTimer)
  saveTimer = setTimeout(() => {
    setJSON('app-state', state)
  }, 500)
}

For genuinely large state, this still won't be enough. That's the IndexedDB threshold.

4. Cross-tab synchronization

Two tabs of your app are open. The user changes a setting in tab A. Tab B doesn't know — it's still showing the old value.

The fix is the storage event:

window.addEventListener('storage', (e) => {
  if (e.key === 'theme') {
    applyTheme(e.newValue)
  }
})

The catch: the storage event only fires in other tabs, not the one that did the write. So the writer needs to update its own UI separately, and the listeners pick up changes from elsewhere. This is correct behavior but easy to mishandle.

5. Versioning your stored data

You ship v1 of your app. It writes user state shaped like:

{ "name": "Jane", "color": "blue" }

Six months later, you ship v2. The state shape is now:

{ "user": { "name": "Jane", "preferences": { "color": "blue" } } }

Existing users have v1 data sitting in localStorage. When v2 loads it, things break.

The fix: version your stored data and migrate.

const CURRENT_VERSION = 2

function loadState() {
  const raw = getJSON('app-state', null)
  if (!raw) return defaultState()

  if (raw.version === undefined || raw.version === 1) {
    return migrate1to2(raw)
  }
  if (raw.version === 2) return raw
  // Unknown future version — bail
  return defaultState()
}

Migration is a one-way door. Once you ship v2, you can't easily walk it back without losing data. So design migrations carefully and test them with real v1 data before deploying.

6. Don't store auth tokens here

This is its own essay, but quickly: any XSS vulnerability on your site lets an attacker do localStorage.getItem('auth-token') and steal it. Cookies marked httpOnly aren't accessible to JavaScript, which is what you want for credentials. Use cookies for auth; use localStorage for non-sensitive state.

If you're inheriting a codebase that puts JWT tokens in localStorage, plan to migrate. The migration isn't trivial (CSRF protection, cross-origin handling) but it's worth doing.

When to graduate to IndexedDB

The threshold is roughly:

Data above 5MB — localStorage will cap out
You need querying — finding records by anything other than primary key
Many writes per second — IndexedDB is async and won't block the main thread
Binary data — Blobs, Files, ArrayBuffers store natively in IndexedDB; localStorage forces base64 encoding (33% size overhead)

IndexedDB is more complex (the API is famously verbose), but libraries like idb-keyval give you a localStorage-like wrapper for the simple cases:

import { get, set } from 'idb-keyval'

await set('user-state', complexObject)
const state = await get('user-state')

That's IndexedDB with the same ergonomics as localStorage, but without the 5MB limit and without blocking.

A real case study: a private notepad

A small browser-based notepad — text editor, multiple tabs, autosave, no signup, fully local — is the kind of app that's a perfect localStorage fit until it isn't.

The version that works for 95% of users:

const STORAGE_KEY = 'notepad-tabs-v1'

function loadTabs() {
  return getJSON(STORAGE_KEY, [{ id: 'default', content: '' }])
}

function saveTabs(tabs) {
  setJSON(STORAGE_KEY, tabs)
}

// Debounce on every keystroke
const debouncedSave = debounce(saveTabs, 300)

This works perfectly until a user pastes a 4MB log file into one tab. Then setItem throws, the tab data fails to save, and on reload everything is back to the previous state. The user thinks they lost their work.

The graduation path: when total size approaches 1MB, migrate that tab's content to IndexedDB and store just a pointer in localStorage. Most users never trip the migration; the heavy users get a more capable backend automatically.

This is what notepad.renderlog.in does — small notes stay in localStorage for instant load, larger ones move to IndexedDB transparently, nothing ever leaves the browser. The whole thing is single-page, no signup, works offline after the first load, just a working text editor that respects the user's privacy. Useful as a reference if you're designing similar offline-first state.

TL;DR

localStorage is great for: preferences, drafts, small caches, non-sensitive flags. ~10–500KB of data.
Always JSON.stringify/JSON.parse non-string values; always try/catch the parse.
The 5MB limit is real and hits in production. Catch QuotaExceededError.
Synchronous writes block the main thread; debounce frequent saves.
Use the storage event for cross-tab sync.
Version your stored data from day one — migrations cost you nothing now and save you everything later.
Don't store auth tokens. Use httpOnly cookies.
Graduate to IndexedDB (via idb-keyval or similar) for >5MB, querying, or binary data.

localStorage is one of those APIs that looks too simple to think about and turns out to deserve about a day of design. Spend the day; you'll save the support tickets.

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)
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)

Forem: Ashish Kumar

Images, Fonts, Third-Party Scripts: LCP and CLS

Images and LCP: Why Your Hero Image Is Almost Always the Culprit

Image Formats: WebP vs AVIF: When to Use Each

srcset and sizes: How the Browser Picks the Right Image

CLS From Images: Width, Height, and the aspect-ratio Trick

The <picture> Element: Art Direction vs Format Selection

Font Loading and CLS: The FOUT/FOIT Trade-off

preconnect and preload for Fonts

System Font Stacks: The Right Answer More Often Than You Think

Subsetting Fonts: Removing Glyphs You Don't Need

Third-Party Scripts: How They Block the Main Thread

Deferring Third-Party Scripts

The Facade Pattern for Heavy Embeds

Putting It Together: A Pre-Launch Checklist

Tree Shaking and Code Splitting in JavaScript

What a bundle actually is

Bundle analysis: seeing what's actually in there

Tree shaking: how it works and why it fails silently

The sideEffects field

Common tree shaking failures

Barrel files

lodash

moment.js locale problem

Code splitting

React.lazy() and Suspense

Dynamic import() and chunk naming

Vendor splitting for cache utilization

The entry point waterfall

Measuring bundle impact in CI

.github/workflows/build.yml

The bundle optimization checklist

Web Workers in React: Heavy Work Off Main Thread

What Web Workers actually are

The structured clone algorithm: what can cross the boundary

CPU-bound vs I/O-bound: the right use cases

Worker lifecycle management

Comlink: making Workers feel like normal async functions

Vite/webpack integration

React integration: custom hook wrapping a Worker

Worker pools for parallelism

OffscreenCanvas: rendering off the main thread

SharedArrayBuffer and Atomics

Before/after: moving CSV parsing to a Worker

OPFS: The Browser's Built-in Filesystem Explained

The storage landscape problem

What OPFS actually is

The synchronous access handle why it matters

Worker + OPFS patterns

Streaming writes from the network

Real use case: caching a 200MB WASM binary

OPFS + SQLite: the surprising use case

Storage comparison table

Quota management

Browser support

Wrapping up

Network Optimization in React SPAs: Prefetching

The SPA network problem

HTTP cache headers: the foundation you're probably skipping

Stale-while-revalidate in JavaScript: React Query internals

Request deduplication

Avoiding request waterfalls in React

Prefetching strategies

Resource hints: preconnect, prefetch, preload

Priority Hints

Service Workers for network interception

Connection-aware fetching

What the network tab tells you

Putting it together

DOM Performance on Mobile: Lab vs Real Device Reality

The mobile hardware reality

Chrome DevTools CPU throttling isn't enough

DOM size and style recalculation cost

Mounting discipline: deferring below-fold components

content-visibility: auto

CSS contain property

Touch scroll performance

Scroll jank: the full picture

IntersectionObserver vs scroll events

Input latency: the 300ms tap delay

`srcset` and `sizes`: How the Browser Picks the Right Image

CLS From Images: Width, Height, and the `aspect-ratio` Trick

The `<picture>` Element: Art Direction vs Format Selection

`preconnect` and `preload` for Fonts

The `sideEffects` field

`content-visibility: auto`

CSS `contain` property