DEV Community: Yadhunandan S

How to catch the frozen tabs and jank your monitoring misses

Yadhunandan S — Sat, 12 Sep 2026 09:03:32 +0000

One user's page froze, and every dashboard stayed green. It was a long-lived single-page app, the kind of tab someone keeps open for hours. A customer writes in: yesterday the page locked up and they lost work. You open your monitoring to pull that exact session, and it is not there, because your replay tool sampled it away and it threw no error to catch on.

Modern error-monitoring and real user monitoring (RUM) tools are good: real Core Web Vitals in the field, session replay, per-session drill-down, and rage-click and dead-click detection all ship today. Three failures still fall through, though, and this post is how we caught them, with a per-session recorder built on tooling most teams already own.

TL;DR

The session behind a complaint is often missing: replay tools sample sessions for cost, and silent failures throw no error to trigger capture. Keep every session on infrastructure you own, and any complaint stays traceable.

Scroll jank and sustained drag stutter go uncaptured, because these tools detect frustration through clicks only. Each needs a small detector that samples the gesture with timestamps.

A permanent main-thread freeze can't be reported from the main thread that froze. Run the watchdog in a Web Worker so it survives and sends the report itself, from a snapshot handed over while the tab was healthy.

INP measures how responsive interactions feel, but misses dead and rage clicks, scroll jank, drags, and the merely-bad interaction. Per-session logs match how people actually complain.

Why isn't the session you need in your monitoring tool?
Why can't standard monitoring detect a frozen browser tab?
What is per-session real user monitoring?
Measuring what users feel with INP
What does INP not measure?
Small detectors for the four blind spots
The measurement trap we walked into first
How do you detect a frozen browser tab from a thread that isn't frozen?
Send the instant you know, do not batch
Run it on infrastructure you already own
Record for the machine, communicate for the human
What carries over

Why isn't the session you need in your monitoring tool?

The session you need is often missing because session replay tools sample sessions to control cost. They reliably capture a session only when a JavaScript error fires. The failures this post is about throw no error. Unless that exact session landed in the small sampled fraction, it was never recorded.

Replay is expensive to store, so tools keep only a portion of traffic dependably:

