DEV Community: CodeScoop.dev

Authentication on the Frontend - More Than Just Tokens

Yogesh Yadav — Sun, 19 Apr 2026 14:12:36 +0000

The decisions behind auth are more consequential than most developers realize.

In this article we'll cover how token storage works and why the wrong choice creates real security vulnerabilities, how silent refresh keeps users logged in without interrupting their experience, how to handle session expiry gracefully, what actually happens during an OAuth flow, and the authentication decisions most frontend developers get wrong.

Authentication is one of those things that looks simple from the outside. User logs in, you get a token, you attach it to requests. Done.

Except it's not done. Not even close.

I've worked on platforms handling more than 10 million active users across multiple OTT applications. Authentication touches every single one of them. And the decisions you make at the frontend layer - where to store tokens, how to refresh them, how to handle expiry - have consequences that go well beyond a login form.

Get it wrong and you're looking at XSS vulnerabilities, session hijacking or users getting logged out mid-stream during a live event. At scale, any of those is a serious incident.

This article is about getting it right.

Token Storage - The Decision That Has the Most Security Consequences

When you authenticate a user and get back an access token, the first question is: where do you put it?

There are three common options. Each has real tradeoffs.

localStorage

This is the most common choice because it's the easiest. Persist the token, read it back on page load, attach it to requests. Simple.

The problem is XSS. If an attacker manages to inject malicious JavaScript into your page - through a compromised dependency, a third-party script or an unsanitized input - they can read everything in localStorage. Your token is gone. The attacker now has it.

// Any injected script can do this
const token = localStorage.getItem('access_token')
// Token is now in the attacker's hands

At scale, with multiple third-party scripts running on your platform, the XSS surface area is larger than you think.

httpOnly Cookies

The browser sets these cookies automatically on every request to your domain. JavaScript cannot read them. That means an XSS attack cannot steal them.

This sounds like the obvious winner, and for many server-rendered applications it is. But it comes with its own complexity. You need to think about CSRF protection, SameSite cookie attributes and cross-origin request handling. On a platform with multiple subdomains or a separate API domain, cookie configuration gets complicated quickly.

In-Memory Storage

This is the approach I consider most secure for single-page applications. Store the access token in a JavaScript variable, never in localStorage, never in a cookie readable by JavaScript.

let accessToken = null

export function setToken(token) {
  accessToken = token
}

export function getToken() {
  return accessToken
}

An XSS attack cannot read a JavaScript variable from another script's scope if you're careful about how you expose it. The token lives only in memory and disappears when the tab closes.

The tradeoff is that you lose persistence across page refreshes. Which is exactly why silent refresh exists.

Silent Refresh - Keeping Users Logged In Without Asking Them To

Access tokens are short-lived by design. Typically 15 minutes to an hour. That's intentional - if one gets stolen, the damage window is limited.

But you can't ask a user to log in again every hour. Especially on an OTT platform where they might be mid-stream during a live sports event.

Silent refresh solves this. The idea is straightforward: before the access token expires, use the refresh token to get a new one automatically, without any visible interruption to the user.

Here's the basic pattern:

let refreshTimeout = null

function scheduleTokenRefresh(expiresIn) {
  // Refresh 60 seconds before expiry
  const refreshIn = (expiresIn - 60) * 1000
  refreshTimeout = setTimeout(async () => {
    try {
      const newToken = await refreshAccessToken()
      setToken(newToken.accessToken)
      scheduleTokenRefresh(newToken.expiresIn)
    } catch (err) {
      // Refresh failed, session has expired
      handleSessionExpiry()
    }
  }, refreshIn)
}

A few things worth noting here:

The refresh token should be stored in an httpOnly cookie. It's longer-lived and more sensitive than the access token. You don't want JavaScript touching it directly. The server reads it from the cookie and issues a new access token.

Handle the case where the tab has been in the background. Browsers throttle timers in inactive tabs. When the user comes back to the tab, check if the token has already expired and refresh immediately if so.

