Forem: Shubham Gupta

Things Nobody Tells You About Building Chrome Extensions

Shubham Gupta — Mon, 18 May 2026 19:01:37 +0000

When I started learning Chrome extension development, I thought it would be easy.

I already knew:

React
JavaScript
APIs
Node.js

So I assumed:
“Building a browser extension should take only a few hours.”

I was wrong. 😅

Chrome extensions work very differently from normal web applications.

You need to understand:

manifests,
permissions,
content scripts,
service workers,
browser security,
an extension architecture.

In this article, I’ll explain the things that confused me the most while building my first Chrome extension.

If you’re a beginner, this guide may save you many hours.

First, What Is a Chrome Extension?

A Chrome extension is a small application that runs inside the browser.

Extensions can:

modify webpages,
automate tasks,
save notes,
block ads,
use AI,
summarize content,
and much more.

Examples:

Grammarly
Honey
Dark Reader
Momentum

All of these are browser extensions.

The Most Important File: manifest.json

The first confusing thing in Chrome extension development is the manifest.json file.

Think of it like the brain of your extension.

This file tells Chrome:

your extension name,
version,
permissions,
scripts,
icons,
popup pages,
and features.

Without this file, your extension will not work.

Example:

{
  "manifest_version": 3,
  "name": "My First Extension",
  "version": "1.0",
  "action": {
    "default_popup": "popup.html"
  }
}

At first this looks simple.

But as your extension grows, this file becomes very important.

What Is Manifest Version 3?

Most old tutorials use Manifest V2.

But Chrome now uses Manifest V3 (MV3).

This changes many things.

The biggest change:
background scripts are replaced with service workers.

This means:

extensions do not stay active all the time,
Chrome stops them when inactive,
and they restart only when needed.

As a beginner, this confused me a lot because I expected my extension to behave like a normal application.

Understanding Extension Parts

A Chrome extension usually has 4 main parts.

1. Popup

This is the small UI that opens when users click the extension icon.

Usually built using:

HTML
CSS
JavaScript
React

Example:

Todo popup
AI assistant popup
Note-taking UI

2. Content Script

This script runs inside websites.

It can:

read webpage content,
modify the DOM,
inject buttons,
extract text.

Example:
A YouTube summarizer extension reads video titles and transcripts using content scripts.

This was one of the hardest concepts for me initially.

3. Background Service Worker

This handles background logic.

Examples:

listening for browser events,
handling API calls,
managing notifications.

But unlike normal apps:
it does not stay alive forever.

This behavior creates many beginner bugs.

4. Storage

Extensions can save data using Chrome storage APIs.

Example:

saved notes,
settings,
AI prompts,
authentication tokens.

Permissions Are Extremely Important

Extensions often ask for permissions like:

tabs
storage
activeTab
scripting

Example:

"permissions": ["storage", "activeTab"]

At first I added many permissions without thinking.

But I later realized:
too many permissions make users suspicious.

Good extensions request only what they truly need.

Debugging Chrome Extensions Is Weird

Debugging normal apps is simple.

Chrome extensions are different because each part has separate DevTools.

You may debug:

popup console,
content script console,
background worker console.

I wasted a lot of time checking the wrong console 😅

Content Scripts Are Isolated

One thing nobody explains properly:

Content scripts run inside webpages…
but they are still isolated from the page itself.

This means:
some variables are inaccessible,
and some scripts behave differently.

At first this feels very confusing.

Chrome Security Is Strict

Chrome blocks many unsafe operations.

For example:

inline JavaScript,
unsafe eval(),
random external scripts.

This security system is called CSP (Content Security Policy).

Many libraries that work in React apps may fail inside extensions because of CSP restrictions.

Performance Actually Matters

Bad extensions can slow down the browser.

Especially when:

scripts run on every page,
bundles are too large,
or too many listeners exist.

I learned quickly that optimization matters even for small extensions.

Publishing Is Another Challenge

After building your extension, you still need:

store listing,
screenshots,
icons,
privacy policy,
proper permissions explanation.

Chrome Web Store reviews can reject extensions for small issues.

Final Thoughts

Chrome extension development is much more interesting than I expected.

At first it feels confusing.

But while building extensions, you learn:

browser architecture,
security,
performance optimization,
event-driven systems,
and real product engineering.

If you’re a beginner:
don’t worry if things feel strange initially.

Everyone gets confused by:

