DEV Community: Utkarsh Bansal

The 3-Second Rule of Web Performance — And How to Beat It

Utkarsh Bansal — Fri, 03 Jul 2026 14:06:00 +0000

Hello there 👋

So... I may have gone a little overboard with this one.

Last time we pulled apart how ESLint actually works.

This time, we're dismantling web performance.

Why? Because it's one of the highest-ROI frontend skills you can learn—and one of the few that can't simply be outsourced to a tool.

Fortunately, browsers already hand you the diagnosis.

By the end of this article, you'll know how to read it.

Could this have been a 10-part series?

Absolutely.

Did I make it one?

Nope.

Curious what that 10-part series would've looked like?
Here you go.

Core Web Vitals: LCP, INP, CLS
The Critical Rendering Path
JavaScript costs more than you think
CSS is not free either
Images
Fonts
The network
Framework patterns (React/Vue)
Perceived performance
Lighthouse and field data — measuring what matters
The performance budget
The checklist

Now, the choice is yours — complete it in one sitting, go section by section, or skip straight to the checklist. No judgment.

3 seconds.

That's all you have before visitors start leaving.

Sounds harsh? Reality is even harsher.

53% of mobile users abandon a site that takes longer than 3 seconds to load. — Google's 2016 research

But you don't need a study to believe it.

How many times have you closed a tab because it took just a little too long?

Your users do exactly the same thing.

What does that mean?

That portfolio you spent weeks perfecting.

That product page you pulled three all-nighters building.

People might never see it.

Not because it's bad. Because it was slow.

Google found that improving mobile load times by just 0.1 seconds increased retail conversions by 8.4%.

That's not a rounding error.
That's revenue.

And that's only half the story.

Google also uses Core Web Vitals as a search ranking signal.

That means poor performance doesn't just cost you users — it also costs you visibility.

Performance isn't just a UX metric. It's a business metric.

Fast Isn't a Feeling. It's Measurable.

Everyone says:

"Make the site faster."

But what does "fast" actually mean?
For the browser, this comes down to three questions:

Did the user see something? — Loading performance -> LCP
Did the page respond when I click? — Interaction performance -> INP
Did the layout stay stable? — Layout stability -> CLS

Google spent years figuring out how to measure what users actually experience.

The result? Core Web Vitals.
Before we go any further...
Let's measure this page together.

Open DevTools (Cmd+Option+I / Ctrl+Shift+I) -> Performance

Keep this tab open. We'll keep coming back to it throughout the article.

Chrome DevTools Performance panel — Live Metrics view (see your scores)

Chrome DevTools Performance panel — Record and Reload (see why)

Spend a minute exploring.
I'll wait.

Performance isn't something you memorize. It's something you experience.

These two views tell you what's slow, why it's slow, and which Core Web Vital is paying the price.
That's 90% of performance engineering.

LCP, INP, CLS — What They Actually Measure

Here's what my Live Metrics view showed:

LCP: 0.18s
CLS: 0.00
INP: 48ms

Let me explain what these mean.

LCP — Largest Contentful Paint

When does the user finally see the main content?

Not the spinner. Not the navigation.

The largest visible element in the viewport — because that's usually why they came.

Good       -> under 2.5 s
Needs work -> 2.5 s – 4 s
Poor       -> over 4 s

INP — Interaction to Next Paint

How quickly does the page react when someone clicks, taps, or types?

Not scrolling. Not hovering.

Good       -> under 200 ms
Needs work -> 200 ms – 500 ms
Poor       -> over 500 ms

Under 200ms, the interaction feels instant.

Past 500ms, people start wondering if the click even worked.

CLS — Cumulative Layout Shift

How much does the page unexpectedly move while someone is using it?

Ever clicked a button just as the page shifted?
You've experienced CLS.

If a late-loading banner affects 50% of the viewport and pushes content 20% of the viewport height:

0.5 (impact) × 0.2 (distance) = 0.1 shift score

Every unexpected layout shift adds to your CLS score.

Good       -> under 0.1
Needs work -> 0.1 – 0.25
Poor       -> over 0.25

All Three, In One Session

These metrics don't happen in isolation.

They happen on the same page. To the same user. Often within a few seconds.

Watch it play out:

  0ms    -> Browser sends request
 300ms   -> HTML received, parser starts building the DOM
 600ms   -> Browser discovers render-blocking CSS file.
            Parsing pauses.
            Nothing is painted.
            User sees a blank screen.
 900ms   -> CSS loads. Parsing resumes.
1200ms   -> Hero image starts downloading.
2400ms   -> Hero image finishes rendering.
            ↑ LCP
2600ms   -> User taps the menu.
2601ms   -> A 400ms JavaScript task is already running.
            Browser can't respond yet.
3000ms   -> JS finishes. The click is finally processed.
            ↑ INP
3100ms   -> Menu opens. User starts reading.
3300ms   -> Font finishes loading.
            Text shifts down.
3500ms   -> An ad appears.
            Content shifts again.
            User taps the wrong button.
            ↑ CLS

Three metrics.
One page load.
One user who had a genuinely terrible experience.

The Browser Has a Pipeline. Your Resources Keep Interrupting It.

In the last section we measured LCP, INP, and CLS.

Those metrics aren't random.

They all come from the same pipeline the browser uses to load a page.

Two rules govern that pipeline.

Rule #1 — No DOM + CSSOM, no paint.

HTML builds the DOM.
CSS builds the CSSOM.

The browser needs both before it can paint a single pixel.

No CSSOM.
No paint.
Just a blank screen.
That's the Critical Rendering Path.

Here's the whole pipeline, start to finish:

The thing is, you don't have to wait for the entire stylesheet before the first paint happens.

Only the CSS for what's visible right now actually matters.

Everything below the fold can wait.
That's critical CSS.

<!-- 🔴 Browser waits for the whole file before it can paint -->
<link rel="stylesheet" href="styles.css" />

<!-- 🟢 Critical styles inline. The rest loads without blocking. -->
<style>
  /* just enough CSS for what's visible right away */
  .hero { ... }
</style>
<link rel="stylesheet" href="styles.css" media="print" onload="this.media='all'" />

That media="print" part isn't really about printing.

It tricks the browser into treating the file as non-blocking.

Once it finishes loading, onload flips it back to media="all".

No network round-trip blocking your first paint.

One more thing: add a <noscript> fallback too, in case JavaScript is off.

<!-- Without JS, the onload above never fires, so this stylesheet would be -->
<!-- stuck on media="print" forever. The noscript version gives JS-less -->
<!-- browsers a normal, blocking stylesheet instead. -->
<noscript>
  <link rel="stylesheet" href="styles.css" />
</noscript>

Rule #2 — Without `defer` or `async`, the parser waits.

A <script> without defer or async is parser-blocking — though what that actually costs you depends on where the tag sits, as you'll see below.

The browser pauses HTML parsing, executes the script, then resumes where it left off.

Watch what happens when you load the same script three different ways.

Here's what it looks like in DevTools:

Those markers tell the story of the page load.

Marker	Full name	What it means	Time
FCP	First Contentful Paint	First visible content appears	167.66ms
DCL	DOMContentLoaded	HTML finished parsing	321.39ms
L	onLoad	Initial resources finished loading	697.21ms
LCP	Largest Contentful Paint	Largest visible element rendered	861.26ms

Notice something.
The browser isn't "done" once.
It's done in stages.

Timeline comparing script loading:

Same FCP. Very different LCP — often the difference between passing and failing.

Rule of thumb:

defer -> for app code.
async -> for independent scripts like analytics, ads, widgets, API calls, or anything that doesn't depend on the DOM.

One Exception That Trips Up Almost Everyone

async and defer only work on external scripts — inline scripts ignore both.

<!-- ✅ Works -->
<script src="app.js" defer></script>
<!-- ❌ defer ignored — no src -->
<script defer>
  document.getElementById('btn').addEventListener('click', doSomething)
</script>

Two good options if you must put an inline script in <head>.

Option 1 — Wait for the DOM.

<script>
  document.addEventListener('DOMContentLoaded', () => {
    document.getElementById('btn').addEventListener('click', doSomething)
  })
</script>

Think of it as the inline equivalent of putting your script at the end of <body>.

Option 2 — Use modules (deferred automatically):

<script type="module">
  document.getElementById('btn').addEventListener('click', doSomething)
</script>

Here's the full picture.

Script	Best placement	Why
External, no attribute	End of `</body>`	Works, but starts downloading late
External + `defer`	`<head>`	Best choice — parallel download, safe execution
External + `async`	`<head>`	Independent scripts only
Inline, no wrapper	End of `</body>`	`async` and `defer` are ignored
Inline + `DOMContentLoaded`	`<head>`	Waits for the DOM
Inline + `type="module"`	`<head>`	Deferred automatically

Then Why Does Everyone Still Teach "Put JavaScript at the Bottom"?

I wondered the same thing until I looked into the history — and found something interesting.

It was the right advice in 2007. It just never got updated.

Back then, defer existed, but browser support was unreliable.

Internet Explorer interpreted it differently.
Firefox had bugs.

Putting scripts at the end of </body> was the only reliable solution.

Later, Steve Souders' 2007 book High Performance Web Sites popularized the pattern. And the advice spread through books, tutorials, bootcamps, and never really changed.

Now, every modern browser implements defer consistently.

The workaround is no longer necessary.
Let's leave 2007 behind, shall we?

JavaScript Costs More Than You Think

Blocking paint is only half the story.
The other half is JavaScript.
It's more than just a download.

A 200KB image and a 200KB JavaScript file might be the same size.

They're nowhere near the same cost.

Image (200KB):      download -> decode -> done
JavaScript (200KB): download -> parse -> compile -> execute -> (blocks interactions)

Real-world cost? Up to 30% of a page's total load time can go purely into JavaScript execution.

Not because kilobytes are evil.

Because the browser has to process every byte before it can run.

Optimizing JavaScript boils down to two goals:

Ship less JavaScript.
Run what you ship without blocking the main thread.

Goal #1 — Ship Less JavaScript

The fastest code is the code users never download.

Code Splitting — Ship Only What the User Needs

Most apps ship one giant bundle.

Every route.
Every feature.
Every component.