Guard against multiple simultaneous refresh calls. On platforms with multiple concurrent API requests, several calls can fail at the same time when a token expires. Without a guard, you'll fire multiple refresh requests simultaneously.

let refreshPromise = null

async function refreshAccessToken() {
  if (refreshPromise) {
    return refreshPromise
  }
  refreshPromise = fetch('/auth/refresh', { method: 'POST' })
    .then(res => res.json())
    .finally(() => {
      refreshPromise = null
    })
  return refreshPromise
}

This ensures only one refresh request goes out regardless of how many callers triggered it.

Session Expiry - Handle It Like It's Part of the Product

Session expiry is inevitable. Refresh tokens expire. Users get logged out on other devices. Admins revoke access. Your job is to handle it in a way that doesn't feel broken.

The worst experience is a silent failure - the user clicks something, nothing happens, no explanation. Or worse, they get a raw 401 error in the UI.

A better approach has three parts:

Intercept 401 responses globally. Don't handle auth errors individually in every API call. Set up a single interceptor that catches 401s, attempts a token refresh, and retries the original request. If the refresh fails, then you handle expiry.

async function apiFetch(url, options) {
  let response = await fetch(url, {
    ...options,
    headers: {
      ...options?.headers,
      Authorization: `Bearer ${getToken()}`
    }
  })

if (response.status === 401) {
    try {
      const newToken = await refreshAccessToken()
      setToken(newToken.accessToken)
      // Retry original request with new token
      response = await fetch(url, {
        ...options,
        headers: {
          ...options?.headers,
          Authorization: `Bearer ${newToken.accessToken}`
        }
      })
    } catch {
      handleSessionExpiry()
    }
  }
  return response
}

Tell the user what happened. When the session genuinely expires, show a clear message. "Your session has expired, please log in again." Not a blank screen, not a generic error. A real explanation with a clear action.

Preserve their intent. Store the URL they were trying to access before redirecting to login. After they authenticate, bring them back to where they were. On a content platform this matters - a user who was about to watch something should land back on that content, not the homepage.

OAuth and Social Login - What Actually Happens in the Browser

Most developers use a library for OAuth and treat it as a black box. That's fine until something breaks and then you need to understand what's actually happening.

Here's the simplified flow for a third-party login:

User clicks "Login with Google."
Your app redirects the browser to Google's authorization endpoint with your client ID, requested scopes and a redirect URI.
Google authenticates the user and redirects back to your redirect URI with an authorization code.
Your frontend sends that code to your backend.
Your backend exchanges the code for tokens directly with Google using your client secret.
Your backend issues its own session token to your frontend.

A few things to pay attention to here:

Never exchange the authorization code on the frontend. The code exchange requires your client secret. That should never be in frontend code.

Use the state parameter. This is a random value you generate before the redirect and verify when the user comes back. It protects against CSRF attacks on the OAuth flow.

function initiateOAuthLogin() {
  const state = crypto.randomUUID()
  sessionStorage.setItem('oauth_state', state)

  const params = new URLSearchParams({
    client_id: CLIENT_ID,
    redirect_uri: REDIRECT_URI,
    response_type: 'code',
    scope: 'openid email profile',
    state
  })
  window.location.href = `https://accounts.google.com/o/oauth2/auth?${params}`
}

function handleOAuthCallback() {
  const params = new URLSearchParams(window.location.search)
  const returnedState = params.get('state')
  const savedState = sessionStorage.getItem('oauth_state')
  if (returnedState !== savedState) {
    throw new Error('OAuth state mismatch. Possible CSRF attack.')
  }
  // Safe to proceed
}

Use PKCE for public clients. If you're doing the token exchange from a mobile app or a pure SPA without a backend, PKCE (Proof Key for Code Exchange) replaces the client secret with a cryptographic challenge. It's the current best practice for frontend-only OAuth flows.

