Forem: Yogesh Yadav

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.

Writing SDKs That Don’t Make Other Developers Hate You

Yogesh Yadav — Sun, 22 Mar 2026 18:30:00 +0000

Lessons from building and maintaining an NPM package that powers tier-0 OTT production apps across millions of users.

When I started building a frontend SDK, one that would eventually be consumed across a fleet of tier-0 OTT production applications, collectively handling more than 10 million active users, I quickly realized something uncomfortable.

The hardest part wasn’t the code. It was every decision around the code.

How you name a method. What you return when something goes wrong. Whether you force consumers to configure something they shouldn’t have to think about. These are the things that either make a developer’s day easier, or quietly ruin it at 2am during a production incident.

This article is everything I wish I’d known before shipping that first version.

1. Your API Surface Is a Promise

The moment another team installs your package and writes import { authenticate } from '@your-org/sdk', you've made a promise. That method name, its parameters, its return shape are now load-bearing walls in someone else's application.

Keep the surface small. Export only what needs to be public. Every extra export is a contract you now have to honour forever, or break with a major version bump.

// ❌ Exporting internal utilities "just in case"
export { tokenParser, refreshQueue, buildAuthHeader }

// ✅ Only expose what consumers actually need
export { authenticate, logout, getUser }

If an internal utility leaks into the public API and someone starts depending on it, you can’t quietly remove it. You’ve created a hidden contract.

Name things from the consumer’s perspective, not yours. You know how the internals work. They don’t, and they shouldn’t have to.

2. Sensible Defaults Are an Act of Respect

Every required config option you add is a question your SDK is asking the consumer to answer. Sometimes that’s necessary. Most of the time, it isn’t.

Ask yourself for every config field: does the developer actually know what to set here, and does it vary meaningfully across use cases?

// ❌ Forcing the consumer to configure things they shouldn't care about
const sdk = new AuthSDK({
  tokenStorageStrategy: 'memory',
  refreshBuffer: 60,
  retryAttempts: 3,
  cookieSameSite: 'Lax'
})

// ✅ Sane defaults. Override only when needed.
const sdk = new AuthSDK({
  clientId: 'your-client-id'
})

The defaults should represent the most secure, most correct behaviour out of the box. The consumer shouldn’t have to research best practices just to get started safely.

In our Authentication SDK, access tokens are stored in memory by default, not localStorage, not sessionStorage. That’s the right call for XSS resistance. A developer shouldn’t have to know about XSS attack surfaces to benefit from that decision. They just get it.

3. Error Messages Are Documentation

When something goes wrong in your SDK, you have a few seconds of the developer’s attention. Use them.

// ❌ An error that tells you nothing useful
throw new Error('Auth failed')

// ✅ An error that tells you what happened, why, and what to check
throw new Error(
  '[AuthSDK] Token refresh failed: the refresh token has expired or is invalid. ' +
  'This usually happens after a long inactive session. Call sdk.login() to re-authenticate.'
)

A few things that make error messages genuinely useful:

Prefix with your SDK name: when this surfaces in a Sentry report, developers know immediately where to look.
Explain the why, not just the what: “invalid token” is useless; “token expired after 24 hours of inactivity” is actionable.
Suggest a fix: if there’s a clear resolution path, just say it.

For errors that consumers are expected to handle, create typed error classes:

export class TokenExpiredError extends Error {
  constructor() {
    super('[AuthSDK] Access token has expired. Call sdk.refreshToken() or sdk.login().')
    this.name = 'TokenExpiredError'
  }
}

export class NetworkError extends Error {
  constructor(public statusCode: number) {
    super(`[AuthSDK] Network request failed with status ${statusCode}.`)
    this.name = 'NetworkError'
  }
}

Now the consumer can do this cleanly:

try {
  await sdk.getUser()
} catch (err) {
  if (err instanceof TokenExpiredError) {
    await sdk.login()
  }
}

4. TypeScript Types Are the First Layer of Documentation