A sampled fraction of all sessions, often a small slice, say 10 percent (illustrative, not any vendor's exact default).
Sessions where an error is thrown.

That works for loud failures. A thrown exception flags the session, and you can open it later and watch it back.

The failures here are silent. A tab that slows over a long session, a scroll that stutters, a drag that lags, a main thread that freezes: none of them throw. With no exception for on-error capture to catch, the session is recorded only by luck, if it fell inside the sampled fraction. When a user complains about yesterday, their session is unlikely to be among the sampled few.

Replay length is usually capped too, often to a set window, sometimes around an hour (illustrative). Sensible for cost, awkward for a long-lived single-page app. A session that runs for hours can be truncated. The stretch you care about, the slow run-up before the freeze, can sit outside the recorded window even when the session was sampled.

So session replay can miss the very sessions you care about most. Sampling optimizes for a representative view of the fleet, not for guaranteeing that one arbitrary complaint is reproducible. The fix is not a cleverer sampling rule. It is full fidelity: keep every session. That is affordable only when you record onto infrastructure you already own, which we come back to later.

Why can't standard monitoring detect a frozen browser tab?

Standard monitoring cannot detect a frozen browser tab for two reasons. It aggregates individual sessions into percentiles that cannot be traced back to one user. And the monitoring script it runs inside your page sits on the same main thread that just froze. Both problems point at the same missing unit of measurement, the session.

Error monitors and APM tools are built around transactions: a page load, a route change, an API call. Each is a bounded event with a start and an end, and the tool rolls thousands into percentiles you read on a dashboard. That model fits a server, where a request arrives, does its work, and leaves. A long-lived browser tab fits it far less comfortably.

The failure our users described was a property of a session, not a transaction. "It got slow after a while, then froze" is a claim about how one tab behaved across its whole lifetime. The state that explains it, memory creeping up, a growing document, an interaction that quietly regressed, lives in the gaps between the transactions the tools recorded.

Percentiles make this worse, because a percentile cannot be traced back to a session. When your p75 interaction latency (the value three-quarters of interactions come in under) rises, there is no thread to pull back to the person who complained. You cannot ask a percentile which session it came from, or what the tab looked like right before it stalled.

The aggregate is lossy by construction. It throws away exactly the per-session detail you need to reproduce a slow-then-frozen tab.

The second reason is sharper, and it motivates the whole build. A freeze that never ends cannot be reported by code that runs on the frozen thread, because that monitoring script wedges with it. The watchdog section returns to why, and what to do.

What is per-session real user monitoring?

Per-session real user monitoring records the raw, ordered story of each browser session as its own log, tagged with a session id, instead of averaging interactions into percentiles. It matches the unit you record to the unit people complain in.

That is the single change of unit the rest of this post builds on. Keep the raw story of each session, and any complaint can be walked back to the events that produced it.

The trade is deliberate. Percentiles are cheap and answer questions about the fleet; per-session logs are heavier and answer questions about a person. For a failure that belongs to one long session and ends in a frozen tab, the per-session log is the only artifact that can reconstruct it, so that is the one we keep.

Measuring what users feel with INP

The main number worth recording is Interaction to Next Paint. INP is the time from a user action to the next frame that visibly reflects it, a good measure of how responsive an interface feels. Thanks to the web-vitals library, it now reads across Chrome, Firefox, and Safari rather than one engine. The canonical definition lives on web.dev.

That reach is recent. INP is built on the browser's Event Timing API, and the property it depends on, interactionId, was Chromium-only from Chrome 96 back in 2021. Firefox did not ship it until version 144, and Safari until 26.2, both in late 2025. Safari had no Event Timing API at all before 26.2.

Because that cross-browser support is so new, a real share of your Firefox and Safari sessions, the ones still on older versions, emit no INP whatsoever. They report the recorder's other signals fine. They just cannot produce INP. So measure what fraction of your sessions can actually report INP before you quote a number.

The attribution build

A bare INP number tells you something was slow, not what. That is what the library's attribution build is for. It breaks each interaction into the pieces that actually consumed the time: the input delay before your handler ran, the processing duration of the handler itself, and the presentation delay while the browser laid out and painted the result.

That is the difference between "an interaction took 600 milliseconds" and "a click on this control spent 500 milliseconds in processing" (both figures illustrative). One is a fact. The other is a place to start reading code.

The three phases each point at a different cause:

A large input delay means the main thread was busy elsewhere when the click landed, so the fix lives elsewhere in the session, not in the handler.
A large processing duration puts the cost in your own handler.
A large presentation delay means the browser spent its time in layout and paint.

Same slow interaction, three different files to open, and for a long session input delay is the telling one: it often signals a tab that has been accumulating work.

Reading it is a few lines. You import onINP from the attribution entry point and log the breakdown it hands back.

import { onINP } from 'web-vitals/attribution';

onINP((metric) => {
  const a = metric.attribution;
  // Where the time actually went, plus the element the user touched.
  console.log('INP', metric.value, 'ms on', a.interactionTarget);
  console.log('  input delay   ', a.inputDelay);
  console.log('  processing    ', a.processingDuration);
  console.log('  presentation  ', a.presentationDelay);
});

That is the teaching version, not production code, but it shows the shape of the signal: a value, a target, and three phases that say where the value came from.

What does INP not measure?

INP does not measure four real failures: dead and rage clicks where nothing repaints, scroll jank, sustained drags that stutter across many frames, and the merely-bad interaction dropped by worst-N sampling. INP is well defined, and these four fall outside its edges.

INP captures	INP does not capture
Clicks, taps, and key presses that produce a visible paint	Dead and rage clicks, where nothing repaints
How responsive those interactions feel	Scroll jank, which is continuous rather than discrete
Each interaction split into input delay, processing, and presentation	Sustained drags that stutter across many frames
The element the user touched	The merely-bad interaction dropped by worst-N sampling

Naming these four is not academic. Each is a gap you fill on purpose rather than a number that appears on its own. INP will never surface a dead click, so you watch the DOM for a non-response. It folds a stuttering drag into one clean entry, so you sample the gesture yourself. The list tells you where your monitoring is quiet.

Two of these four are worth separating honestly. Dead and rage clicks are already surfaced by mainstream tools through session replay. Building your own detector for them buys you ownership and full fidelity, not a capability you could not get otherwise. Scroll jank and sustained drag stutter are different. Those tools miss them too, because their frustration detection is click-based, so no off-the-shelf product is capturing them for you.

One INP interaction broken into input delay, processing, and presentation delay, beside the interaction types INP leaves out.

Small detectors for the four blind spots

Each blind spot gets its own small detector, cheap and specific to the failure it watches for, running alongside INP. The freeze from the opening needs a fifth detector, off the thread it watches, in its own section below.

Dead clicks and rage clicks

A dead click is the most literal version of "I clicked and nothing happened": the click lands, nothing repaints, and INP produces no entry at all. We catch it with a MutationObserver scoped to the subtree of the clicked element. Register the click, watch that subtree for a beat, and if nothing in the DOM changed, record a dead click.

// Dead click detector: did the click change anything in its own subtree?
const WATCH_MS = 300; // illustrative watch window, not a tuned constant

function watchForDeadClick(target, sessionId) {
  let changed = false;
  const observer = new MutationObserver(() => { changed = true; });
  observer.observe(target, { subtree: true, childList: true, attributes: true });

  setTimeout(() => {
    observer.disconnect();
    // document.contains guards a navigation away that removed the element.
    if (!changed && document.contains(target)) {
      recordDeadClick({ sessionId, at: Date.now() });
    }
  }, WATCH_MS);
}

document.addEventListener('click', (event) => {
  watchForDeadClick(event.target, currentSessionId);
});

Three legitimate responses must not read as dead clicks:

A canvas repaint changes pixels without changing the DOM, so exclude those regions or watch them differently.
A navigation away removes the element, which the document.contains(target) guard handles.
A slow-but-real update can land after the watch window closes, so keep the window generous.

Several fast clicks in the same dead spot are a rage click, so count repeats in one place.

Scroll jank and sustained drags

Scrolling is continuous rather than a discrete interaction, so INP excludes it by design, and a heavy list can scroll badly while scoring nothing. A sustained drag is the same problem in reverse: one gesture spread across many frames. One that stutters the whole way across the screen can still leave a clean INP record behind it.

We measure both the same way, with bounded bursts of sampling scoped to a real gesture, taking timestamps only. Why timestamps only, and never a layout read in that loop, is a mistake we made first and describe in the next section.

The merely-bad click lost to worst-N sampling

The last blind spot is one we created ourselves. If the recorder keeps only a session's few worst interactions (worst-N sampling), it will usually miss the specific click a user is complaining about, which was merely bad rather than record-breaking. So we keep all of a session's interactions, not the worst N. The whole purpose of the recorder is to be walked back to one person, and you cannot do that with the exact interaction they noticed thrown away.

The measurement trap we walked into first

Our first attempt at measuring scroll smoothness was the obvious one, and it was wrong in a way worth remembering. We ran a requestAnimationFrame loop that read layout each frame to see how much the content had moved. Reading a layout property forces the browser to synchronously recompute layout. Doing that every frame injected work into the exact path we were trying to observe.

The monitor manufactured the jank it reported, worst in the heavy, already-slow parts of the app, precisely where an honest reading mattered most.

The fix was two changes:

We take timestamps only in the hot path and never read layout there.
We replaced the forever-running loop with bounded bursts scoped to a real gesture, measuring an actual scroll for a short window instead of paying a per-frame cost forever.

// Fixed scroll sampling: timestamps only, bounded to a real gesture. No layout reads here.
let frames = [];
let scrolling = false;

function sampleScroll() {
  frames.push(performance.now()); // cheap: no layout property is read
  if (scrolling) requestAnimationFrame(sampleScroll);
}

function onScrollStart() {
  frames = [];
  scrolling = true;
  requestAnimationFrame(sampleScroll);
}

function onScrollEnd() {
  scrolling = false;
  // Turn frame timestamps into gaps off the hot path; long gaps are dropped frames.
  const gaps = frames.slice(1).map((t, i) => t - frames[i]);
  recordScrollJank({ sessionId: currentSessionId, gaps });
}

The durable lesson is short: a measurement that perturbs what it measures is close to worthless.

How do you detect a frozen browser tab from a thread that isn't frozen?

You detect a frozen browser tab by moving the detector off the main thread entirely, into a dedicated Web Worker that runs on its own event loop and keeps ticking while the main thread is wedged. Everything above measures degrees of slow. A freeze is different in kind: the main thread stops servicing work entirely and stays stopped. Any detector written the normal way runs on that same thread, so a setInterval meant to notice the freeze cannot fire during the freeze it exists to notice.

So we put the watchdog in a dedicated Web Worker, on its own thread. It keeps running when the main thread is stuck.

The heartbeat

The mechanism is a heartbeat. On a timer inside the worker, it posts a ping to the main thread and notes the time. The main thread has a tiny handler whose only job is to post an echo back. When the echo arrives, the worker compares the round trip against how long a healthy answer should take.

A late echo is the useful case. If the worker expected an answer within a frame or two and got one after, say, 1,800 milliseconds (illustrative, not a measurement from a real system), the main thread was blocked for roughly that long. The lateness of the echo is the measurement of blocked time. We get it this way on every browser, without the Chromium-only Long Tasks or Long Animation Frames APIs.

Here is the worker side: the heartbeat, the blocked-time reading, and the path that fires when the echo never comes.

// watchdog.worker.js runs on its own thread with its own event loop.
let identity = null;      // session id + context, handed over while the tab is healthy
let pingSentAt = 0;       // 0 means the last ping was answered
const PROMPT_MS = 16;     // a healthy echo returns within a frame or two
const FREEZE_MS = 5000;   // illustrative: no echo for ~5s means the tab is frozen

self.onmessage = (event) => {
  const msg = event.data;
  if (msg.type === 'identity') { identity = msg.snapshot; return; }
  if (msg.type === 'echo') {
    const roundTrip = Date.now() - pingSentAt;
    if (roundTrip > PROMPT_MS) report('blocked_time', { ms: roundTrip });
    pingSentAt = 0; // answered, healthy
  }
};

setInterval(() => {
  if (pingSentAt && Date.now() - pingSentAt > FREEZE_MS) {
    report('freeze', { silentFor: Date.now() - pingSentAt });
    pingSentAt = 0; // report once, then keep watching
    return;
  }
  if (!pingSentAt) {
    pingSentAt = Date.now();
    self.postMessage({ type: 'ping' });
  }
}, 1000);

function report(kind, data) {
  if (identity) navigator.sendBeacon('/rum', JSON.stringify({ kind, ...identity, ...data }));
}

On the main thread the handler stays trivial, because if answering the ping is expensive it defeats the point. The main thread also hands the worker an identity snapshot while it is still healthy: the session id and the context needed to attribute an incident later.

// On the main thread: create the worker, hand it an identity snapshot, echo its pings.
const watchdog = new Worker('/watchdog.worker.js');

// While we are still healthy, give the worker what it needs to report on its own.
watchdog.postMessage({
  type: 'identity',
  snapshot: { sessionId: currentSessionId, path: location.pathname, startedAt: Date.now() },
});

// The only job of this handler is to answer immediately. Keep it trivial.
watchdog.onmessage = (event) => {
  if (event.data.type === 'ping') {
    watchdog.postMessage({ type: 'echo' });
  }
};

When the echo never comes

The case that matters is when the echo never comes. If the worker hears nothing for several seconds (around 5 seconds is the illustrative threshold above), it concludes the tab is frozen. It does not wait for the main thread to recover, because it may never recover.

It sends the report itself, from its own thread, using the identity snapshot it was handed earlier. navigator.sendBeacon('/rum', ...) works inside a worker, so the freeze report goes out while the tab is still frozen, with no help from the thread that died.

This is the capability we could not get off the shelf, and the reason is structural. Mainstream error-monitoring and RUM tools run their code on the main thread, so a freeze that never ends is a report they can never send. Moving the watchdog off-thread is the whole difference between "the tab froze and we have nothing" and an incident report that arrives during the freeze.

The worker heartbeat, healthy on the left and failing on the right. Late replies measure blocked time; silence past a threshold triggers a freeze report the worker sends by itself.

Send the instant you know, do not batch

Send each slow interaction the moment it crosses the threshold, rather than buffering events and flushing on a timer, because of the order the bad things happen in. Buffering in memory and flushing periodically is the usual way to ship telemetry, and for most signals that is fine. For this recorder it is a liability.

The sequence is jank first, then freeze. The tab struggles, an interaction crosses into poor, and moments later the thread wedges. If those struggling-interaction events are sitting in an in-memory batch waiting for the next flush, the freeze takes the batch down with it. You lose the readings that describe the run-up to the very failure you are trying to explain.

So each slow interaction leaves the tab the moment it crosses the threshold, before the tab can lose it.

Run it on infrastructure you already own

You do not need a new vendor to build this. We already ran a self-hosted, open-source event analytics pipeline backed by a columnar database, the kind that is fast at counting and aggregating a single field across millions of rows. It was there for product analytics, good at swallowing a high volume of small, structured events and letting us slice them.

A performance signal is just another structured event. Every measurement the recorder takes is emitted as an event carrying its own session id, the surrounding context, and a pre-computed label describing how good or bad the number is. Because the classification already happened on the client, the dashboard needs no query engine and no statistics service, just a login and a bar chart. The adoption cost is close to zero: one more event type on a system that already exists, with nothing new to buy or install.

This is also what makes full fidelity affordable, which the opening scene needed. Because you own the event store, keeping 100 percent of sessions costs storage you already pay for, not a per-session premium. There is no sampling rate to tune and no on-error filter deciding which sessions survive. Every session is present.

Unlike a sampled commercial replay, the session behind any complaint, silent failure or not, is always there when you go looking. The customer writes in about yesterday, and this time the session is right where you expect it.

Cross-browser by default

One rule held the design together: the load-bearing signals have to work in every major browser. INP, blocked time from the worker heartbeat, action timing, and the DOM and memory gauges all do. The genuinely useful Chromium-only APIs, Long Animation Frames and precise memory measurement, are an enrichment layer, never the foundation. If your core diagnosis works in only one engine, you are blind to every user who complained from another.

Record for the machine, communicate for the human

Keep precise numbers for the engineer and pre-computed buckets for everyone else, both attached to the same event at record time. Internally the recorder keeps exact milliseconds. But when someone asks whether last quarter's work helped, milliseconds are the wrong language.

So every interaction is tagged at record time as good, needs-improvement, or poor, and the dashboard mostly counts those buckets. "Poor interactions fell from 14 percent of sessions to 3 percent" (illustrative, not a real system's data) is a sentence anyone can act on. "p75 improved by 300 milliseconds" (also illustrative) is not, even when it describes the same win. The buckets travel with the raw data rather than replacing it, so an engineer can still open one poor session and read it line by line.

What carries over

Three ideas outlast the browser specifics:

The first is the one the opening turns on: full fidelity beats sampling when you have to reproduce a specific complaint. A representative sample answers questions about the fleet, but the session one user is angry about is not a statistical question, and the only way to guarantee it is there is to keep all of them.
The second is the one the freeze build turns on: a detector that shares a thread with what it watches goes down with it, so the move that makes freezes observable at all is putting the watchdog somewhere the freeze cannot reach.
The third bit us hardest in practice: a measurement that perturbs what it measures buys you almost nothing, so keep the hot path to timestamps and push the expensive work onto another thread.

The rest is bookkeeping that matters: our users complain in sessions, so per-session logs beat transaction percentiles, and attaching the judgment to the fact at record time lets one event serve both the engineer reproducing a bug and the person deciding what to do next.

Custom React Router Prompt

Yadhunandan S — Sun, 13 Jun 2021 09:29:38 +0000

How to implement the custom prompt on navigation using react-router

What’s the need for custom prompt ?

Most of the react projects follow the UI design system for their components. In order to achieve the same design consistency across the app, they reuse the components. However to block the navigation in case there are some unsaved user data, default browser prompt is the most common and easy way to block the user from navigating to different routes. But the popup does not match your library component.

There is no official docs explicitly mentioning how to use the custom modal instead of the default react-router Prompt.

Solution

There are few simple steps to be followed in order to get the required result. Each step contains 100% working code snippets. You can use it in your projects.

Step 1

We need to disable or block the default browser prompt. This can be done by passing an empty callback to the getUserConfirmation function prop of the BrowserRouter.

Step 2

Now let’s create a custom RouterPrompt component using the useHistory hook from the react-router-dom and ant design component library for the Modal component.

Step 3

Let’s create two sample components for navigating between pages. For example, let the first component be Dashboard.jsx and the second component be Home.jsx.

The home component contains our custom RouterPrompt component. The prompt is triggered on the page change and also based on the when prop. The when prop is used to conditionally trigger the prompt. For instance, if the when prop is set to true , the prompt will be shown every time page navigates (from home route to other routes or navigate forward / back).

The onOK and onCancel callback props must return boolean value in order to proceed with the route.

Result

Conclusion

You can use any component library’s modal, even your own custom modal or default browser prompt. But just be careful when implementing the history.block.

By following the above steps you can achieve the desired solution. The code is 100% working. You can copy the code snippets to your applications to save time.

References

What is Output — Webpack 5

Yadhunandan S — Sun, 02 May 2021 15:27:20 +0000

Before continuing the article, please refer to the below link if you have missed the introduction to webpack 5

https://dev.to/yadhus/introduction-to-webpack-5-5fhm

https://dev.to/yadhus/what-is-entry-webpack-5-1cb5

What is Output

Output is a property that tells webpack where to emit / save the bundles it creates and how to name these bundled files. By default the main output file gets stored in ./dist/main.js and other generated files are stored in ./dist.

module.exports = {
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js
 }
}

Single or Multi-main entry points

Though the entry property can have one or multi paths, there can be only one output configuration specified.

Example:

module.exports = {
 mode: "development",
 entry: "./src/home.js"
}

Output:

dist /
 - main.js

Note:

The webpack’s default configuration for the output property looks something like this

module.exports = {
 mode: "development",
 entry: "./src/home.js"

 // default output configuration
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js
 }
}