The Security Decisions Most Developers Get Wrong

Storing sensitive tokens in localStorage. Covered above, but worth repeating. The convenience is not worth the XSS exposure.

Not setting token expiry short enough. Access tokens should be short-lived. If yours are valid for 24 hours, a stolen token gives an attacker a 24-hour window. Keep them short and lean on silent refresh.

Trusting the frontend for authorization. Hiding a button in the UI is not authorization. The API must enforce access control. Frontend checks are for user experience only, never for security.

Not handling token refresh race conditions. Already covered with the single refresh promise pattern. This one causes subtle bugs that are hard to reproduce and harder to debug in production.

Logging out only on the current device. When a user logs out or changes their password, invalidate their refresh tokens on the server. Otherwise they're still effectively logged in on every other device they've used.

Sending tokens in URL parameters. Tokens in URLs end up in browser history, server logs, and referrer headers. Always send them in the Authorization header or a cookie. Never in the URL.

Final Thoughts

Authentication on the frontend is not just a login form and a token in localStorage. It's a set of decisions that affect the security, reliability, and user experience of your entire platform.

Get the storage right. Build silent refresh properly. Handle expiry gracefully. Understand the OAuth flow well enough to debug it when it breaks.

The developers who handle auth well aren't the ones who memorized every OAuth RFC. They're the ones who understood the tradeoffs and made deliberate decisions at each step.

At scale, deliberate decisions are the only kind that hold up.

Have thoughts or questions on frontend authentication? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Frontend Performance That Actually Moves the Needle

Yogesh Yadav — Thu, 16 Apr 2026 20:01:05 +0000

In this article we'll cover why Lighthouse scores alone don't tell the full story, what metrics actually matter at scale, how real user monitoring changes the way you think about performance, and the optimizations that have the most impact on platforms serving millions of users.

Lighthouse is a great tool. I'm not here to tell you to ignore it. But I've seen teams chase a perfect Lighthouse score while their real users were experiencing 4-second load times on mid-range android devices with a 4G connection.

The score looked great. The experience wasn't.

When you're building for 10 million users, performance stops being about a number in a report. It becomes about real people on real devices with real network conditions. And the gap between a lab score and what your users actually feel is wider than most developers realize.

This article is about closing that gap.

Lighthouse Scores Are Lab Data, Not Reality

Lighthouse runs in a controlled environment. Throttled CPU, simulated network, a clean browser with no extensions, no cached data, no background tabs. That's not how your users browse.

Your users are on a 3-year-old phone with 15 browser tabs open, on a train with patchy network, while your JavaScript is fighting with a background app for CPU time.

This is why a 90+ Lighthouse score can still result in a poor user experience. The lab doesn't lie, but it only tells you part of the truth.

Lab data: what Lighthouse gives you - is useful for catching regressions and tracking trends over time. But it should never be your only signal.

Field data: what your real users experience - is where performance work actually pays off.

The Metrics That Actually Matter at Scale

Core Web Vitals

Google's Core Web Vitals are the closest thing we have to a standardized set of user-centric performance metrics. Three of them matter most:

LCP - Largest Contentful Paint: How long does it take for the largest visible element to render? For most platforms this is a hero image, a video thumbnail or a headline. This is what the user perceives as "the page loaded."

Target: under 2.5 seconds.

INP - Interaction to Next Paint: How quickly does the page respond after a user interaction? Click a button, tap a menu, submit a form - how long before the page visually responds? This replaced FID (First Input Delay) in 2024 and is a much better measure of real interactivity.

Target: under 200 milliseconds.

CLS - Cumulative Layout Shift How much does the page jump around while loading? Ads loading late, images without dimensions, fonts swapping - these all contribute to CLS. On a content-heavy platform this can quietly destroy the user experience.

Target: under 0.1.

These three metrics directly impact SEO ranking and user retention. At scale, a 0.1 improvement in CLS or a 500ms reduction in LCP translates to measurable engagement and conversion improvements.