Your types aren’t just for type safety. They are the first thing a developer reads about your SDK, before they open a single doc page.

If your types are vague, your SDK feels unreliable.

// ❌ Vague types that tell the consumer nothing
function authenticate(config: object): Promise<any>

// ✅ Types that tell the full story at a glance
interface AuthConfig {
  clientId: string
  /** Defaults to 'memory'. Use 'cookie' only for SSR environments. */
  tokenStorage?: 'memory' | 'cookie'
  /** Called automatically when access token expires */
  onTokenRefresh?: (newToken: string) => void
}

interface AuthResult {
  user: User
  accessToken: string
  expiresAt: number // Unix timestamp
}

function authenticate(config: AuthConfig): Promise<AuthResult>

Notice the JSDoc comments inside the interface. That’s the next point.

5. Documentation-as-Code: Write It Where Developers Actually Read It

Developers don’t always open the docs site. They hover over a function in VS Code and read the tooltip. That’s your real documentation surface.

Write JSDoc comments directly in your type definitions and function signatures:

/**
 * Authenticates the user and stores the session.
 *
 * @param config - Authentication configuration
 * @returns Resolved with the authenticated user and token details
 *
 * @throws {TokenExpiredError} If the existing session has expired
 * @throws {NetworkError} If the auth endpoint is unreachable
 *
 * @example
 * const { user } = await sdk.authenticate({ clientId: 'abc123' })
 * console.log(user.email)
 */
function authenticate(config: AuthConfig): Promise<AuthResult>

The @example block is particularly valuable. When a developer is evaluating whether your SDK does what they need, a concrete working example in the tooltip closes that question in 5 seconds.

6. Versioning Is a Communication Tool

A version number carries meaning. When you bump it, you’re telling your consumers something.

Patch (1.0.x): bug fix, nothing changes for them
Minor (1.x.0): new capability, fully backwards compatible
Major (x.0.0): something they depend on changed, they need to act

When we had a breaking change in our authentication flow, we did three things:

Bumped the major version
Added a clear migration guide in the CHANGELOG
Kept the old method working for one minor version, with a console warning pointing to the new one

/** @deprecated Use sdk.login() instead. Will be removed in v4.0. */
function authenticate() {
  console.warn('[AuthSDK] authenticate() is deprecated. Use login() instead.')
  return login()
}

Deprecation warnings are a courtesy your consumers will remember.

7. What Changes in Your SDK Can Break Production - Know That Weight

When your package is used across tier-0 applications serving millions of users, a broken release isn’t just embarrassing. It’s a real incident. Here’s what that forces you to discipline:

Never release without testing in a consumer app. Snapshot tests in your own repo aren’t enough. Use a real integration.
Lock peer dependencies carefully. If your SDK assumes React 17 but the consumer has 18, that mismatch will surface at the worst possible time.
Changelogs are not optional. Every release should have one, even patch bumps. Consumers need to know what changed.
Don’t put secrets or environment-specific logic in the SDK core. Config should come from the consumer. Your SDK should be environment-agnostic.

Final Thoughts

The best SDK is one that feels obvious. Where a developer can sit down with it for the first time and get something working without reading a single doc page, because the API told them what to do, the defaults were sensible, and the error message told them what they got wrong.

That’s a hard bar to hit. But every time you name a method from the consumer’s perspective, write a JSDoc example, or turn a cryptic error into a useful one, you get closer.

The developers consuming your SDK are trusting you with their production apps. That trust is worth protecting.

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

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

Forem: Yogesh Yadav

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

Writing SDKs That Don’t Make Other Developers Hate You

1. Your API Surface Is a Promise

2. Sensible Defaults Are an Act of Respect

3. Error Messages Are Documentation

4. TypeScript Types Are the First Layer of Documentation

5. Documentation-as-Code: Write It Where Developers Actually Read It

6. Versioning Is a Communication Tool

7. What Changes in Your SDK Can Break Production - Know That Weight

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