The [name] resolves to the dynamic name of the bundle. Here it resolves to main.js.

If you want the default configuration, it is not required to mention the output property. Webpack understands and apply it implicitly.

Object entry points

While webpack can have multiple different entry points, only one output configuration can be specified.

Example:

module.exports = {
 mode: "development",
 entry: {
  adminApp: "./src/admin.js",
  homeApp: "./src/home.js"
 },

 // default output configuration 
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js
 }
}

Output:

dist /
 - adminApp.js
 - homeApp.js

Advanced

Apart from path and filename sub properties of the Output property. There are few other sub properties that are used often in the build process (like CRA etc.). Some of them are listed below.

PathInfo

module.exports = {
 mode: "development",
 entry: {
  adminApp: "./src/admin.js",
  homeApp: "./src/home.js"
 },
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js,

  pathInfo: true
 }
}

This tells webpack to include comments in bundles with information about the contained modules (filename comments). It also adds some info about tree shaking to the generated bundle.

ChunkFilename

module.exports = {
 mode: "development",
 entry: {
  adminApp: "./src/admin.js",
  homeApp: "./src/home.js"
 },
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js,

  pathInfo: true, 
  chunkFilename: [id].[contenthash:8].chunk.js
 }
}

contenthash:8 generates a dynamic hash value based on the contents of the files and the ‘:8’ represents the length of the hash value. If the contents of the files are not changed, then the same hash value is generated.