TTFB - Time to First Byte

Before the browser can render anything, it needs a response from the server. TTFB measures that wait time. High TTFB usually points to server-side issues - slow API responses, no CDN or unoptimized server rendering.

On platforms with a global audience, CDN configuration alone can cut TTFB from 800ms to under 100ms for a significant portion of your users.

TTI - Time to Interactive

When can the user actually use the page? Not just see it, but interact with it without the UI freezing. This is where JavaScript bundle size and execution time have the most direct impact.

A page that looks loaded but isn't responding to clicks is one of the most frustrating experiences a user can have.

Real User Monitoring - The Signal You Can't Ignore

If you're only running Lighthouse, you're flying partially blind. Real User Monitoring (RUM) captures performance data from actual user sessions and sends it back to you.

The difference is significant. With RUM you can see:

How performance varies by device type, browser and geography
Which pages have the worst real-world LCP or INP
How performance degrades over time as your codebase grows
What percentage of your users are experiencing poor performance right now

Tools like Datadog RUM, SpeedCurve, Mux Data or even the free Chrome User Experience Report (CrUX) give you this visibility.

On a platform serving millions of users, even if 5% of your users are experiencing poor performance, that's 500,000 people having a bad time. RUM makes that visible. Lighthouse doesn't.

The Optimizations That Actually Move the Needle

1. JavaScript Bundle Size

This is almost always the biggest lever. JavaScript is the most expensive resource on the web - it has to be downloaded, parsed, and executed before it does anything useful.

Code splitting is non-negotiable at scale. Every route should load only the JavaScript it needs.

// Instead of importing everything upfront
import HeavyComponent from './HeavyComponent'

// Load it only when needed
const HeavyComponent = React.lazy(() => import('./HeavyComponent'))

Audit your bundle regularly. Tools like webpack-bundle-analyzer or vite-bundle-visualizer will show you exactly what's in your bundle and where the weight is coming from. You will almost always find something surprising.

Third-party scripts are usually the worst offenders. Analytics, chat widgets, ad scripts - these are often loaded synchronously and block rendering. Load them async or defer them entirely until after the page is interactive.

2. Image Optimization

Images are the largest assets on most pages. Getting this wrong has a direct impact on LCP.

Use modern formats. WebP is widely supported and significantly smaller than JPEG or PNG. AVIF is even better where supported.
Always set explicit width and height on images. This prevents layout shift and helps the browser allocate space before the image loads.
Use lazy loading for images below the fold.
Serve appropriately sized images. Don't serve a 2000px wide image to a 400px wide mobile screen.

<img
  src="thumbnail.webp"
  width="400"
  height="225"
  loading="lazy"
  alt="Video thumbnail"
/>

For a platform with a large content library, image optimization alone can reduce page weight by 40–60%.

3. Critical Rendering Path

The browser has to download your HTML, parse it, discover CSS and JavaScript, download those, parse them and then render the page. Every step in that chain is an opportunity to either speed things up or slow things down.

Inline critical CSS - the styles needed to render above-the-fold content - directly in the HTML. This eliminates a render-blocking network request for the initial view.
Preload key resources the browser won't discover until late in the parsing process.

<link rel="preload" as="font" href="/fonts/main.woff2" crossorigin>
<link rel="preload" as="image" href="/hero.webp">

Defer non-critical JavaScript. If a script doesn't need to run before the page is interactive, it shouldn't block rendering.

4. Caching Strategy

I covered this in depth in the previous article in this series, but it's worth mentioning here because caching is one of the highest-impact performance optimizations available to you.

Repeat visitors on a well-cached platform can load pages almost entirely from cache. No network requests for static assets, no server round trips for unchanged resources. The performance improvement for returning users is dramatic.

If you haven't read the caching article yet, it's worth going back to.

5. Reducing Main Thread Work