manifests,
content scripts,
and service workers at first.

Start with a small project,
experiment a lot,
and keep debugging.

That’s honestly the best way to learn Chrome extensions 🚀

Performance Optimization in Modern Web Applications

Shubham Gupta — Thu, 14 May 2026 07:32:23 +0000

Performance optimization is no longer an optional improvement for web applications — it is a core requirement. Users expect applications to load instantly, respond smoothly, and work reliably across devices and network conditions. Even a one-second delay in load time can reduce conversions, engagement, and user satisfaction.

In modern full-stack development, performance optimization spans frontend rendering, backend efficiency, database queries, network communication, caching, and deployment infrastructure. This blog explores practical strategies developers can use to build faster and more scalable web applications.

Why Performance Matters

Performance directly affects:

User experience
SEO rankings
Conversion rates
Retention and engagement
Infrastructure cost
Scalability

A slow application increases bounce rates and frustrates users. Search engines also prioritize faster websites, making performance optimization critical for visibility.

Frontend Performance Optimization

1. Reduce Bundle Size

Large JavaScript bundles slow down page loads.

Best Practices

Use tree shaking
Remove unused dependencies
Split code dynamically
Compress assets using Brotli or Gzip
Prefer lightweight libraries

Example (React Lazy Loading)

import React, { Suspense, lazy } from 'react';

const Dashboard = lazy(() => import('./Dashboard'));

function App() {
  return (
    <Suspense fallback={<div>Loading...</div>}>
      <Dashboard />
    </Suspense>
  );
}

This loads components only when required.

2. Optimize Rendering

Unnecessary re-renders can degrade UI responsiveness.

Techniques

Use React.memo
Memoize callbacks with useCallback
Use useMemo for expensive calculations
Avoid deep component nesting
Virtualize large lists

Example

const ExpensiveComponent = React.memo(({ data }) => {
  return <div>{data}</div>;
});

3. Image Optimization

Images often account for the largest portion of page weight.

Recommendations

Use WebP or AVIF formats
Lazy-load offscreen images
Serve responsive image sizes
Use CDN image optimization

Example

<img loading="lazy" src="image.webp" alt="optimized image" />

4. Improve Core Web Vitals

Google Core Web Vitals measure real user experience.

Key metrics include:

Largest Contentful Paint (LCP)
First Input Delay (FID)
Cumulative Layout Shift (CLS)

Optimization Tips

Preload important assets
Avoid layout shifts
Minimize blocking JavaScript
Use font optimization

Backend Performance Optimization

1. Database Query Optimization

Poor database queries create major bottlenecks.

Best Practices

Add proper indexes
Avoid N+1 queries
Use pagination
Optimize joins
Cache frequent queries

Example (MongoDB Index)

db.users.createIndex({ email: 1 });

2. Implement Caching

Caching reduces server load and response times.

Types of Caching

Browser caching
CDN caching
API caching
Redis in-memory caching
Database query caching

Example (Node.js + Redis)

const cachedData = await redis.get('users');

if (cachedData) {
  return JSON.parse(cachedData);
}

3. API Optimization

Efficient APIs improve both frontend and backend performance.

Recommendations

Compress API responses
Use pagination
Return only required fields
Implement rate limiting
Use GraphQL selectively

Example

GET /users?page=1&limit=20

4. Asynchronous Processing

Heavy tasks should run in the background.

Examples

Email sending
Video processing
Report generation
Notification delivery

Tools

BullMQ
RabbitMQ
Kafka
AWS SQS

Network Optimization

1. Use a CDN

A Content Delivery Network serves assets from servers closer to users.

Benefits include:

Faster load times
Reduced latency
Better scalability
DDoS protection

Popular CDNs:

Cloudflare
AWS CloudFront
Akamai
Fastly

2. Enable Compression

Compression significantly reduces response sizes.

Example (Express.js)

const compression = require('compression');
app.use(compression());

3. Minimize HTTP Requests

Reduce the number of requests by:

Combining assets
Using SVG icons
Removing unused scripts
Lazy loading modules

Performance Monitoring

Optimization should be data-driven.

Important Monitoring Tools

Lighthouse
Chrome DevTools
WebPageTest
New Relic
Datadog
Grafana

Metrics to Track

Page load time
API response time
Memory usage
CPU utilization
Error rate
Time to interactive

Scalability and Infrastructure Optimization

1. Load Balancing