Even though most users never touch most of it.
Code splitting fixes that.

// Static import — downloads immediately
import { initMap } from './map.js'
// Dynamic import — downloads only when needed
document.getElementById('show-map').addEventListener('click', async () => {
  const { initMap } = await import('./map.js')
  initMap(document.getElementById('map-container'))
})
// Route-based splitting
const routes = {
  '/dashboard': () => import('./pages/dashboard.js'),
  '/profile': () => import('./pages/profile.js'),
  '/settings': () => import('./pages/settings.js'),
}

The dashboard never downloads for the users who never open it.

That's not optimization.
It's simply not wasting bandwidth.
React, Vue, and Angular all build on the same idea.
Under the hood, they're just using dynamic import().
See it yourself.
Open DevTools -> Network -> JS on dev.to.

Fourteen JavaScript files.
None over 200KB.
Fourteen focused chunks beat one massive bundle.

Tree Shaking — Remove What You Don't Use

Install lodash. Use one function. The whole library ships anyway.

That's because lodash uses CommonJS — bundlers can't tree-shake it.

lodash-es is the same library, rewritten as ES modules.

Switch to lodash-es and use a named import:

// 🔴 Ships ALL of lodash (~72KB minified)
// CommonJS — bundlers can't tree-shake this
import _ from 'lodash'
const val = _.get(obj, 'a.b.c')
// 🟢 Ships ONLY get (~5KB minified)
// ES modules — bundler strips everything you never imported
import { get } from 'lodash-es'
const val = get(obj, 'a.b.c')

One switch. 72KB -> ~5KB.

Want to find where this is happening in your own project?

npx vite-bundle-visualizer  # see your full bundle as a treemap

Bundle analysis almost always reveals something that doesn't belong.

Choose Smaller Libraries

The fix isn't always how you import — it's what you import.

Open bundlephobia.com.
Search moment. Then search date-fns.

Same job. Very different cost.

Moment: 75.4KB minified
date-fns: 17.1KB minified

That's roughly 1.5s vs 342ms on Slow 3G.

Moment became so large that its own maintainers recommend not using it for new projects.

Not because it's broken. Because it no longer makes sense.

Goal #2 — Keep the Main Thread Free

Shipping less JavaScript gets it to the browser faster.

But whatever you ship still has to execute on the main thread.

Keep it free.

Long Tasks — Stop Freezing the Page

The browser can only do one thing at a time.

If JavaScript keeps the main thread busy for more than 50ms, everything else waits.

Clicks lag.
Scrolling freezes.
Animations drop frames.
That's a Long Task.

// 🔴 Blocks the main thread
function processLargeDataset(data) {
  return data.map(item => expensiveCalculation(item))
}
// 🟢 Gives the browser time to breathe
async function processLargeDataset(data) {
  const results = []
  for (let i = 0; i < data.length; i++) {
    results.push(expensiveCalculation(data[i]))
    if (i % 50 === 0) {
      await new Promise(resolve => setTimeout(resolve, 0))
    }
  }
  return results
}

setTimeout(resolve, 0) isn't making your code faster.

It's giving the browser a chance to handle pending input before continuing.

Feel the difference yourself.

Now inspect what's happening.

Open the CodePen -> Inspect -> Performance -> Record -> Reload.

Look for the red diagonal stripe in Main thread.

Every task longer than 50ms gets flagged.
The yielding version doesn't.
Breaking work into chunks fixes many long tasks.
Sometimes, though...

The work itself is the problem.

Web Workers — Move Heavy Work Off the Main Thread

Some work simply doesn't belong on the main thread.
Things like:

Image processing.
Large datasets.
Complex calculations.

Move it to a Worker.

// worker.js — separate thread, never blocks UI
self.onmessage = ({ data }) => {
  const result = heavyCalculation(data)
  self.postMessage(result)
}
// main.js — page stays responsive
const worker = new Worker('./worker.js')
worker.postMessage(largeDataset)
worker.onmessage = ({ data }) => {
  console.log('Done:', data)
}

Here's what that separation looks like — two threads, one message-passing bridge:

Turn the Worker OFF.
Keep pressing + until the particles begin to stutter.
Turn it back ON.
Same computation.
Different thread.
You can feel it — and the FPS counter backs you up.

In the demo, the main thread drops from 60fps to near-zero during heavy computation. The Worker keeps it at 60.

Want proof beyond feel? Open the demo in a new tab, start a Performance recording, and toggle the Worker a few times before you stop.

A Worker track shows up the moment it's switched on, and the Main thread goes quiet right alongside it. Switch it off, and the work lands straight back on the Main thread — the same moment the frame rate and CPU graph start complaining.

Nothing became faster.
The work simply stopped blocking the UI.

That's the entire point of Web Workers.

Before using one, remember three things.

Workers can't access the DOM. No document, no querySelector, no element event listeners. They process data and communicate through postMessage.
Messaging has a cost. Every message crosses a thread boundary. For tiny updates, that overhead can outweigh the benefit.
Threads aren't free. Workers consume memory and scheduling resources. A few heavy Workers are great. Dozens of tiny ones usually aren't.

The browser will never create a Worker for you.
If you want another thread, you have to ask for one.

Passive Listeners — One Word. Instant Win.

Heavy JavaScript isn't the only thing that blocks the main thread.

Sometimes the browser is waiting...
For your event listener.

When you scroll or touch the screen, the browser has to answer one question first:

"Is this listener about to call preventDefault()?"

If it might, scrolling has to wait.

// 🔴 Browser waits before scrolling
window.addEventListener('scroll', updateScrollPosition)
// 🟢 Browser scrolls immediately
window.addEventListener('scroll', updateScrollPosition, {
  passive: true,
})

passive: true is a promise:

"I won't cancel scrolling."

That lets the browser scroll immediately instead of waiting for JavaScript.

One word.
Instantly smoother scrolling.
Chrome even warns you when you forget.

🔧 Catch it in the act: Open the CodePen link -> DevTools -> Console -> interact with the hamburger menu. You'll see the warning. Uncomment the passive version and it disappears.

CodePen link: open it here

The JavaScript You Didn't Write

So far we've been fixing your JavaScript.
Sometimes the slowest JavaScript isn't yours at all.
It's the third-party scripts you embedded.
Here's the cost:

Downloads from a server you don't control.
Runs on your user's device.
Competes for the same CPU and main thread your own code needs.

Start with how it gets requested in the first place.

<!-- 🔴 Blocks HTML parsing -->
<script src="https://analytics.example.com/track.js"></script>

<!-- 🟢 Downloads in parallel -->
<script src="https://analytics.example.com/track.js" async></script>

That fixes when it loads.
It doesn't fix what happens once it's there.
Open DevTools.
Go to More tools -> Coverage.
Record a page load.

That screenshot tells a painful story.

97% of one script never executed.

It still downloaded, parsed, compiled, and competed for CPU time.

For code that never ran.

async only changes when a script shows up. It does nothing about how much of it was dead weight to begin with.

Every third-party script is someone else's code spending your user's battery, bandwidth, and main-thread time.

Treat each one like a dependency.
Because that's exactly what it is.

For the expensive embeds — YouTube, Maps, chat widgets — async isn't enough.

Don't load them at all.
Not until someone actually wants them.

<div class="video-facade" onclick="loadPlayer(this)" data-id="dQw4w9WgXcQ">
  <img src="thumbnail.webp" alt="Play video" width="640" height="360" />

  <button>▶ Play</button>
</div>

The fastest third-party script is the one that never loads.

CSS Is Not Free Either

Think you're done?

JavaScript isn't the only thing the browser has to process.

You already met CSS once, blocking your first paint back in the Critical Rendering Path.

That was the loading cost. This one's different.

CSS.

Every developer learns CSS as a stylesheet to build beautiful websites.

Does the browser see it the same way?

It doesn't.
The browser treats CSS as layout instructions.

Every time you change an element's size or position, it has to answer one question:

"Did this affect anything else?"

Sometimes the answer is one element.
Sometimes it's the entire page.
That's a reflow.
Reflows cost you frames.

The classic mistake looks harmless — say you're padding out a row of cards to match whichever one's tallest:

// 🔴 Read, write, read, write — once per card, every card
cards.forEach(card => {
  const height = card.offsetHeight
  card.style.height = height + 24 + 'px'
})
// 🟢 Read everything first, then write everything
const heights = cards.map(card => card.offsetHeight)
cards.forEach((card, i) => {
  card.style.height = heights[i] + 24 + 'px'
})

Reading layout (offsetHeight) immediately after writing layout (style.height) forces the browser to stop and recalculate synchronously.

Do it inside a loop and you pay that cost every iteration.

That's called layout thrashing.

It's common in card grids, feed lists, accordions — anything where you read layout and write styles in the same loop.

🔧 Two demos to run:
Animation — hit Start. Watch the FPS counters. margin-top drops frames. transform stays at 60.
Resize 50 Elements — hit ⛔ Run thrashing, then ✅ Run batched. The ms timers show the real cost. Same 50 elements. Same result. Completely different price.

Animate Without Making the Browser Sweat

Want to animate something?
Not every CSS property costs the same.

margin-top vs transform

One keeps the browser busy.
The other barely touches it.

/* 🔴 Layout recalculates every frame */
.card {
  margin-top: -4px;
}
/* 🟢 GPU moves the layer */
.card {
  transform: translateY(-4px);
}

Identical visual result.
Completely different cost.

margin-top changes layout.

Every frame, the browser recalculates positions before it can paint.

transform skips layout entirely.

The GPU compositor moves the layer without touching the DOM.

🔧 Hit Start. The animation looks the same. Watch the CPU meters instead.

One rule for every animation:

transform and opacity are the two safest properties the GPU compositor can animate without touching the main thread.

Everything else triggers layout, paint, or both.

CSS Containment — Tell the Browser What Can't Change

Imagine every component had invisible walls around it.
That's exactly what contain does.
Changes inside stay inside.

.card {
  contain: layout; /* changes inside don't affect outside */
}
.widget {
  contain: strict; /* fully isolated from the rest of the page */
}

Every contained component becomes an island — when something changes inside it, the browser doesn't have to recheck the rest of the page.

On a page with hundreds of cards, that's the difference between the browser rechecking one card's layout and rechecking all of them.