INP and TTI both suffer when the main thread is busy. JavaScript execution, long tasks, layout recalculations - these all compete for the same thread that handles user interactions.

A few things that help:

Break up long tasks. Any task that takes more than 50ms can cause noticeable jank. Use setTimeout or scheduler.postTask to yield control back to the browser between chunks of work.
Avoid layout thrashing. Reading and writing to the DOM in alternating calls forces the browser to recalculate layout repeatedly. Batch your reads and writes.
Move heavy computation off the main thread with Web Workers.

// Yielding to the browser between heavy tasks
async function processLargeDataset(items) {
  for (let i = 0; i < items.length; i++) {
    process(items[i])
    if (i % 100 === 0) {
      await new Promise(resolve => setTimeout(resolve, 0))
    }
  }
}

Performance Budgets - Making It Stick

One of the hardest parts of performance work at scale is keeping improvements from regressing over time. A performance budget solves this.

A performance budget sets explicit limits on metrics like bundle size, LCP or TTI. If a pull request would push you over the budget, it fails the build.

{
  "resourceSizes": [
    { "resourceType": "script", "budget": 300 },
    { "resourceType": "total", "budget": 1000 }
  ],
  "timings": [
    { "metric": "first-contentful-paint", "budget": 1500 },
    { "metric": "interactive", "budget": 3500 }
  ]
}

This keeps performance on everyone's radar, not just the engineer who cared enough to optimize it once.

What Scale Actually Teaches You About Performance

Here's what I've learned from working on platforms at this size that you don't find in most performance guides:

Device distribution matters more than you think. Your development machine is not representative of your users. Profile on a mid-range Android device and you will find issues you never knew existed.

Geography matters. A platform with a global audience needs a CDN strategy, not just a fast server in one region. Network latency from a distant origin server can add seconds to TTFB for users in certain regions.

Performance degrades gradually. Nobody ships a slow app intentionally. It gets slow one dependency, one feature, one third-party script at a time. Without a budget and regular monitoring, you won't notice until users are already complaining.

The 80/20 rule applies. A small number of pages usually account for the majority of your traffic. Find those pages, measure them obsessively and optimize them first. That's where your performance work will have the most impact.

Final Thoughts

Lighthouse is a tool, not a goal. A green score means you've done the basics right. It doesn't mean your users are having a fast experience.

The teams that get performance right at scale are the ones who measure what their real users experience, set budgets to prevent regression and focus their effort on the optimizations that actually move the needle for their specific platform and audience.

Start with RUM. Find where your real users are struggling. Fix those things first.

The Lighthouse score will follow.

Have thoughts or questions on frontend performance? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Frontend Caching Done Right

Yogesh Yadav — Sun, 05 Apr 2026 06:39:19 +0000

In this article we’ll cover how the browser cache and HTTP headers work, when and how to use stale-while-revalidate, how service workers give you programmatic control over caching, what you should never cache, and how cache invalidation works in practice. All of it from the perspective of building for platforms that can’t afford to get this wrong.

Caching is one of those topics that every frontend developer thinks they understand, until they’re staring at a production issue where users are getting stale data, or worse, the server is getting hammered because nothing is being cached at all.

I’ve worked on platforms handling more than 10 million active users. And I can tell you, caching stops being a “nice to have” the moment your scale starts growing. It becomes the difference between a platform that feels fast and one that quietly falls apart under load.

This article is everything I’ve learned about frontend caching, written the way I wish someone had explained it to me early in my career.

First, Understand What You Are Actually Caching

Before you touch a single HTTP header or write a line of service worker code, ask yourself one question.

What is the cost of serving stale data here?

That question determines everything. Because caching is always a tradeoff between freshness and performance. The mistake most developers make is treating all resources the same way. They’re not.

Here’s how I think about it:

Static assets (JS bundles, CSS, fonts, images) - these can be cached aggressively, sometimes forever, if you version them correctly.
API responses - depends entirely on how often the data changes and how much it matters if the user sees something slightly outdated.
HTML documents - usually should not be cached aggressively, especially for authenticated apps.
User-specific data - almost never cache this without thinking carefully.

Get this mental model right first. Everything else follows from it.

Browser Cache and HTTP Headers

The browser cache is your first and most powerful caching layer. It lives between the user and your server, and it’s controlled entirely through HTTP response headers.

Cache-Control

This is the header you’ll use the most. Here’s what the key directives actually mean:

Cache-Control: max-age=31536000, immutablety

max-age tells the browser how many seconds to keep this resource before considering it stale. immutable tells the browser not to bother revalidating it even on a hard refresh, because the content will never change.

Use this combination for versioned static assets, your JS bundles, CSS files, and images that have a content hash in the filename. Something like main.a3f9c2.js. The hash changes every build, so the URL changes, so you never serve stale code. Cache it forever.

Cache-Control: no-cache

Despite the name, this does not mean “don’t cache.” It means “cache it, but check with the server every time before using it.” The server can respond with a 304 Not Modified and the browser uses the cached version. No full download needed.

Use this for your HTML documents. You want the browser to always check if there’s a new version, but still benefit from caching when nothing has changed.

Cache-Control: no-store

This actually means “don’t cache.” Nothing is stored anywhere. Use this for sensitive data, authentication responses, anything you never want sitting in a cache.

ETag and Last-Modified

These work alongside Cache-Control for revalidation. When the browser asks "has this changed?", the server uses these to answer.

ETag: "abc123"
Last-Modified: Mon, 01 Jan 2024 00:00:00 GMT

The browser sends back If-None-Match: "abc123" or If-Modified-Since on the next request. If nothing changed, the server returns 304 and saves the bandwidth of sending the full response again.

At scale, these small savings add up to a significant reduction in server load.

Stale-While-Revalidate

This is one of the most underused caching strategies I’ve seen in frontend codebases, and it’s genuinely powerful.

Cache-Control: max-age=60, stale-while-revalidate=300

Here’s what this does. For the first 60 seconds, serve from cache, no questions asked. Between 60 and 300 seconds, serve the stale cached version immediately, but kick off a background request to revalidate it. After 300 seconds, it’s stale and must be revalidated before serving.

The user gets an instant response. The cache gets updated in the background. No loading spinner, no waiting.

This pattern is perfect for data that changes occasionally but doesn’t need to be real-time. Think navigation menus, configuration data, content that updates a few times a day. The user always gets a fast experience and the data stays reasonably fresh.

You’ll also recognize this pattern from TanStack Query’s staleTime and gcTime configuration. The underlying idea is exactly the same, just applied at the JavaScript layer instead of the HTTP layer.

Service Workers - The Programmable Cache

HTTP headers give you declarative control over caching. Service workers give you programmatic control. That’s a significant difference.

A service worker sits between your app and the network, intercepting every request. You decide what happens with each one.

self.addEventListener('fetch', (event) => {
  event.respondWith(
    caches.match(event.request).then((cachedResponse) => {
      if (cachedResponse) {
        return cachedResponse
      }
      return fetch(event.request)
    })
  )
})

This is a simple cache-first strategy. Check the cache first, fall back to the network if nothing is found. For a platform serving millions of users, this means repeat visitors often never hit your server for static assets at all.

Caching Strategies with Service Workers

Cache First - Serve from cache, fall back to network. Best for static assets that rarely change.

Network First - Try the network, fall back to cache if offline. Best for API data where freshness matters but offline support is needed.

Stale While Revalidate - Serve from cache immediately, update cache in background. Best for non-critical content where speed matters more than freshness.

Cache Only - Only serve from cache. Useful for assets you’ve pre-cached during install.

Network Only - Always go to network. For requests that should never be cached, like analytics or payment endpoints.

Pick your strategy per resource type, not globally. A single strategy for everything is almost always the wrong call.