The chunkFilename determines the name of the non-initial chunk files (like lazy loaded or dynamically imported modules). These filenames need to be generated at runtime to send request for the chunks.

Because of this, placeholders like [name] and [contenthash] need to add a mapping from chunk id ([id]) to placeholder value ([name].[contenthash:8].chunk.js) to the output bundle with the webpack runtime. This increases the size and may invalidate the bundle when placeholder value for any chunk changes.

PublicPath

module.exports = {
 mode: "development",
 entry: {
  adminApp: "./src/admin.js",
  homeApp: "./src/home.js"
 },
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js,

  pathInfo: true, 
  chunkFilename: [id].[contenthash:8].chunk.js, 
  publicPath: 'https://server.com/assets/' 
 }
}

The publicPath is where you have uploaded the bundled files. This is an important option when using on-demand-loading or loading external resources like images, files, etc.

This option specifies the public URL of the output directory when referenced in a browser. A relative URL is resolved relative to the HTML page (or <base> tag). Server-relative URLs, protocol-relative URLs or absolute URLs are also possible and sometimes required, i.e. when hosting assets on a CDN.

In the above code snippet, the request to the chunk file will look something like this https://server.com/assets/1.a345ersd.chunk.js.

The webpack-dev-server also takes a hint from publicPath, using it to determine where to serve the output files from.