Real-world A/B tests back this up. Applying containment to product tiles on a high-traffic e-commerce category page cut INP by ~120ms on mobile. In prototype testing, adding DOM elements on interaction dropped rendering work from 732ms to 54ms.

Skip Rendering What Nobody Can See

Why render content that's still three screens away?
You don't have to.

.article-section {
  content-visibility: auto;
  contain-intrinsic-size: auto 600px;
}

content-visibility: auto tells the browser:

"Ignore this until it's about to enter the viewport."

No layout.
No paint.
No compositing.
Not until the user gets there.

It can cut rendering work by 50% or more. One real page dropped from 232ms to 30ms. That's a 7x improvement.

contain-intrinsic-size reserves space while the section is skipped, preventing layout shifts when it finally renders.

Choose a value close to the section's real height.

Too far off, and the page will jump when the content appears.

Chrome, Firefox, and Safari all support it today. Anything older simply ignores it and renders everything normally.

Safe to ship.

CSS optimized.

The rendering pipeline is doing as little work as possible.

But there's one resource that's usually bigger than all of it combined.

Images.

Images Are Probably Your Biggest Problem

Let's prove it.

🔧 Open DevTools -> Network -> Reload -> All -> sort by Size.

This is a blog post. Code blocks. A handful of screenshots.

Nothing like a portfolio, an e-commerce site, or Instagram.

And still, images dominate the top of that list.
Now imagine an online store.
Or a travel website.
Or a social media feed.
Odds are the top of that list isn't JavaScript.
It never is.
It's the thing everyone looks at, and nobody optimizes.

Four decisions. That's all it takes.

1. Choose the Right Format

Format matters more than compression settings.

Format	Best for
JPEG	Photos (fallback)
PNG	Transparency (fallback)
WebP	Default choice — 25–34% smaller than JPEG
AVIF	Best compression — about 50% smaller than JPEG
SVG	Icons, logos, illustrations

Let the browser choose the best format it supports.

<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="630" />
</picture>

Modern browsers get AVIF.
Older ones fall back automatically.
No JavaScript required.

2. Always Tell the Browser the Size

Always set width and height. These two attributes fix one of the most common causes of CLS.

<img src="hero.webp" width="1200" height="630" alt="Hero" />

Without them, the browser has no idea how much space to reserve.

The image loads.
Everything moves.
That's layout shift.

For your LCP image specifically, add fetchpriority="high" — it tells the browser: "Download this before less important images."

<img src="hero.webp" fetchpriority="high" width="1200" height="630" alt="Hero" />

3. Don't Send a 4K Image to a Phone

A phone doesn't need desktop-sized images.

srcset lets the browser choose the right one.

<img
  src="hero-800.jpg"
  srcset="hero-400.jpg 400w, hero-800.jpg 800w, hero-1200.jpg 1200w, hero-2400.jpg 2400w"
  sizes="(max-width: 600px) 100vw,
         (max-width: 1200px) 50vw,
         1200px"
  alt="Hero"
/>

A phone downloads the 400px version.
A desktop downloads the larger one.
Same image.
Different file.
Less wasted bandwidth.

4. Don't Download Images Nobody Can See

Images users can't see yet don't need to load immediately.

<img src="product.webp" loading="lazy" width="400" height="300" alt="Product" />

One attribute.

Often a 30–50% cut to initial page weight on an image-heavy page, sometimes more.

There is one important exception: Never lazy-load your LCP image.

If the hero is above the fold, delaying it delays your LCP.

Four decisions. One theme.

Smaller files.
Fewer pixels.
Fewer downloads.

That's why images are usually the biggest performance win.

A Real Example — dev.to Is Already Doing This

Every image you upload gets stored on S3 at full resolution.

That's not what your readers download.

Cloudflare intercepts every request, resizes the image, converts the format, and sends the smaller version. The original never changes. The user never sees it.

The URL tells the whole story:

You uploaded:
https://dev-to-uploads.s3.us-east-2.amazonaws.com/uploads/articles/your-image.gif

Your readers get:
https://media2.dev.to/dynamic/image/width=1000,height=420,fit=cover,gravity=auto,format=auto/https%3A%2F%2Fdev-to-uploads.s3.us-east-2.amazonaws.com%2Fuploads%2Farticles%2F1ydkr1d4qmhxyms63lpx.gif

width=1000,height=420. format=auto. fit=cover.

Resize. Convert. Crop. All at the edge, before a single byte reaches your reader.

Same image. Two URLs. Here's what that costs:

	Size	Time
CDN (what readers get)	147 kB	212ms
S3 original (what you uploaded)	22,759 kB	10.13s

That's 155× smaller and 48× faster.
Not from any code change. From a URL.

dev.to is doing automatically what this section teaches you to do manually.

They do it for images.
They do it for embeds too.

Every CodePen, every YouTube embed — none of them load until you scroll to them.

Open DevTools. Watch the Network tab. Scroll slowly down the page.

You'll see requests fire at the exact moment each embed enters the viewport. Not a second before.

That "Queued at 18.7 min" is the exact moment I scrolled to the embed.

Not at page load. Not before. The second it entered the viewport — the request fired.

And it resolved in 47 microseconds. Cloudflare already had it cached at the edge.

That's intersection observer lazy loading for iframes. Same principle as loading="lazy" on images. dev.to just applies it to everything.

Fonts Cost More Than You Think

Images delay pixels.
JavaScript delays interaction.

Custom fonts delay reading.

The browser reaches your text.
Your font isn't there yet.

On a cold connection, Google Fonts alone can add 300ms to your LCP before a single character appears.

Now it has a few choices.

FOIT (Flash of Invisible Text) — hide the text until the font finishes downloading.
FOUT (Flash of Unstyled Text) — show a fallback font, then swap when the custom font arrives.
font-display: optional — give the custom font a brief window to show up; if it isn't ready in time, stick with the fallback for the rest of the visit and skip the swap entirely.

None of them are perfect.
The goal is to make the compromise invisible.

font-display: swap chooses readability over visual perfection.

The user starts reading immediately.

Press Play and watch all three strategies side by side.

@font-face {
  font-family: 'Inter';
  src: url('/fonts/inter.woff2') format('woff2');
  font-display: swap;
}

Use woff2. It's smaller than older formats and supported by every modern browser.

One catch: If your fallback font has different metrics, swapping fonts causes layout shift. That's textbook CLS.

Properties like size-adjust, ascent-override, and descent-override in the @font-face rule let you tune the fallback so the swap barely moves.

You can also give the browser a head start.

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

The font starts downloading before CSS asks for it.
Or...
hear me out — use no custom font at all:

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

System fonts are already available on the user's device.

Zero downloads. Zero waiting.

GitHub, Notion, dev.to — all use system fonts. So why can't you?

The fastest font is the one you never download.

Three chapters, one rule.

The fastest JavaScript never downloads.
The fastest image is the smallest one.
The fastest font is already installed.

The next bottleneck follows the same rule.

Except now... The delay isn't on your page.

It's on the wire.

The Network Is Not Your Friend — Until You Work With It

You've trimmed the JavaScript. Optimized the CSS. Shrunk the images. Fixed the fonts.

The bottleneck moves — to the network.

TTFB — The Delay Before Anything Happens

Before the browser can download CSS, discover JavaScript or request your hero image...

It waits for the server to start responding.
That's Time to First Byte (TTFB).

Good       -> under 800ms
Needs work -> 800ms – 1.8s
Poor       -> over 1.8s

If your TTFB is two seconds...
Everything else starts two seconds late.
Frontend optimizations haven't even begun.

It might sound like a backend concern — until you see what it cost Amazon.

Every 100ms of added latency cost Amazon 1% in sales.
Not 1% of a bad quarter.

1% of revenue, every single time, from a tenth of a second.

At Amazon's scale today, that 1% is worth billions of dollars a year.

🔧 Clock it: DevTools -> Network -> Reload -> Click the HTML document -> Timing.

"Waiting for server response" bar is your TTFB.
Over 800ms means your server is now the bottleneck.
No amount of frontend optimization can hide it.

Four common causes — all fixable:

Slow database queries
No caching
No CDN
Servers too far from the user

A CDN (Content Delivery Network) solves the distance problem.

Instead of serving every request from one origin server, it serves files from an edge location close to the user. That's also why you'll often see region-specific domains like amazon.in and amazon.com alongside CDNs and regional data centers — shorter distances mean lower latency.

For global audiences, that's often a 200–400ms win before you've touched a line of code.

Platforms like Vercel, Netlify and Cloudflare already do this automatically.

If your server lives in one region while your users live everywhere...

A CDN is usually the highest-ROI optimization you can make.

Gzip, Brotli and Zstd — Free Bandwidth

Before files leave your server...
Compress them.

Original JS:   500 KB
After minify:  200 KB  (bundler handles this)
After gzip:     60 KB  (server handles this — 70% off)
After Brotli:   50 KB  (15–25% better than gzip)
After zstd:     48 KB  (newer than Brotli — what dev.to uses)

Minification removes unnecessary characters.
Compression removes unnecessary bytes.

Different job. Much bigger payoff.

Most CDNs enable compression automatically. Check yours:

🔧 Peek at the headers: DevTools -> Network -> Reload -> click any .js file -> Response Headers -> look for Content-Encoding.

br -> Brotli
gzip -> Gzip
zstd -> Zstandard

Any of them means compression is active.

dev.to already serves assets with zstd. If a platform serving millions of developers made the switch, the tooling is mature enough for your project too.

No Content-Encoding header?

Means your server is sending raw files — you're paying roughly a 70% bandwidth penalty for every request.

If you're using Vercel, Netlify, or Cloudflare... you're probably already covered.

No code change. Just a config line.
Most sites don't bother. That's why it's still a win.

On your own server, it's almost trivial — for gzip, at least.

# Nginx
gzip on;
brotli on;

# Apache
AddOutputFilterByType DEFLATE text/html text/css application/javascript image/svg+xml application/json