Distribute traffic across multiple servers.

Popular Load Balancers

NGINX
HAProxy
AWS ALB

2. Horizontal Scaling

Instead of increasing server size vertically, scale by adding more servers.

Benefits:

Better reliability
Improved fault tolerance
Higher availability

3. Containerization

Docker and Kubernetes help manage scalable applications efficiently.

Advantages

Faster deployments
Resource isolation
Better scalability
Consistent environments

Common Performance Mistakes

Avoid these frequent issues:

Over-fetching data
Unoptimized database queries
Large frontend bundles
Memory leaks
Blocking operations
Excessive re-renders
Lack of caching
Ignoring monitoring

Real-World Optimization Workflow

A practical optimization process usually follows these steps:

Measure current performance
Identify bottlenecks
Prioritize high-impact fixes
Implement optimizations
Test under load
Monitor continuously

Performance optimization is iterative, not a one-time task.

Conclusion

Modern web applications require performance-focused engineering at every layer of the stack. From frontend rendering and asset optimization to backend caching and infrastructure scaling, each improvement contributes to a smoother user experience.

The best-performing applications are not necessarily the ones with the most features, but the ones that deliver fast, reliable, and efficient experiences consistently.

By adopting performance optimization best practices early in development, teams can build scalable systems that remain responsive as traffic and complexity grow.

Final Thoughts

Performance is a competitive advantage. Users notice speed, responsiveness, and reliability immediately. Investing in optimization improves user satisfaction, SEO performance, and operational efficiency.

A fast application is not just technically better — it is better for business.

When a Simple Streaming Bug Turned Into a Deep Engineering Lesson

Shubham Gupta — Wed, 06 May 2026 18:52:35 +0000

Recently, I worked on a streaming-related issue that initially looked very small.

Users reported that some long-duration videos were buffering unexpectedly during playback.

The pattern was interesting:

Videos started normally
Playback worked fine initially
After some time, buffering increased
In certain cases, playback stopped completely

At first, we assumed it could be:

A frontend player issue
Network instability
Device-specific behavior

Because for most users, buffering simply feels like “slow internet".

But after deeper investigation, we realised the actual problem was much more complex.

Understanding the Real Issue

After testing multiple scenarios, we noticed the issue mostly happened with:

Long-duration videos
Specific streaming versions
Quality switches during playback

Initially, video segments were loading correctly.

However, during longer playback sessions:

Segment loading became inconsistent
Buffer handling was delayed
Retry requests increased
Some quality-switch requests were not synchronizing properly

This created buffering loops that affected the viewing experience.

The challenging part was that the issue was not consistently reproducible.

Some videos worked perfectly.
Some failed only after extended playback durations.

That made debugging significantly harder.

How We Investigated

To identify the root cause, we started validating the following:

Multiple video durations
Different encoded versions
Various network conditions
Adaptive bitrate switching
Long playback sessions

We monitored:

Segment request timing
Retry behavior
Streaming responses
Buffer health
Playback synchronization

After deeper analysis, we found that certain streaming versions were not handling segment transitions efficiently during long playback sessions.

The Fix

To improve playback stability, we optimised the following:

Streaming response handling
Segment loading flow
Retry handling logic
Playback synchronization between streaming versions
Buffer management behavior

We then validated the fixes using:

Long-duration videos
Multiple streaming qualities
Different playback environments
Extended playback testing sessions

The improvements were immediately visible:

Playback became smoother
Buffering reduced significantly
Long-session streaming stabilized
Overall streaming consistency improved

What This Experience Taught Me

Before working closely with streaming systems, I thought video playback was mostly frontend-driven.

Now I understand the real complexity exists in:

Infrastructure
Scalability
Delivery optimization
Media pipelines
Buffer management
Performance engineering

Streaming platforms are one of the most fascinating examples of large-scale engineering.

Users only see a simple “Play” button.

Behind that button, thousands of engineering decisions work together in milliseconds to create a smooth viewing experience.

Smooth playback is not magic.

It’s engineering. ⚙️

Streaming #BackendEngineering #VideoStreaming #OTT #SoftwareEngineering #NodeJS #SystemDesign #PerformanceEngineering

Designing a Universal Error Handler for Frontend & Backend (React + Node.js)

Shubham Gupta — Thu, 22 Jan 2026 18:27:28 +0000

Error handling is one of those things we all do — but rarely design properly.