By default, the publicPath value is set to ‘/’.

GlobalObject

module.exports = {
 mode: "development",
 entry: {
  adminApp: "./src/admin.js",
  homeApp: "./src/home.js"
 },
 output: {
  path: path.resolve(__dirname, "dist"),
  filename: [name].js,

  pathInfo: true, 
  chunkFilename: [id].[contenthash:8].chunk.js, 
  publicPath: 'https://server.com/assets/',
  globalObject: 'this'
 }
}

When targeting a library, especially when libraryTarget is 'umd', this option indicates what global object will be used to mount the library.

To make UMD build available on both browsers and Node.js, set globalObject option to 'this'.

Defaults to self / window for Web-like targets.

The webpack configuration file specifically to highlight output property:

GitHub Repo Link

https://github.com/yadhus/What-is-Output-Webpack-5

References

https://webpack.js.org/configuration/output/
https://webpack.js.org/concepts/#output

What is Entry — Webpack 5

Yadhunandan S — Sat, 09 Jan 2021 19:38:24 +0000

Before continuing the article, please refer to the below link if you have missed the introduction to webpack 5

https://dev.to/yadhus/introduction-to-webpack-5-5fhm

What is entry

Entry is a property that indicates webpack which module(s) / file(s) it should use to begin building out the internal dependency graph(s) of the project / application.