Pre-caching vs Runtime Caching

Pre-caching happens when the service worker installs. You explicitly list assets to cache upfront.

self.addEventListener('install', (event) => {
  event.waitUntil(
    caches.open('v1').then((cache) => {
      return cache.addAll([
        '/',
        '/styles/main.css',
        '/scripts/main.js',
      ])
    })
  )
})

Runtime caching happens dynamically as requests come in. You cache responses as they’re fetched, so frequently accessed resources end up in cache naturally over time.

For most platforms, you want both. Pre-cache your critical shell, runtime cache everything else.

What Not to Cache

This is the part that trips people up. Caching the wrong things causes bugs that are genuinely hard to debug in production.

Never aggressively cache:

Authentication tokens or session data
Payment and transaction endpoints
User-specific personalization data
Anything that changes per user or per session
A/B test configurations if they need to be real-time

I’ve seen teams cache API responses that included user-specific entitlements. The result was users seeing content they shouldn’t have access to, or not seeing content they’d just purchased. At scale, that’s not just a bug. It’s a trust problem.

When in doubt, don’t cache it, or use no-cache so at least revalidation happens.

Cache Invalidation - The Hard Part

There’s a famous saying in computer science: there are only two hard things, naming things and cache invalidation.

It’s funny because it’s true.

For static assets, content-hashed filenames solve this completely. New deploy, new hash, new URL, new cache entry. Old one expires naturally.

For API responses and service worker caches, you need a versioning strategy.

const CACHE_VERSION = 'v2'

self.addEventListener('activate', (event) => {
  event.waitUntil(
    caches.keys().then((cacheNames) => {
      return Promise.all(
        cacheNames
          .filter((name) => name !== CACHE_VERSION)
          .map((name) => caches.delete(name))
      )
    })
  )
})

Every time you deploy, bump the cache version. The activate event cleans up old caches. Users get fresh data on their next visit without you having to manually purge anything.

Caching at Scale - What Actually Changes

When you’re building for 10 million users, the fundamentals don’t change. But the consequences of getting it wrong are amplified significantly.

A few things I’ve learned from operating at that scale:

Measure before you optimize. Use Chrome DevTools, Lighthouse, and your RUM (Real User Monitoring) data to understand where your actual cache hit rates are. Don’t guess.

CDN caching and browser caching are different layers. Your CDN has its own cache headers, often separate from what the browser sees. Understand both. Misconfiguring your CDN can mean millions of users bypassing the browser cache entirely.

Cache stampedes are real. When a popular cached resource expires simultaneously for millions of users, they all hit your server at once. Stale-while-revalidate and jittered expiry times help prevent this.

Monitor your cache hit ratio. If it’s low, you’re leaving performance on the table. If it’s too high and you’re seeing stale data complaints, your TTLs are too aggressive.

Final Thoughts

Caching is not a set-it-and-forget-it feature. It’s an ongoing engineering decision that touches performance, correctness and user experience all at once.

Start with HTTP headers and get those right. Layer in stale-while-revalidate for the right resources. Add service workers when you need offline support or more granular control. And always think about invalidation before you think about caching.

The developers who get this right aren’t the ones who know the most cache directives. They’re the ones who ask the right question first.

What is the cost of serving stale data here?

Answer that honestly for every resource, and the rest follows.

Have thoughts or questions on frontend caching? Drop them in the comments, always happy to discuss.

This article is part of the Frontend at Scale series.

Explore the lexical Environment & Environment Record in Javascript 2021

Yogesh Yadav — Wed, 17 Aug 2022 07:23:00 +0000

Let's first understand the Lexical Environment & Environment Record as per different versions of ECMAScript Specification.

From ES2015 till ES2020 Specification:-

Lexical Environment:

A lexical environment is a specification type used to define the association of Identifiers to specific variables and functions, based upon the lexical nesting structure of your code.
A lexical environment consists of two components:
1. Environment Record
  It records the identifier bindings that are created within the scope of its associated Lexical Environment. It is referred to as the Lexical Environment's EnvironmentRecord.