In most projects, error handling grows organically:

a few try/catch blocks
some HTTP status checks
random error messages sent from the backend
UI logic guessing what went wrong Eventually, the system becomes fragile.

This article walks through how and why I designed a universal error-handling system that works across Backend (Node.js / Express / Next.js APIs) and Frontend (React / Next.js UI) — using a shared contract, not tight coupling.

The Real Problem with Error Handling

Most applications suffer from the same issues:

Backend problems

Errors from DB, validation, or external APIs look different
Internal stack traces leak to clients
Error responses change over time
Hard to debug production issues

Frontend problems

Every API returns a different error shape
UI shows technical or confusing messages
Error handling logic is duplicated everywhere
Runtime crashes cause white screens The core issue isn’t missing try/catch.

👉 The issue is lack of design.

The Key Insight: Errors Are a Contract

Instead of treating errors as exceptions, I started treating them as data.
That led to one fundamental idea:

Frontend and backend should share an error contract, not implementations.

This single decision shaped the entire system.

Design Principle #1: Shared Contract, Not Tight Coupling

The frontend and backend do not depend on each other’s code.
They only agree on:

error codes
error structure

Example error contract:

{
  "success": false,
  "message": "User already exists",
  "code": "DUPLICATE_ERROR",
  "details": {
    "field": "email"
  },
  "traceId": "abc-123"
}

This gives us:

consistency
backward compatibility
freedom to evolve each layer independently

Design Principle #2: Backend Decides What Happened

The backend is the source of truth.

Its responsibility is to:

detect what went wrong
categorize the error
attach structured metadata
assign a stable error code

It does not decide how the error is shown.

Internally, the backend normalizes:
database errors
validation failures
authentication & authorization errors
third-party API failures
system-level crashes

Everything becomes a single, predictable error object.

Design Principle #3: Frontend Decides How to Show It

The frontend owns user experience.

It receives structured error data and decides:

the message shown to users
localization (i18n)
UI presentation (toast, banner, modal)
retry or recovery behavior

This allows the same backend error to be shown differently in:

admin dashboards
consumer apps
mobile vs desktop UIs

Technical message ≠ UI message — and that’s intentional.

Design Principle #4: Progressive Adoption

This system is not all-or-nothing.

You can:

use only backend utilities
use only frontend hooks
use both together for best results

Even if the backend doesn’t follow the contract perfectly, the frontend falls back safely.

This makes the library practical for:

legacy systems
gradual refactors
monorepos with mixed stacks

Design Principle #5: Hooks-Only, Modern React

All frontend APIs are built with hooks:

no class components
no outdated patterns

Some examples:

useAPIError() – handle API & network errors
useAsyncData() – async operations with built-in error state
useGlobalError() – app-wide error state
useNetworkStatus() – offline/online detection

Runtime UI crashes are handled via a React error boundary, wrapped once at the app root.

Design Principle #6: TypeScript-First

TypeScript isn’t an add-on — it’s the foundation.

strict typing
shared types between FE & BE
discriminated unions for error types
strong inference for consumers

This means:

fewer runtime surprises
safer refactors
better IDE experience

Types are the documentation.

End-to-End Flow (How Everything Connects)

Here’s the full journey of an error:

Backend detects a failure

Error is normalized into a standard structure
API returns a predictable error response
Frontend parses the error
Error code is mapped to a user-friendly message
UI displays a safe, meaningful response

At no point does the UI guess what went wrong.

Why This Matters in Production

This approach gives you:

cleaner APIs
better UX
safer production behavior
easier debugging (via trace IDs)
a shared mental model for teams

Error handling stops being “glue code” and becomes infrastructure.

The Result: A Universal Error Handler

I packaged this system as an open-source npm library:

npm install @shubhamgupta-oss/universal-error-handler

It works with:

React
Next.js
Node.js
Express
TypeScript
React 18 & 19

GitHub repo: https://github.com/shubhamgupta-oss/universal-error-handler
NPM package: https://www.npmjs.com/package/@shubhamgupta-oss/universal-error-handler

Final Thoughts

Good error handling isn’t about catching errors.

It’s about:

defining responsibility
designing contracts
respecting separation of concerns

Once you treat errors as a first-class system, everything else becomes simpler.

If you’re building full-stack applications and struggling with inconsistent error handling, I hope this approach helps.

Feedback, suggestions, and contributions are welcome. 🙌