Three syntax of entry

Single entry
Multi-main entry
Object entry

Single entry

The single entry syntax points to one file path to start building the dependency graph of the project / application. It is a great choice when you are looking to quickly setup a webpack configuration for an application or tool with one entry point (i.e. a library)

Usage

entry: String

module.exports = {
  entry: "./src/index.js"
}

Multi-main entry

The multi-main entry syntax points to multiple file paths. Its creates separate dependency graphs based on these paths and finally get combined or merged into a single file.

Usage

entry: [String]

module.exports = {
  entry: [
   "./src/index_1.js",
   "./src/index_2.js"
  ]
};

Object entry

The object entry syntax creates separate files for each key value pair in the entry object. It allows you to customize the chunk / bundled file name (key name). This is the most scalable way of defining entry / entries in your application.

This is a popular technique used to separate concerns by environment, build target, and runtime.

Usage

entry: { [entryChunkName] : String }

Usage

entry: { [entryChunkName] : [String] }

module.exports = {
  entry: {
   adminApp: "./src/admin.js",
   homeApp: ["./src/home_1.js", "./src/home_2.js"]
  }
};

The webpack configuration file specifically to highlight entry property:

Note

You can pass empty object to entry when you have only entry points generated by plugins (will see more about this in detail in the upcoming articles).