2. Outer Reference
  A reference to outer environment (null in the global environment).

A conceptual view using pseudo-code:

executioncontext.environment = {
    environmentRecord: { 
    // storage
    <identifier> : <value>
    <identifier> : <value>
    }
    // reference to the parent environment
    outer: <...>    
}

Note: - The [[Environment]] created inside Execution Context is of type Lexical Environment
[refer ES2020]

According to 12th Edition ECMAScript2021 Specification:

Environment Record

A Environment Record is a specification type used to define the association of Identifiers to specific variables and functions, based upon the lexical nesting structure of your code.
Every Environment Record has one component:
1. Outer Reference
  An [[OuterEnv]] field, which is either null or a reference to an outer Environment Record. A conceptual view using pseudo-code:

executioncontext.environment = {
    // storage
    <identifier> : <value>,
    <identifier> : <value>,
    // reference to the parent environment
    outer: <...> 
}

Note: - The [[Environment]] created inside Execution Context is of type Environment Record [refer ES2021]

Let's also understand the Structure of execution context

Execution Context:

An execution context is a specification device that is used to track the runtime evaluation of the code.
To keeps the track of execution progress of its associated code, it needs various state components like LexicalEnvironment, VariableEnvironment, etc.

In pseudo-code:

ExecutionContext = {
    VariableEnvironment: { ... },
    LexicalEnvironment: { ... },
    // other components
}

Note:

Till ES2020	From ES2021
- The `LexicalEnvironment component` and `VariableEnvironment component` of an execution context are always Lexical Environments [refer ES2020]	- The `LexicalEnvironment component` and `VariableEnvironment` components of an execution context are always Environment Records [refer ES2021]

Summary

Let's have a quick recap of all the steps we perform in the above code snippet.

In ECMAScript2021, the [[environment]] which is created inside the execution context is of type Environment Record instead of Lexical Environment.
So, The LexicalEnvironment component and VariableEnvironment components of an execution context are always Environment Records.

Wrap Up!!

Thank you for your time!! Let's connect to learn and grow together.
Github Twitter

DEV Community: CodeScoop.dev

Authentication on the Frontend - More Than Just Tokens

Token Storage - The Decision That Has the Most Security Consequences

localStorage

httpOnly Cookies

In-Memory Storage

Silent Refresh - Keeping Users Logged In Without Asking Them To

Session Expiry - Handle It Like It's Part of the Product

OAuth and Social Login - What Actually Happens in the Browser

The Security Decisions Most Developers Get Wrong

Final Thoughts

Frontend Performance That Actually Moves the Needle

Lighthouse Scores Are Lab Data, Not Reality

The Metrics That Actually Matter at Scale

Core Web Vitals

TTFB - Time to First Byte

TTI - Time to Interactive

Real User Monitoring - The Signal You Can't Ignore

The Optimizations That Actually Move the Needle

1. JavaScript Bundle Size

2. Image Optimization

3. Critical Rendering Path

4. Caching Strategy

5. Reducing Main Thread Work

Performance Budgets - Making It Stick

What Scale Actually Teaches You About Performance

Final Thoughts

Frontend Caching Done Right

First, Understand What You Are Actually Caching

What is the cost of serving stale data here?

Browser Cache and HTTP Headers

Cache-Control

ETag and Last-Modified

Stale-While-Revalidate

Service Workers - The Programmable Cache

Caching Strategies with Service Workers

Pre-caching vs Runtime Caching

What Not to Cache

Cache Invalidation - The Hard Part

Caching at Scale - What Actually Changes

Final Thoughts

Explore the lexical Environment & Environment Record in Javascript 2021

Lexical Environment:

Environment Record

Outer Reference

Environment Record

Outer Reference

Execution Context:

Summary

Wrap Up!!