Gzip ships with nginx out of the box. Brotli doesn't — brotli on; will fail to start nginx unless you've already compiled in the separate ngx_brotli module (or you're on NGINX Plus, or using a distro package like nginx-extras on Debian/Ubuntu that bundles it in for you).

As for Zstandard (zstd), support depends on your server or CDN. Many modern CDNs already enable it automatically, while self-hosted servers often require additional modules or newer server software.

Preload, Prefetch, Preconnect — Know the Difference

These three are easy to confuse.
They solve completely different problems.

Preload -> I need this on this page.
Prefetch -> I'll probably need this on the next page.
Preconnect -> I'm about to talk to this server, just open the connection so it's ready when I knock.

<!-- Preload: I need this RIGHT NOW on the current page -->
<link rel="preload" href="/hero.webp" as="image" />
<link rel="preload" href="/fonts/font.woff2" as="font" crossorigin />

<!-- Prefetch: I'll probably need this when the user navigates NEXT -->
<link rel="prefetch" href="/about.js" />

<!-- Preconnect: warm up the connection to this domain -->
<link rel="preconnect" href="https://fonts.googleapis.com" />
<link rel="preconnect" href="https://cdn.myapp.com" crossorigin />

<!-- DNS lookup only: cheaper preconnect — resolves DNS only -->
<link rel="dns-prefetch" href="https://analytics.myapp.com" />

Use the wrong one and you waste bandwidth. Skip them entirely and you waste time.

Hint	Use it for
`preload`	Hero image, critical font, above-the-fold CSS
`prefetch`	Likely next page
`preconnect`	Third-party origins you'll definitely contact
`dns-prefetch`	Third-party origins you might contact

One <link rel="preconnect"> eliminates the DNS, TCP, and TLS cost upfront. That's typically 100–300ms saved per domain.

One warning: preload is a priority override — every preloaded resource jumps to the front of the queue.

Preload ten things and you've prioritized nothing.

Cache Everything That Doesn't Change

The browser already has an excellent cache.
Most sites barely use it.

Cache-Control: no-cache                    -> always validate with server
Cache-Control: max-age=31536000            -> cache for one year
Cache-Control: max-age=31536000, immutable -> cache forever, never revalidate

The pattern never changes.

HTML files     -> Cache-Control: no-cache
                 (always check for new HTML — it references
                 updated asset URLs)

JS/CSS/Images  -> Cache-Control: max-age=31536000, immutable
                 (cached forever — content hash in filename
                 changes on deploy)

Modern bundlers already fingerprint assets. (app.a3f5b2c.js)

app.js
↓
app.a3f5b2c.js

New deploy, new hash.
Same hash, instant cache hit.

The browser downloads it once.
Everything else stays cached forever.
Here's what that looks like on a repeat visit.

🔧 Watch it stick: DevTools -> Network -> reload twice -> watch the Size column.

Cached resources return instantly: 0ms.

Network requests still take: 371ms to over 1 second.

Same files.
Zero download.
That's exactly what immutable buys you.
Configuration depends on your host.

# Netlify — netlify.toml
[[headers]]
  for = "/assets/*"
  [headers.values]
    Cache-Control = "max-age=31536000, immutable"

[[headers]]
  for = "/*.html"
  [headers.values]
    Cache-Control = "no-cache"

// Vercel — vercel.json
{
  "headers": [
    {
      "source": "/assets/(.*)",
      "headers": [{ "key": "Cache-Control", "value": "max-age=31536000, immutable" }]
    }
  ]
}

One deploy. One download. Every visit after that is free.

Back/Forward Cache — The Fastest Navigation You'll Ever Ship

What's faster than caching files?
Not loading the page at all.

That's exactly what the Back/Forward Cache (bfcache) does.

Press Back.

The browser restores the entire page from memory.

No network.
No rendering.
No JavaScript startup.
Usually under 100ms.

Most developers break it without realizing.
The biggest culprit?

unload.

// 🔴 Disables bfcache
window.addEventListener('unload', cleanup)
// 🟢 Compatible with bfcache
window.addEventListener('pagehide', cleanup)

Many analytics libraries still register unload handlers behind the scenes.

One script.
Your entire site loses bfcache.
Check yours.

🔧 DevTools -> Application -> Back/Forward Cache -> Run Test

Passing: dev.to

Failing: CodePen

The report tells you exactly what prevented caching.
Fix what it reports.

One exception: banking, payments, medical portals — anything showing sensitive data.
In those cases, restoring an old page from memory may be the wrong trade-off.

Security wins.

For everything else... bfcache should work by default.

One Move, Five Times

Every optimization in this chapter does exactly the same thing.

It avoids work.

A CDN avoids the long trip to your origin server.
Compression avoids sending unnecessary bytes.
Preconnect avoids waiting for a connection to open.
Caching avoids downloading files twice.
bfcache avoids loading the page altogether.

The fastest request isn't the one you optimize.

It's the one the browser never has to make.

Framework Patterns That Actually Move the Needle

Everything so far was browser fundamentals.

Now let's look at what your framework is already doing for you.

Here's what many developers miss.

React and Vue aren't fast because they're frameworks.
They're fast because they avoid unnecessary work.
Out of the box:

React batches state updates (React 18+) so multiple setState() calls become a single render.
Vue batches reactive updates and flushes DOM changes together on the next tick.
Both diff a virtual DOM before touching the real DOM.

Less work.
Fewer DOM updates.
Better performance.
Most applications never need more than that.

The techniques below are for when the defaults stop being enough.

TLDR — what this chapter covers:
React and Vue already optimize rendering by default. This chapter covers three things for when that's not enough: memoization, conditional rendering (v-if vs v-show), and virtualization.

Angular, Svelte, or Solid? Same ideas, different APIs — I don't have enough production experience to cover them accurately.
Skip to Perceived Performance

Stop Re-rendering What Didn't Change

The fastest render... is the one that never happens.

React skips re-rendering with React.memo() — it wraps a component and bails out if props haven't changed.

Vue handles this differently. Its reactivity system is more granular by default — components only re-render when their reactive dependencies change. For expensive computed values, computed() caches the result and only recalculates when its dependencies change.

// 🟢 React — skip re-rendering when props are the same
const DataGrid = React.memo(function DataGrid({ rows }) {
  return rows.map(row => <Row key={row.id} data={row} />)
})

// 🔴 React — comparison overhead outweighs the benefit
const Badge = React.memo(function Badge({ label }) {
  return <span>{label}</span>
})

// 🟢 Vue — cached until dependencies change
const total = computed(() => cart.items.reduce((sum, item) => sum + item.price, 0))

// 🔴 Vue — recalculates every render
const total = () => cart.items.reduce((sum, item) => sum + item.price, 0)

The part most tutorials skip: memoization is not free.

Every memoized component first compares its inputs before deciding to skip rendering.

If the component is cheap, that comparison can cost more than rendering itself.

Good candidates are:

Large lists
Heavy components
Expensive calculations
Deep trees with stable props

Everything else?
Measure first.

v-if vs. v-show — Don't Default to One

Vue has an optimization most developers get wrong.

<!-- 🔴 Destroy and recreate every toggle -->
<ExpensiveModal v-if="isOpen" />
<!-- 🟢 Keep mounted, toggle visibility -->
<ExpensiveModal v-show="isOpen" />

Rarely shown?
-> Use v-if. The component never mounts.

Frequently toggled?
-> Use v-show. It stays in the DOM, just hidden.

Don't guess.

React DevTools Profiler and Vue Devtools will tell you exactly where your renders are coming from.

Virtualization — The DOM Was Never Meant for 10,000 Rows

Imagine a city-select dropdown with 10,000 options.
The user can only see 15 at a time.

The other 9,985:

Still consuming memory.
Still participating in layout.
Still slowing everything down.

Don't render them.
Render only what's visible.

// React
import { FixedSizeList as List } from 'react-window'
;<List height={600} itemCount={rows.length} itemSize={50}>
  {({ index, style }) => <Row style={style} data={rows[index]} />}
</List>

<!-- Vue -->
<RecycleScroller :items="rows" :item-size="50" v-slot="{ item }">
  <Row :data="item" />
</RecycleScroller>

Ten thousand rows in memory.
Fifteen rows in the DOM.
That's virtualization.

Perceived Performance — Making It Feel Fast Before It Is

Technical performance improvements make pages faster.
Perceived performance makes them feel even faster.
Those aren't always the same thing.

A 1.5-second API request behind a spinner feels slow.
The same 1.5 seconds with an optimistic update feels instant.

The network didn't change.
The experience did.

🔧 Race them: Which one feels fastest?

That's perceived performance.

Optimistic Updates — Respond Before the Server Does

Most applications wait for server confirmation before updating the UI.

Optimistic updates reverse that order.
The UI updates immediately.
The server catches up afterward.

function likePost(postId) {
  setLiked(true)
  setLikeCount(count => count + 1)
  api.likePost(postId).catch(() => {
    setLiked(false)
    setLikeCount(count => count - 1)
  })
}

If the request fails... Roll it back.

GitHub stars.
Notion edits.
They all update before the server responds.

In Instagram's earlier days, a single Justin Bieber post could pull in millions of simultaneous like-taps within seconds — more than enough to choke a database trying to keep an accurate count in real time.

That's a backend problem. It needed its own backend fix.
But it also exposed a frontend one: every tap was a person waiting on a network round-trip just to see a number move.

Optimistic updates fixed that part.

The number you see immediately after pressing ❤️ is often an optimistic estimate that eventually catches up.

It feels instant because your tap isn't waiting for the database anymore.

Stale While Revalidate — Show Something Now

Returning users shouldn't stare at another loading spinner.

They've already seen this data.
Show the cached version immediately.
Refresh it quietly in the background.

// TanStack Query / SWR
const { data } = useQuery({
  queryKey: ['dashboard'],
  queryFn: fetchDashboardData,
  staleTime: 30_000,
})

First visit -> normal load.
Every next visit -> instant content from cache.
Silent refresh.

Libraries like TanStack Query and SWR make this almost effortless.

You see it in the Instagram feed too — the content from your last visit appears instantly while fresh posts load in the background.

Prefetch Before the Click

Remember the prefetch hint from a few chapters back? That was a guess about the next page.

People rarely click instantly.
Most hover for 200–300ms first.
That's free time. Use it.

document.querySelectorAll('a[data-prefetch]').forEach(link => {
  link.addEventListener(
    'mouseenter',
    () => {
      const preload = document.createElement('link')
      preload.rel = 'prefetch'
      preload.href = link.href
      document.head.appendChild(preload)
    },
    { once: true }
  )
})

By the time the click happens...
Part of the next page is already downloading.

Next.js does this automatically for internal links.

Skeletons Beat Spinners

A spinner tells the user...

"Something is happening."

A skeleton tells them...

"This is what you're waiting for. The content is almost here."

The loading time is identical.

Research by Viget found users rate skeleton screens as 20% faster than spinners — even when the actual load time is identical.

Not because they are.
Because uncertainty feels slower than progress.

A different kind of win this time.

None of these techniques make the server faster.
They change when the user experiences the wait.
Sometimes that's enough.

Because performance isn't only measured in milliseconds.

It's measured in how long the wait feels.

Lighthouse Is Where You Start. Field Data Is Where You Trust.

You've spent the whole article learning what to optimize.

Now let's learn how to find it.
Start with Lighthouse.
Run it before every release.

🔧 Run it now: DevTools -> Lighthouse -> Mobile -> Analyze page load.

Ignore the score.
The real value is underneath.

FCP.
LCP.
TBT.
CLS.
Speed Index.

Each one points to a specific bottleneck.
Scroll a little further.

Lighthouse doesn't just tell you something is slow.
It tells you why.

Render-blocking resources.
Unused JavaScript.
Long Tasks.
Broken bfcache.

Prioritized. Estimated. Actionable.

One caveat: that 81 score came from one controlled test.

One device.
One network.
One page load.

Your users don't browse under laboratory conditions.

They browse:

On trains.
In elevators.
On overloaded mobile networks.

That's why field data exists.

🔧 Check it yourself: Go to PageSpeed Insights pagespeed.web.dev, paste any URL, then look for "Discover what your real users are experiencing."

Notice something.

The top section isn't Lighthouse.
It's CrUX.

Real Chrome users.
Real devices.
The last 28 days.

The score underneath is still Lighthouse.
Same page.
Different measurement.

In this example,

This URL measures only the homepage.
Origin averages every page on dev.to.

Same site.
Different data.
Different conclusions.

Lighthouse tells you what's possible.
Field data tells you what's happening.

When they disagree... Trust the field.

Once you've found the problem, you've already learned how to investigate it.

Open the Performance panel. -> Record. -> Find the bottleneck. -> Fix it.

Finally, measure your own users:

import { onLCP, onINP, onCLS } from 'web-vitals'
onLCP(metric => analytics.track('LCP', metric.value))
onINP(metric => analytics.track('INP', metric.value))
onCLS(metric => analytics.track('CLS', metric.value))

Send those metrics to whatever analytics platform you already use.

Then watch the p75 — not the average, but the point where 75% of visits were this fast or faster.
That's the number Google uses for Core Web Vitals scoring.
And it's the one your users actually experience.

One more tool: WebPageTest.

Lighthouse covers most days. WebPageTest goes deeper — filmstrip, waterfall, real device in a specific city on a throttled connection.

Same site. Same browser. Same connection speed. Tested from two cities on opposite sides of the planet:

Tokyo and Columbus, Ohio — and the numbers barely move. That's a CDN doing its job.

Full reports: Tokyo run · Columbus run

The Performance Budget — Make It Impossible to Regress

Here's the problem — you fix performance, the numbers look great, then it quietly rots.

Performance doesn't usually break overnight.
It leaks.

One dependency.
One analytics script.
One feature.

Sprint after sprint.

Your Lighthouse score is 92 today.
Six months later it's 58.
Nobody remembers when it happened.

A performance budget fixes that.

It's a contract enforced by CI.

// lighthouserc.js
module.exports = {
  ci: {
    assert: {
      assertions: {
        'categories:performance': ['error', { minScore: 0.85 }],
        'largest-contentful-paint': ['error', { maxNumericValue: 2500 }],
        'total-blocking-time': ['error', { maxNumericValue: 200 }],
        'cumulative-layout-shift': ['error', { maxNumericValue: 0.1 }],
        'resource-summary:script:size': ['error', { maxNumericValue: 300000 }],
      },
    },
  },
}

Five limits. Miss any one, and CI flags it before a reviewer has to.

Wire it into your pipeline — and performance stops being someone's responsibility.

Cross the limit.
The pipeline fails.

The Uncomfortable Part Nobody Puts in the Tutorial

Every optimization you've seen has trade-offs.

Lazy-loading your hero image delays your LCP.
Wrapping every component in memo adds comparison overhead.
Preloading everything means nothing is truly prioritized.
SSR improves LCP but introduces hydration work.
Over-splitting bundles creates unnecessary network overhead.

Performance advice isn't universal. It's contextual.

Before changing anything, ask one question:

Am I solving a problem I've actually measured, for users who actually have it?

If you can't answer that — that's not optimization.

That's a guessing game.

The most expensive optimization is the one that improves a metric nobody was watching.

The Checklist You'll Actually Use

One article. Twelve chapters. Hundreds of decisions.
Here's all of it in one place.

Server
  ✓ Keep TTFB under 800 ms                           (imp)
  ✓ Serve through a CDN                              (imp)
  ✓ Enable Brotli or Gzip or Zstd                    (imp)
Browser Rendering
  ✓ Remove render-blocking CSS and JS                (imp)
  ✓ Use defer for app scripts                        (imp)
  ✓ Inline critical CSS
JavaScript
  ✓ Code split by route                              (imp)
  ✓ Tree shake dependencies                          (imp)
  ✓ Analyze bundles before release
  ✓ Use passive listeners
  ✓ Load third-party scripts with async              (imp)
  ✓ Move heavy work to Web Workers
  ✓ Break up long tasks                              (imp)
CSS
  ✓ Animate transform and opacity only               (imp)
  ✓ Avoid layout thrashing
  ✓ Use CSS containment
  ✓ Use content-visibility for off-screen content
Images
  ✓ Prefer AVIF or WebP                              (imp)
  ✓ Always set width and height                      (imp)
  ✓ fetchpriority="high" for the LCP image           (imp)
  ✓ Lazy-load below the fold                         (imp)
  ✓ Use srcset
Fonts
  ✓ Preload critical fonts                           (imp)
  ✓ Use font-display: swap                           (imp)
  ✓ Prefer system fonts when possible
Network
  ✓ Preconnect to third-party origins
  ✓ Prefetch likely next pages
  ✓ Cache hashed assets aggressively                 (imp)
  ✓ Keep bfcache working                             (imp)
Framework
  ✓ Memoize expensive components only                (imp)
  ✓ Virtualize long lists
Perceived Performance
  ✓ Optimistic updates
  ✓ Stale-while-revalidate
  ✓ Prefetch on hover
  ✓ Skeleton screens                                 (imp)
Measurement
  ✓ Lighthouse CI                                    (imp)
  ✓ web-vitals in production                         (imp)
  ✓ Track p75 field data                             (imp)
  ✓ Verify with WebPageTest

Not every item applies to every project.

But every item you skip should be a choice you made — not an oversight.

The Takeaway

Performance isn't about making browsers faster.

It's about giving them less work to do.

Less JavaScript to parse.
Less CSS to calculate.
Fewer images to download.
Fewer layouts to recalculate.
Fewer requests to make.

Every optimization in this article follows the same idea.

Avoid work.

Because every piece of work you remove... is time your user gets back.

Three seconds.
You don't earn them back with one optimization.
You earn them back a hundred milliseconds at a time.

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal — Fri, 12 Jun 2026 18:31:01 +0000

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript - DEV Community

A few days ago, I shared an article: You Don't Need Another Agent. You Need a Linter. Then I did...

dev.to

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript

Utkarsh Bansal — Fri, 12 Jun 2026 12:37:30 +0000

A few days ago, I shared an article:

You Don't Need Another Agent. You Need a Linter.

Then I did what I do with anything I write: shared it around — a few publications, a few channels.

Two reasons:

First, feedback. I'd genuinely rather get roasted and fix my blind spots than stay comfortable and wrong.

Second, let's be honest: reach.
Every writer enjoys seeing a few more views.

Most of the responses were positive.

One wasn't.

A publication rejected it with the reason:

LOW_QUALITY

Fair enough.

It means there's room for improvement.

Funny enough, my caffeinated 1 AM brain disagreed.

Then it did what every developer does when someone says "this isn't good enough."

It took that personally.

So I went back and reread the article.

And after the initial ego check, I realized something serious:

The article talked in detail about ESLint, why it matters more in an AI-assisted world than ever.

What it did not do was answer the question that actually matters:

What is ESLint, how does it work, and why has half the JavaScript ecosystem quietly built its quality process around it?

So let's fix that.

Now, this isn't a sequel to my last piece about untangling vibe-coded code. It stands on its own — one thing, done properly.

A complete teardown of ESLint:

What it is
How it works internally
Why companies use it as a quality gate
The different classes of problems it solves
How plugins work
How to write your own rules
Where it fails
Why it still beats many AI-based review systems

Fair warning.

This article is going to be technical.

There will be syntax trees.

There will be compiler concepts.

There will be enough JavaScript internals to make frontend developers slightly uncomfortable.

I'll try my best to keep it readable not letting it turn into another manual - which nobody finishes.

Let's start with the question most people never ask.

What Is ESLint Actually Doing?

Most developers describe ESLint like this:

It checks code for mistakes.

Technically true. Also completely useless.

That's like describing a car as:

It helps you move.

The interesting part is how?

Consider this code:

import axios from "axios";

function getUsers() {
  return fetch("/api/users");
}

With the right rules on, ESLint can tell us:

axios is imported and never used
fetch is being used
getUsers exists
getUsers is never called
there are no syntax errors

But how?

The answer is that ESLint never reads code as text.

The first thing it does is destroy your beautiful source code.

Step 1: Your Code Stops Being Code

The moment ESLint sees a file, it passes it through a parser.

The parser converts your code into something called an Abstract Syntax Tree (AST).

Your code:

const answer = 42;

becomes something closer to:

{
  "type": "VariableDeclaration",
  "kind": "const",
  "declarations": [
    {
      "id": { "name": "answer" },
      "init": { "value": 42 }
    }
  ]
}

Notice what's missing.

Formatting. Spacing. Comments. Indentation.

The parser doesn't care. The AST only cares about meaning.

To ESLint, your source code isn't text anymore.

It's a tree.

Literally. That same const answer = 42 looks like this:

VariableDeclaration · const
└─ VariableDeclarator
   ├─ Identifier · "answer"
   └─ Literal · 42

The JSON above and this tree are the same thing. One's just easier to look at.

And every lint rule is basically a tree inspector.

That's the core idea:

Source code
   ↓
Parser
   ↓
AST
   ↓
Rules inspect nodes
   ↓
Reports / warnings / errors

Step 2: Rules Walk The Tree

Every ESLint rule is a visitor.

It walks through the nodes inside the AST and asks questions.

For example:

console.log("debug");

produces a node that looks like:

CallExpression

The no-console rule simply visits every CallExpression and asks:

Is this a console call?

If yes.

Report error.

That's it.

No AI. No embeddings. No vector database.

Just deterministic tree traversal.

Computer science doing computer science things.

Why This Is More Powerful Than It Sounds

Most people hear "static analysis" and immediately think:

So... it catches semicolons?

No.

Semicolons are the least interesting thing ESLint does.

Let's look at the categories.

Category 1: Correctness

These rules catch code that is probably wrong.

A function that doesn't exist:

foo();

An assignment hiding inside a condition:

if (user = admin) { /* ... */ }

A promise nobody awaited:

promiseFunction();

These are not style issues. These are bugs.

The code may compile. It may even pass tests.

But eventually somebody is getting paged at 2 AM.

Category 2: Dead Code

AI loves dead code. Humans create it too. AI just does it faster.

An import that's never used:

import lodash from "lodash";

A function nobody calls anymore:

function oldImplementation() {}

One abandoned experiment later, and your repository becomes an archaeological site.

Dead code increases bundle size, maintenance cost, and confusion.

The cheapest bug is the code that doesn't exist.

ESLint helps make that happen.

Category 3: Security

This is where people start underestimating linters.

Consider:

eval(userInput);

No. Just no.

Or:

element.innerHTML = userInput;

Also no.

A decent security-focused lint setup can stop entire classes of vulnerabilities before the code ever reaches production.

Not because it's intelligent.

Because it recognizes dangerous patterns.

And dangerous patterns repeat. A lot.

Category 4: Performance

Some rules exist purely because developers keep making the same expensive mistakes.

This:

array.indexOf(value) !== -1;

can become this:

array.includes(value);

Tiny improvement.

Now repeat it across a million lines of code, and you've quietly compressed years of engineering experience into a config file.

That's what lint rules really are.

Institutional memory

The Real Superpower: Quality Gates

The biggest mistake teams make is treating ESLint like a suggestion.

A linter running in your editor is nice.

A linter blocking merges is transformative.

The moment ESLint becomes part of CI, it stops being advice.

It becomes policy.

The workflow changes from:

Hopefully somebody notices the bug in review.

to:

The code physically cannot merge.

That's a completely different game.

Good engineering isn't about creating perfect developers.

It's about creating systems where common mistakes cannot survive.

ESLint is one of those systems.

Developer writes code
   ↓
Editor lint shows warnings
   ↓
PR created
   ↓
CI runs lint
   ↓
Pass → merge
Fail → fix before merge

Community Plugins Already Solved Half Your Problems

Here's the part most developers miss.

ESLint is a rule engine.

It parses code, walks the AST, runs rules, reports violations, and that's basically the entire core.

The real power comes from everything built on top of it: plugins, shared rule sets, and years of accumulated engineering knowledge.

Need to find unused imports?

There's a plugin. eslint-plugin-unused-imports

Need TypeScript-aware analysis?

There's a plugin. @typescript-eslint

Need accessibility checks for your components?

There's a plugin. eslint-plugin-jsx-a11y or eslint-plugin-vuejs-accessibility

Need to catch dangerous security patterns?

There's a plugin. eslint-plugin-security

Need to enforce architectural boundaries between layers?

Believe it or not, there's a plugin for that too. eslint-plugin-boundaries.

You don't have to write any of this yourself.

Thousands of developers have already spent years turning common mistakes into reusable rules.

A few common examples:

eslint-plugin-unused-imports — dead imports and variables
eslint-plugin-import — circular dependencies and broken paths
@typescript-eslint — type-aware correctness rules
eslint-plugin-jsx-a11y / eslint-plugin-vuejs-accessibility — accessibility
eslint-plugin-promise — dropped awaits and async mistakes
eslint-plugin-security — dangerous patterns like eval
eslint-plugin-boundaries — architectural layer rules

That's the mental shift.

Most people think ESLint is one tool with a bunch of built-in rules.

It's closer to a platform.

A small, stable engine that lets an entire ecosystem contribute knowledge.

  eslint-plugin-import     @typescript-eslint     your local rules
   (cycles, dead code)     (type-aware checks)     (team gates)
            │                      │                      │
            └──────────────────────┼──────────────────────┘
                                   ▼
            ┌──────────────────────────────────────────┐
            │                ESLint core                 │
            │     parse → walk the AST → run → report     │
            └──────────────────────────────────────────┘

That's why ESLint has survived for so long.

The core doesn't need to know about React.

Or Vue.

Or TypeScript.

Or whatever framework we'll all be rewriting our applications in next year.

The engine stays the same.

The ecosystem keeps growing.

The core never changes. The rules feeding into it are infinite.

And eventually you realize something interesting:

Most teams don't need more tooling.

They just need to enable the plugins that already exist.

When The Defaults Aren't Enough: Write Your Own Rule

Now for the fun part — the part that makes ESLint feel less like a tool and more like a system.

Suppose your company has a design system. And somebody keeps committing raw colors:

color: "#FF0000";

instead of:

color: tokens.error;

You can complain. You can review every PR. Or you can automate the complaint.

Here's the entire rule:

// rules/no-raw-color.js
export default {
  meta: {
    type: "problem",
    messages: { rawColor: "Use a design token, not a raw hex like '{{value}}'." },
  },
  create(context) {
    return {
      // the walker hands you every string literal; you keep the ones that look like hex
      Literal(node) {
        if (typeof node.value === "string" && /^#[0-9a-f]{3,6}$/i.test(node.value)) {
          context.report({ node, messageId: "rawColor", data: { value: node.value } });
        }
      },
    };
  },
};

That's it. No npm package, no publishing. Flat config lets you wire a local rule in directly, and ESLint's built-in RuleTester lets you prove it fires on "#FF0000" and stays quiet on tokens.error.

A custom ESLint rule is usually less code than the Slack argument it prevents.

That's the real secret.

The best engineering teams don't repeatedly solve the same problem.

They automate it.

Every bug becomes a rule. Every rule becomes institutional knowledge. Every future developer benefits.

Human. Or AI. Doesn't matter.

The gate treats everybody equally.

Where ESLint Fails

Now, before somebody accuses me of turning ESLint into a religion — it has limits.

ESLint cannot tell:

if your architecture is good
if your business logic is correct
if the feature should even exist
if your product manager had a terrible idea

Those remain human problems.

Static analysis sees structure. Not intent.

A green lint report does not mean correct software.

It means your code survived a specific set of inspections.

Nothing more. Nothing less.

So Why Am I Still Talking About ESLint In The Age Of AI?

Because every week I see somebody proposing:

AI review agents
AI architecture agents
AI quality agents
AI code verification agents

And half the time, they're trying to solve problems ESLint solved years ago.

Before building another agent, ask:

Can a deterministic static analysis tool already solve this?

Because if the answer is yes, the boring tool is:

faster
cheaper
reproducible
and it doesn't hallucinate

The boring solution often wins.

Not because it's exciting. Because it works.

And software engineering eventually rewards whatever keeps production alive — even if it was invented twenty years ago.

Takeaway

The most important thing I learned from AI-assisted development wasn't how powerful AI is.

It was how valuable boring tooling remains.

ESLint isn't glamorous. Nobody posts screenshots of lint checks on LinkedIn. Nobody raises venture capital for a missing-semicolon detector.

But every large JavaScript codebase eventually discovers the same truth.

It parses code. It walks trees. It applies rules. It reports violations. That sounds humble — but the impact compounds: it catches bugs early, enforces standards, protects architecture, scales institutional memory, and keeps bad code from sneaking through the door.

And unlike the rest of us, it never gets tired.

The cheapest reviewer on your team is still a linter.

If you still think of ESLint as a semicolon cop, you're missing most of the point.

It was never about the semicolons.

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal — Wed, 10 Jun 2026 15:54:26 +0000

You Don't Need Another Agent. You Need a Linter. - DEV Community

In my last post I complained — a lot — about vibe code and the beautiful disaster it left...

dev.to

You Don't Need Another Agent. You Need a Linter.

Utkarsh Bansal — Wed, 10 Jun 2026 15:49:20 +0000

In my last post I complained — a lot — about vibe code and the beautiful disaster it left behind.

Now, I'm not here just to complain. There were a lot of learning opportunities too, like how to handle legacy / vibe code. Because at the end of the day, both are the same: no one knows how they work, but somehow they keep working. Touching them is like defusing a bomb — you never know how your change might cascade and break the core logic.

The good news is that vibe code is much simpler than legacy. AI, in all its glory, tries to write perfect-looking code — proper function names, comments, the works — not like legacy code where a single function runs 500 lines, with spaghetti names all over that make no sense and comments that are out of date.

And that makes it something I can actually handle. I still don't have a perfect, step-by-step playbook — but I've got pieces.

The first one. The cheapest and the oldest one. The one the industry solved decades ago and the whole "AI built my app in a day" crowd somehow forgot exists.

A linter.

Yes, you heard me right. A linter. ESLint.

Most people who've been in this industry already know it. It's the most boring, reliable tool in the box.

But in an era where the answer to every problem is "add another AI," it's worth saying out loud why the boring tool still wins.

What a linter actually is

If you vibe-coded your way into this world, or you're new to web dev in general and have never heard the word "lint", here's the honest version.

A linter is a set of rules you add to your repo. It reads your code without running it, checks it against those rules, and flags everything that's broken, sloppy, or about to bite you in production.

The detail people get wrong: it's not a grep for bad words.

A real linter parses your code into a syntax tree and actually reasons about its structure — what's imported, what's called, what's reachable, what types flow where.

That's why a rule like no-unused-vars can tell "you imported this and never used it" apart from "you used this without importing it."

It's also why eslint-plugin-unicorn can quietly rewrite array.indexOf(x) !== -1 into array.includes(x) (unicorn/prefer-includes), or flag a new Array(...) call that's going to bite you — without ever executing a single line.

Three properties matter:

It doesn't run your code. No side effects, no flaky network, no "works on my machine."
It's deterministic. Same code in, same result out, every single time. No temperature, no vibes.
It costs nothing. No tokens. No API bill. It runs in seconds on a laptop or a CI box.

In 2026, that last one is the whole argument.

Why this matters more than it used to

We have AI to write code. AI to review code. AI to verify code. Agents stacked on agents, each one quietly spending tokens to do something a free tool already did better.

And honestly? Most of those agents are re-solving problems that were solved long before "agent" meant what it means today.

You do not need a language model to notice that you left a debug log in production (no-console). Or imported a module you never used (unused-imports/no-unused-imports). Or wrote a function nobody calls (knip). Or forgot to await a promise (@typescript-eslint/no-floating-promises). Or made two files import each other in a circle (import/no-cycle).

A linter catches every one of those instantly, deterministically, for free — before any AI even wakes up.

So before you bolt another agent onto your pipeline, ask the boring question:

Does the free, battle-tested tool already do this?

Usually it does.

Use what already exists.

A linter is a Quality Gate

This is the real reason linters matter. Whether you're a big company or a freelancer just starting out.

A linter is a quality gate. A line in the sand that says:

This code does not get in unless it clears the bar.

Where I work, we wired this straight into the pull-request flow. A check a PR has to pass before it can merge.

Not a suggestion. Not "we'll clean it up later." A hard gate on the merge button.

The result was the kind of number that sounds made up until you live it: production issues and bad merges dropped by roughly 80%.

Magic? No.

Most of our incidents were the same boring handful — an unhandled promise that swallowed an error, a stray debug log left in, a circular import that only broke in prod. The gate caught every one of them at the door — we just stopped letting broken code through.

That's the whole trick.

A gate doesn't make anyone smarter. It just raises the floor.

A tip if you're at a big company: when you introduce the ESLint check, you'll hear a lot of pushback from devs — especially at a startup or midsize company. So be ready for a fight, and roll it out gradually: a warning gate first, then an error gate.

It doesn't stop at "missing semicolon"

Here's the common misconception people hit when they first add ESLint and see all those errors: "this thing is bad, it just nags me like my annoying brother." That's a huge underestimation.

Once you treat the linter as a real gate instead of a nag, you can teach it your specific mistakes. And it never forgets them.

Every painful bug in an AI-assisted codebase is also a pattern. And patterns are exactly what static analysis is good at.

A surprising amount of this is one config file away. Modern ESLint flat config plus a few community plugins covers most of it:

// eslint.config.js — a starter "quality gate", not a missing-semicolon nag
import unusedImports from "eslint-plugin-unused-imports";
import importPlugin from "eslint-plugin-import";
import unicorn from "eslint-plugin-unicorn";

export default [
  {
    plugins: { "unused-imports": unusedImports, import: importPlugin, unicorn },
    languageOptions: {
      // type-aware rules need the TS program, not just the syntax tree
      parserOptions: { projectService: true },
    },
    rules: {
      // ~100 perf + hidden-bug rules in one line; downgrade the churny ones
      ...unicorn.configs["flat/recommended"].rules,
      "unicorn/filename-case": "off",       // Vue files are PascalCase by convention
      "unicorn/prevent-abbreviations": "off", // trips on `ref`, `props`, store names
      // dead code the model left behind — auto-fixable
      "unused-imports/no-unused-imports": "error",
      "unused-imports/no-unused-vars": "warn",
      // the silent killer (see the circular-deps post) — crank maxDepth up
      "import/no-cycle": ["error", { maxDepth: 10, ignoreExternal: true }],
      // dropped awaits that swallow errors — needs the type info above
      "@typescript-eslint/no-floating-promises": "error",
      "@typescript-eslint/no-misused-promises": "error",
      // dynamic code execution: off by default in eslint:recommended, turn them on
      "no-eval": "error",
      "no-implied-eval": "error",
      "no-new-func": "error",
      "no-script-url": "error",
    },
  },
];

That's the floor.

On top of it, every time something hurt us, we added a rule so it could only hurt us once. Three of them earned their place the hard way:

Circular dependencies — import/no-cycle with maxDepth: 10 (the default of 1 only sees direct A↔B cycles), backed by dependency-cruiser for the whole-graph view. AI refactors love making two modules import each other until the build breaks only in prod. It's the single most common AI-induced bug I've seen — enough that it deserves a post of its own.
Dropped awaits — @typescript-eslint/no-floating-promises and no-misused-promises. A missing await on a file or network call silently swallows the error, and you find out when a user does. Needs type-aware linting (parserOptions.projectService) — the one setup cost worth paying.
The free-wins pack — eslint-plugin-unicorn's flat/recommended: ~100 rules for one import. A mix of performance wins (prefer-includes, prefer-set-has), real hidden-bug catches (no-array-push-push, no-thenable), and some opinionated style. Turn off the churn (unicorn/filename-case, unicorn/prevent-abbreviations, unicorn/no-null) and keep the rest. Best caught-mistakes-to-config ratio you'll find.

The rest are quieter, but each one caught something once. Skim them:

Dead code — eslint-plugin-unused-imports sweeps the imports the model added for an approach it then abandoned (auto-fixed on --fix).
No eval — no-eval, no-implied-eval, no-new-func, no-script-url. Off by default; zero legit uses, infinite ways for generated code to sneak one in.
XSS sinks — vue/no-v-html / react/no-danger, plus eslint-plugin-no-unsanitized for raw innerHTML. Any HTML injection has to pass through a sanitizer, enforced at lint time.
Hardcoded strings — eslint-plugin-i18next, so the day you add a language nothing's baked into the markup.
Test hygiene — no-focused-tests as an error, so a stray it.only can't silently shrink the CI suite.
Leaked secrets — eslint-plugin-no-secrets flags high-entropy literals that look like committed tokens.
Design drift (custom) — a ~40-line AST script that fails the build when a raw hex/size/shadow shows up where a named token should be.
Layer boundaries — eslint-plugin-boundaries to stop one layer importing another, plus a custom rule forcing risky mutations through a single function.

Each of these is a lesson we only had to learn once.

After that, the linter remembers it for us. Forever, for free, on every commit, for every contributor — human or AI.

The trick that keeps the gate from being annoying

Most people give up on linting for one reason. They turn on every rule at error on day one, drown in ten thousand warnings, and rage-quit.

Don't do that.

Run new rules warn-first. Let them report without blocking. Get the count to zero on your own schedule. Then ratchet that rule up to error so it can never regress.

Here's the reframe that matters: those warnings aren't a to-do list you owe the linter today. They're a map of where the mines are buried. You freeze the count, stop anyone from planting new ones, and clear the field at your own pace.

For the handful of legacy offenders you can't fix today, keep an explicit allowlist. And treat adding to that allowlist as the thing you're not allowed to do.

The list only ever shrinks.

That's how a gate stays strict without crying wolf — and how you tame inherited code without it blowing up in your face.

Gotchas

A linter only sees what's static. Dynamic imports, string-built code, and values resolved at runtime are invisible to it. Know the blind spots. A green lint is not "provably correct."
--fix is not free thinking. Auto-fix is great for unused imports and formatting. It is not great at deciding whether a flagged thing was a real mistake. Read the diff.
Gate on the trend, not the absolute count. Failing CI because the repo has any warnings is untenable in a vibe-coded codebase. Fail when the count grows past the baseline. That's actionable. "Be perfect" isn't.
A rule you suppress everywhere is a rule you deleted. If every other line has a disable comment, you didn't pass the gate — you removed it. Fix the code or kill the rule honestly.

The mild jab

Here's the irony I can already see coming. You've read this whole piece on why bolting AI onto already-solved problems is wasteful — and your very next move is to open a chat window and type "add ESLint and all the plugins to my repo." Or worse: "build me a code-review agent that flags unused imports and circular deps."

Stop.

Both are the wrong move. The first one drops you into a rabbit hole of 1000+ errors you'll be digging out of forever. Start with the base recommendation, then slowly work toward the rest.

As for the code-review agent — I'll pretend I didn't hear that. We just spent this whole article on why a linter beats an AI reviewer here. So why are you still reaching for it? Look, if you hate your tokens that much — if you're really itching to spend them on a problem a free, decades-old tool already solves deterministically — just send them my way. I'll put them to better use.

AI is genuinely good at the fuzzy stuff — turning an idea into reality, that dopamine hit of making something from nothing. Let it do that. Leave the heavy judgement of code quality to linter.

And let me be honest about the other side: a linter won't fix your architecture, won't catch a wrong business rule, won't tell you the feature was a bad idea. That part is still on you. What it will do is take the boring, mechanical, never-ending category of mistakes off your plate — so your brain is free for the part that actually needs one.

Takeaway

A linter is the cheapest reviewer on your team. Free, deterministic, tireless, and completely unimpressed by hype.

Make it a hard gate on merge, and you raise the floor for everyone at once.

Then teach it your own recurring mistakes — token drift, hardcoded strings, circular deps, unsafe HTML, dropped awaits — one custom rule per bug class, warn-first then ratcheted to error.

Add the linter first.

Then, if you still want an agent, at least it's reviewing code that already cleared the bar.

The cheapest reviewer you'll ever hire has been sitting in your repo the whole time.

Frontend Is Not That Simple

Utkarsh Bansal — Thu, 21 May 2026 19:15:01 +0000

I guess most of you already have a pretty basic idea of what this post is about — Frontend Engineering.

Why frontend?
“We have AI now. It can create a website in a day. Why do you even care about frontend anymore? Post something about AI blah blah blah…”

I hear you.

But the real question is: Do you actually understand frontend?

Every day, I see product managers and designers trying their hands at AI — creating MVPs in a day and celebrating like, “We don’t need engineers anymore. We can do everything ourselves now.”

And honestly? That part is impressive.

But then that same code gets handed over to engineers for optimization, scalability, maintainability, performance, accessibility, security, deployment, and production readiness.

And that’s where my nightmare begins.

AI generates code based on patterns and existing code available online. It doesn’t magically create great architecture, scalability, performance, accessibility, or production-grade systems out of thin air.

The bigger problem starts when people continuously edit AI-generated code using more AI prompts without understanding the underlying structure.

At first, it works.

Then slowly:

functions start leaking across modules
components become tightly coupled
business logic spreads everywhere
state management becomes unpredictable
abstractions collapse
duplication increases
and eventually the entire codebase turns into spaghetti

A tangled mess held together by vibes, Stack Overflow answers, and “it works on my machine.”

Then comes the question:

“Why hasn’t the app that was created in a day scaled and deployed yet?”

So for the sake of my sanity, let me take you on a small journey into what real frontend engineering actually looks like.

And do note — this is just the tip of the iceberg. Once you go deeper, it becomes an abyss.

Frontend Engineering

As per product teams:
“Someone who creates beautiful websites using the design team’s instructions.”

As per textbooks:
“HTML, CSS, and JavaScript.”
HTML is the skeleton, CSS is the skin, and JavaScript is the brain.

As per me?
It’s much more than that.

Frontend Engineering
├── UI Development — What everyone sees
├── State Management — What no one sees until it breaks
├── Routing — Mostly ignored, but critical unless you enjoy navigation nightmares
├── Design Systems — Design tokens keep the UI consistent
├── API/Data Layer — Most production issues start here
├── Authentication — One of the biggest production concerns
├── Performance — In production, every millisecond matters
├── Accessibility — Most developers ignore this until they shouldn’t
├── SEO — Decides whether people even discover your product
├── Security — Skip this and enjoy your legal/security nightmare
├── Build Tooling — A massive game changer if you truly understand it
├── Testing — Protects both your product and your sleep
├── Monitoring — Users will always find bugs in ways you never expected
├── Analytics — So you can actually measure improvements instead of guessing
├── Deployment — Because shipping localhost to customers isn’t a strategy
├── CI/CD — Automating releases so deployments don’t become rituals
├── Internationalization — Your app eventually speaks more than one language
├── Offline/PWA — Because internet connections aren’t always reliable
├── Realtime Systems — Notifications, chats, collaboration, live updates
├── Architecture — The difference between scaling smoothly and suffering later
└── Developer Experience — Better DX = faster teams and fewer headaches

Now some people will say:
“Come on, this is an over-the-top explanation.”

And honestly?
They’re not completely wrong.

But it’s also true that all of these areas fall under frontend engineering in modern production systems.

Now the next question is:

“Do we really need all of this?”

Most of the time? Probably not.

Modern frameworks already provide many things out of the box.
For example, when you create a Vue project today, you already get tools like Vite, package managers like npm/pnpm/yarn, routing setups, build pipelines, and much more.

But if you want to build something truly great — something scalable, performant, maintainable, and production-ready — eventually you’ll have to understand these layers.

That’s where frontend engineering actually begins.

And if you’re wondering what the “abyss” looks like…

It looks something like this:

Frontend Engineering
├── Rendering Strategies (CSR, SSR, SSG, ISR, Streaming)
├── Hydration & Partial Hydration
├── Reactivity Systems & Virtual DOM internals
├── Compiler Architecture
├── Browser Rendering Pipeline
├── GPU Acceleration & Paint Optimization
├── Edge Computing
├── Caching Layers
├── WebSockets & CRDTs
├── Distributed State Synchronization
├── Micro Frontends
├── Monorepo Architecture
├── Design Token Pipelines
├── Runtime Performance Profiling
├── Web Security Hardening
├── Memory Leak Debugging
├── Service Workers
├── Rendering at Scale
├── Bundle Optimization
├── Build System Internals
├── Accessibility Compliance
├── Observability Engineering
├── Frontend Infrastructure
├── Server Components
├── WASM Integration
├── Compiler Toolchains
└── Browser Engine Edge Cases

And somewhere in between all this, you realize:

Frontend engineering was never just about making buttons look pretty.

Article 3 of 100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc

Utkarsh Bansal — Sun, 02 Mar 2025 14:39:22 +0000

Handling Git mistakes is a crucial skill for any developer. Recently, I found myself in a situation where a simple feature branch turned into a mess—too many commits, merge conflicts, and unclear history. Instead of starting over, I took the time to properly fix it.

Here’s what helped:
✔️ git reset — Undo unnecessary commits
✔️ git cherry-pick — Apply specific changes cleanly
✔️ git reflog — Recover lost commits
✔️ git stash — Save work without committing

Learning to manage Git efficiently makes PRs easier to review and keeps repositories clean.

If you’ve ever struggled with a tangled Git history, this article might help.

📖 Read more: https://medium.com/p/19c1f22e29ed

Day 3/100: The PR Crisis: GIT/GitHub Commits Cheat Sheet — A Developer’s Redemption Arc Start here: https://medium.com/p/19c1f22e29ed

Utkarsh Bansal — Sun, 02 Mar 2025 14:35:50 +0000

Day 2/100: ‘Wait, don’t we already have this function?’ — Publishing Your First NPM Package 📦

Utkarsh Bansal — Sat, 15 Feb 2025 17:23:41 +0000

Another project, another déjà vu moment.

I was about to copy-paste a helper function again when it hit me: “Didn’t I just use this in another repo?” Instead of repeating history, I finally did what I should’ve done long ago—packaged it up and published it to NPM.

Publishing an NPM package is easier than you think, and once you do it, you’ll wonder why you didn’t sooner. No more hunting through old repos, just clean, reusable code.

🛠️ Ready to publish yours? Start here: https://link.medium.com/h2mfQqqn0Qb

“Wait, don’t we already have this function” — Publishing Your First NPM Package | by Utkarsh Bansal | Feb, 2025 | Medium

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Day 1/100: Exploring Frontend Storage 🖥️

Utkarsh Bansal — Sat, 15 Feb 2025 17:17:05 +0000

Modern frontend development isn't just about UI—it’s about efficient data management. From cookies to IndexedDB, each storage option plays a crucial role in performance, security, and user experience.

This is my first article where I break down key data management, performance optimization, and security best practices — while addressing key security issues and sharing industry insights…

📖 Read: https://lnkd.in/g-A6H87H

DEV Community: Utkarsh Bansal

The 3-Second Rule of Web Performance — And How to Beat It

3 seconds.

Fast Isn't a Feeling. It's Measurable.

LCP, INP, CLS — What They Actually Measure

LCP — Largest Contentful Paint

INP — Interaction to Next Paint

CLS — Cumulative Layout Shift

All Three, In One Session

The Browser Has a Pipeline. Your Resources Keep Interrupting It.

Rule #1 — No DOM + CSSOM, no paint.

Rule #2 — Without defer or async, the parser waits.

One Exception That Trips Up Almost Everyone

Option 1 — Wait for the DOM.

Option 2 — Use modules (deferred automatically):

Then Why Does Everyone Still Teach "Put JavaScript at the Bottom"?

JavaScript Costs More Than You Think

Goal #1 — Ship Less JavaScript

Code Splitting — Ship Only What the User Needs

Tree Shaking — Remove What You Don't Use

Choose Smaller Libraries

Goal #2 — Keep the Main Thread Free

Long Tasks — Stop Freezing the Page

Web Workers — Move Heavy Work Off the Main Thread

Passive Listeners — One Word. Instant Win.

The JavaScript You Didn't Write

CSS Is Not Free Either

Animate Without Making the Browser Sweat

CSS Containment — Tell the Browser What Can't Change

Skip Rendering What Nobody Can See

Images Are Probably Your Biggest Problem

1. Choose the Right Format

2. Always Tell the Browser the Size

3. Don't Send a 4K Image to a Phone

4. Don't Download Images Nobody Can See

A Real Example — dev.to Is Already Doing This

Fonts Cost More Than You Think

The Network Is Not Your Friend — Until You Work With It

TTFB — The Delay Before Anything Happens

Gzip, Brotli and Zstd — Free Bandwidth

Preload, Prefetch, Preconnect — Know the Difference

Cache Everything That Doesn't Change

Back/Forward Cache — The Fastest Navigation You'll Ever Ship

One Move, Five Times

Framework Patterns That Actually Move the Needle

Stop Re-rendering What Didn't Change

v-if vs. v-show — Don't Default to One

Virtualization — The DOM Was Never Meant for 10,000 Rows

Perceived Performance — Making It Feel Fast Before It Is

Optimistic Updates — Respond Before the Server Does

Stale While Revalidate — Show Something Now

Prefetch Before the Click

Skeletons Beat Spinners

Lighthouse Is Where You Start. Field Data Is Where You Trust.

The Performance Budget — Make It Impossible to Regress

The Uncomfortable Part Nobody Puts in the Tutorial

The Checklist You'll Actually Use

The Takeaway

**What's the most over-engineered AI solution you've seen for a problem a linter already solves?** We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript - DEV Community

How ESLint Actually Works: The Quality Gate Behind Modern JavaScript

What Is ESLint Actually Doing?

Step 1: Your Code Stops Being Code

Step 2: Rules Walk The Tree

Why This Is More Powerful Than It Sounds

Category 1: Correctness

Category 2: Dead Code

Category 3: Security

Category 4: Performance

The Real Superpower: Quality Gates

Community Plugins Already Solved Half Your Problems

When The Defaults Aren't Enough: Write Your Own Rule

Where ESLint Fails

So Why Am I Still Talking About ESLint In The Age Of AI?

Takeaway

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

You Don't Need Another Agent. You Need a Linter. - DEV Community

You Don't Need Another Agent. You Need a Linter.

What a linter actually is

Why this matters more than it used to

Rule #2 — Without `defer` or `async`, the parser waits.

What's the most over-engineered AI solution you've seen for a problem a linter already solves? We added AI to write code. Then AI to review code. Then AI to verify code. The thing that actually reduced incidents? ESLint.

Utkarsh Bansal ・ Feb 15, 2025 ・
Medium

Utkarsh Bansal ・ Feb 14, 2025 ・
Medium