module.exports = {
  entry: {}
};

GitHub Repo Link

https://github.com/yadhus/What-is-Entry-Webpack-5

https://dev.to/yadhus/what-is-output-webpack-5-cho

References

https://webpack.js.org/guides/entry-advanced/
https://webpack.js.org/concepts/#entry
https://webpack.js.org/api/
https://webpack.js.org/configuration/

Introduction to Webpack 5

Yadhunandan S — Tue, 05 Jan 2021 07:05:01 +0000

What is webpack

Webpack is a static module bundler for modern JavaScript applications. When webpack processes the application, it internally builds a dependency graph which maps every module (like node_modules, images, CSS, etc.) your project needs and generates one or more bundles.

Module Bundler — A tool that takes JavaScript & its dependencies and bundles them into a single / multiple files (to use in browser).

Dependency Graph — A graph that maps all the dependencies between files based on the order / hierarchy in which it is used or referenced.

Webpack builds and loads modules synchronously. It converts dependencies into modules and pulls the dependencies and modules at the right time in the right scope. Finally, it loads all these modules and dependencies into one or few files and downloads it in the browser (when requested).

webpack requires a configuration file to bundle your project. Webpack, by default has a default configuration once you install it (using NPM). But webpack allows you to incredibly configure it based on your project needs and requirements.

The basic webpack configuration file looks something like this:

To understand the webpack configuration and to get started, First you need to know the core concepts of webpack:

Entry
Output
Loaders
Plugins
Mode

Mode

This parameter enables webpack to identify and add built-in optimizations for the corresponding environment. The default value for the mode parameter is ‘production’.

There are three modes:

production
development
none - does not add any default / built-in optimizations

module.exports = {
  mode: 'development'
}

Entry

An entry is a starting / initial point for webpack to start building out its internal dependency graph. Based on this webpack will figure out other modules, libraries and assets that the entry point depends on.

module.exports = {
  mode: 'development',
  entry: "./path/to/my/entry/file.js"
}

Output

The output property tells webpack where to save the bundles it creates and how to name the bundled files. This property only applies to JavaScript files not on other files like HTML, CSS etc.

module.exports = {
  mode: 'development',
  entry: "./path/to/my/entry/file.js",
  output: {
   path: path.resolve(__dirname, 'dist'),
   filename: [name].js,
 }
}

Loaders

Loaders are used to preprocess the files as you import or load them and allows you to bundle any other static resources (like .png, .img, .css, .sass, etc.).

Loaders are like tasks in other build tools and provide a powerful way to handle front-end build steps. It can transform files from a different language to JavaScript or load inline images as data URLs. It even allows you to directly import CSS files from your JavaScript modules.

module.exports = {
  mode: 'development',
  entry: "./path/to/my/entry/file.js",
  output: {
   path: path.resolve(__dirname, 'dist'),
   filename: [name].js,
 },
 module: {
  rules: [
   { test: /\.css$/, use: ['style-loader', 'css-loader'] },
  ],
 }
}

‘module’ — property is used to denote the loaders and its configuration.

‘rules’ — property is a list of objects that contain the different types of loaders. Each item (object) of the rules property contains ‘test’ and ‘use’.

‘test’ — property takes a regex and executes the specified loader for the file types that match.

‘use’ — property takes the loader type value that will be used for executing / transforming the specified file type(s).

In the above code snippet, the rules checks for the CSS file types and transforms it (to use in browser) using the css-loader and style-loader. The css-loader interprets the ‘@import’ and ‘url()’ and resolves them. The style-loader injects the CSS into the DOM. (takes the styles and creates a style tag in the HTML)

Plugins

Plugins provide a powerful way to tap / injects custom build into webpack’s compilation process. A plugin is able to hook into key events that are fired throughout each compilation.
Plugins are the backbone of the webpack. Webpack itself is built on the same plugin system that you use in your webpack configuration.

module.exports = {
  mode: 'development'
  entry: "./path/to/my/entry/file.js",
  output: {
   path: path.resolve(__dirname, 'dist'),
   filename: [name].js,
 },
 module: {
  rules: [
   { test: /\.css$/, use: ['style-loader', 'css-loader'] }
  ]
 },
 plugins: [
  new HtmlWebpackPlugin({
   template: "./src/index.html"
  })
 ]
}

‘plugins’ — property is a list of new instances of plugins. Each plugin instance takes arguments / options which you need to pass in the new instance.

In the above code snippet, plugins contain the HtmlWebpackPlugin instance which creates a new HTML file based on the template HTML file (./src/index.html) and puts it inside the output folder (./dist).

Difference between loaders and plugins

Loaders do pre-processing transformation of any file types that we specify. Loaders work at the individual level during or before the bundle is generated. Loaders are not able to influence the actual build process.

Plugins are executed after the end of the bundle generation process. Plugins can modify how bundles are created and have more control than loaders.

Why webpack

First and most important reason for using webpack is that it gives complete control over the frontend build process and helps to build boiler plates or ready-made app for developers to start coding using the major frameworks like React, Angular and Vue.

Using webpack loaders, we can use modern JavaScript syntax like arrow functions, spread operators, etc. which are then later transformed (during the bundle generation) into common JavaScript that are compatible with all the modern and old browsers.

In development mode, webpack also provides ‘Hot Module Replacement’ which updates the modules without fully reloading the entire page. This saves the development time by only updating what’s changed.

It is used to optimize and minimize the code, so that it loads and downloads the bundled files / chunks faster in the browser. All these process and transformations are executed in a single build process in a very short time.

There are many more features and advantages of webpack which I will cover in detail in the upcoming articles.

GitHub Repo Link

https://github.com/yadhus/Introduction-to-Webpack-5

https://dev.to/yadhus/what-is-entry-webpack-5-1cb5

References

https://webpack.js.org/concepts/
https://webpack.js.org/api/
https://webpack.js.org/configuration/
https://stackoverflow.com/questions/37452402/webpack-loaders-vs-plugins-whats-the-difference

DEV Community: Yadhunandan S

How to catch the frozen tabs and jank your monitoring misses

On this page

Why isn't the session you need in your monitoring tool?

Why can't standard monitoring detect a frozen browser tab?

What is per-session real user monitoring?

Measuring what users feel with INP

The attribution build

What does INP not measure?

Small detectors for the four blind spots

Dead clicks and rage clicks

Scroll jank and sustained drags

The merely-bad click lost to worst-N sampling

The measurement trap we walked into first

How do you detect a frozen browser tab from a thread that isn't frozen?

The heartbeat

When the echo never comes

Send the instant you know, do not batch

Run it on infrastructure you already own

Cross-browser by default

Record for the machine, communicate for the human

What carries over

Custom React Router Prompt

What’s the need for custom prompt ?

Solution

Step 1

Step 2

Step 3

Result

Conclusion

References

What is Output — Webpack 5

What is Output

Single or Multi-main entry points

Example:

Output:

Note:

Object entry points

Example:

Output:

Advanced

PathInfo

ChunkFilename

PublicPath

GlobalObject

The webpack configuration file specifically to highlight output property:

GitHub Repo Link

References

What is Entry — Webpack 5

What is entry

Three syntax of entry

Single entry

Usage

Multi-main entry

Usage

Object entry

Usage

Usage

The webpack configuration file specifically to highlight entry property:

Note

GitHub Repo Link

Next article

References

Introduction to Webpack 5

What is webpack

Mode

Entry

Output

Loaders

Plugins

Difference between loaders and plugins

Why webpack

GitHub Repo Link

Next article

References