DEV Community: Sachin Maurya

How I Got My Portfolio to 100 PageSpeed on Mobile and Desktop

Sachin Maurya — Sun, 28 Jun 2026 07:36:53 +0000

I recently cleaned up my portfolio and got it to 100 in PageSpeed Insights on both mobile and desktop for:

Performance
Accessibility
Best Practices
SEO

It also got an A on GTmetrix.

This was not because of one magic trick.

It was mostly a lot of small cleanup decisions.

1. I reduced unnecessary client-side work

One thing I focused on was keeping the public page as light as possible.

If something does not need to run in the browser, it should not run in the browser.

That means:

fewer client-side features
less JavaScript shipped to the user
simple rendering flow
no extra state where it is not needed

This helped keep the page fast.

2. I kept the UI simple

I did not want to add effects just for the sake of it.

A portfolio should load fast and communicate clearly.

So I kept the layout simple:

clear sections
readable text
simple buttons
no heavy animations
no unnecessary libraries

This made the site easier to maintain and also helped performance.

3. I cleaned up SEO metadata

SEO was another area I improved.

I checked that the site had:

proper title and description
correct canonical URL
Open Graph metadata
robots and sitemap behavior
different handling for production and staging

One important thing was making sure the staging/dev version does not get indexed.

Production should be visible. Staging should stay hidden.

4. I improved accessibility

Accessibility improvements were mostly basic but important.

I checked things like:

color contrast
button and link behavior
readable text sizes
semantic HTML
useful fallback screens

Sometimes accessibility is not about adding more code. It is about making the existing UI clearer.

5. I added better error and offline states

I added cleaner fallback screens for error and not-found cases.

I also added a very small offline fallback.

The idea was simple:

If the portfolio is not available offline, show a basic message and still allow the visitor to download the resume.

I did not want to build a full PWA or add unnecessary complexity.

Just enough offline support to be useful.

6. I checked with GTmetrix too

After PageSpeed, I also checked the site with GTmetrix.

The result was:

GTmetrix Grade: A
Performance: 99%
Structure: 99%
LCP: 781ms
TBT: 0ms
CLS: 0

This helped confirm that the site was not only passing one tool, but performing well in another check too.

7. I kept performance features minimal

It is easy to over-engineer performance.

But for this site, the best approach was to keep things boring:

no heavy runtime logic
no unnecessary fallbacks
no large client-side packages
no complex caching strategy
no feature that hurts the main page load

The goal was not to add more. The goal was to remove what was not needed.

8. I verified everything before shipping

Before calling it done, I ran checks for:

lint
TypeScript
formatting
production build
PageSpeed Insights
GTmetrix

This helped catch small issues before deployment.

What I learned

Getting a 100 score is not about chasing Lighthouse blindly.

It is about building with discipline.

For me, the main lessons were:

keep the fast path simple
avoid unnecessary JavaScript
care about accessibility from the start
make SEO explicit
don’t add features without a reason
verify before shipping

Small cleanup decisions add up.

That was the biggest learning from this work.

Building a Multi-Layer Caching Strategy in Next.js App Router: From Static to Real-Time

Sachin Maurya — Thu, 01 Jan 2026 05:29:06 +0000

Caching is one of those make-or-break aspects of modern web development. Get it right, and your app is fast, resilient, and scalable. Get it wrong, and you’re left with stale data, poor performance, or worse — broken user experiences.

At my previous role, I led the migration of our corporate platform to the Next.js App Router. One of our core challenges was designing a caching strategy that could handle:

Fully static marketing pages
Occasionally updated blog content
Personalized user dashboards
Real-time activity feeds
Mixed-content pages (static + dynamic)

In this post, I’ll walk through how we built a multi-layer caching architecture that kept our Lighthouse scores consistently above 95 while ensuring data freshness where it mattered most.

Understanding Next.js Caching Layers

Before jumping into implementation, it’s important to understand the caching layers available in the App Router:

Full Route Cache – Entire route responses (HTML) cached at build or request time
Data Cache – Results of fetch requests persisted across requests
Client Cache – Caching done in the browser (via React Query, Zustand, etc.)
CDN/Edge Cache – Caching at the network edge (Vercel, Cloudflare, etc.)

Each layer serves a different purpose, and using them together is key.

Layer 1: Fully Static Pages with `force-static`

We had several pages that never changed: /about, /contact, /legal. For these, we used:

// app/about/page.js
export const dynamic = 'force-static'

export default function AboutPage() {
  // This page is cached at build time
  // and served from CDN indefinitely
}

Why force-static?

It tells Next.js to skip all dynamic logic, treat the page as completely static, and cache it at the edge. This is ideal for true static content.

Impact:

These pages loaded instantly on repeat visits and required zero backend computation.

Layer 2: Incrementally Static Pages with ISR

Our blog and documentation pages were mostly static but could be updated via CMS. We used Incremental Static Regeneration (ISR) with on-demand revalidation.

Step 1 – Basic ISR

// app/blog/[slug]/page.js
export const revalidate = 3600 // Revalidate every hour

async function getPost(slug) {
  const res = await fetch(`https://api.example.com/posts/${slug}`, {
    next: { tags: ['posts'] }
  })
  return res.json()
}

export default async function BlogPost({ params }) {
  const post = await getPost(params.slug)
  return <PostLayout post={post} />
}

Step 2 – On-Demand Revalidation

When a post was updated in the CMS, we triggered:

// app/api/revalidate/route.js
import { revalidateTag } from 'next/cache'

export async function POST(request) {
  const { tag } = await request.json()
  revalidateTag(tag) // e.g., 'posts'
  return Response.json({ revalidated: true })
}

This meant:

Blog posts were cached for performance
But could be updated in seconds when needed
No full rebuilds required

Layer 3: Personalized Dashboards – No Server Cache

For authenticated user dashboards (/dashboard, /settings), we disabled server caching entirely.

// app/dashboard/page.js
export const dynamic = 'force-dynamic'

export default async function DashboardPage() {
  // This page is never cached on the server
  // Fresh data on every request
}

Instead, we moved caching to the client layer:

React Query for server-state caching, background updates, and request deduplication
Zustand for client-side UI state
Optimistic updates for a snappy UX

Example with React Query:

// app/dashboard/activity.js
'use client'

import { useQuery } from '@tanstack/react-query'

function fetchActivity() {
  return fetch('/api/activity').then(res => res.json())
}

export default function ActivityFeed() {
  const { data, isLoading } = useQuery({
    queryKey: ['activity'],
    queryFn: fetchActivity,
    staleTime: 1000 * 60 * 5, // Consider data fresh for 5 minutes
  })

  // Render feed
}

Why client cache here?

User data is personalized and sensitive. Server caching could leak data between users. Client caching is safe and still provides performance benefits.

Layer 4: Real-Time Components with Streaming

For real-time components like live notifications or stats, we used Streaming with Suspense.

Component Structure

// app/dashboard/live-stats.js
'use client'

import { useEffect, useState } from 'react'

export default function LiveStats() {
  const [stats, setStats] = useState(null)

  useEffect(() => {
    const ws = new WebSocket('wss://api.example.com/live')
    ws.onmessage = (event) => {
      setStats(JSON.parse(event.data))
    }
    return () => ws.close()
  }, [])

  return stats ? <StatCard stats={stats} /> : <StatSkeleton />
}

Wrapping in Suspense

// app/dashboard/page.js
import { Suspense } from 'react'
import LiveStats from './live-stats'

export default function Dashboard() {
  return (
    <div>
      <h1>Dashboard</h1>
      <Suspense fallback={<StatSkeleton />}>
        <LiveStats />
      </Suspense>
    </div>
  )
}

This allowed the rest of the page to load quickly while real-time components hydrated separately.

The Hybrid Page Problem

Our homepage was tricky:

Static hero section
Dynamic user greeting (if logged in)
Real-time trending section
Cached blog previews

Our Solution: Isolate Caching Boundaries

// app/page.js
import { React } from 'react'
import { getHeroData, getTrendingPosts } from '@/app/actions'
import UserGreeting from './user-greeting'
import TrendingSection from './trending'
import BlogPreview from './blog-preview'

// Cache static data
const getCachedHeroData = React.cache(getHeroData)
const getCachedTrending = React.cache(getTrendingPosts)

export default async function HomePage() {
  const [heroData, trending] = await Promise.all([
    getCachedHeroData(),
    getCachedTrending(),
  ])

  return (
    <main>
      {/* Static hero */}
      <Hero data={heroData} />

      {/* Dynamic user greeting */}
      <Suspense fallback={<GreetingSkeleton />}>
        <UserGreeting />
      </Suspense>

      {/* Real-time trending */}
      <Suspense fallback={<TrendingSkeleton />}>
        <TrendingSection />
      </Suspense>

      {/* Cached blog previews */}
      <BlogPreview posts={trending} />
    </main>
  )
}

By splitting sections into different caching boundaries, we optimized each part independently.

Monitoring & Debugging

A caching strategy is useless without monitoring.

1. Lighthouse + Web Vitals

We ran Lighthouse in CI on every PR and set performance budgets.

2. Custom Cache Logging

We added logging middleware to track cache hits/misses:

// middleware.js
import { NextResponse } from 'next/server'

export function middleware(request) {
  const response = NextResponse.next()

  // Add cache headers for static assets
  if (request.nextUrl.pathname.startsWith('/_next/static')) {
    response.headers.set('Cache-Control', 'public, max-age=31536000, immutable')
  }

  return response
}

3. Vercel Analytics

We used Vercel’s built-in analytics to monitor cache hit ratios and edge performance.

Results & Metrics

After implementing this layered approach:

Lighthouse Performance: 96+ (consistent across pages)
Cache Hit Ratio (CDN): 92%
Reduced Backend Load: ~40% fewer queries for cached content
Time to Interactive: Improved by ~35%
Real-Time Updates: Reflected within 2-3 seconds

Lessons Learned

Cache based on content type, not convenience – Each type of content has different freshness requirements.
Use revalidateTag over revalidatePath – More precise, less expensive.
Client caching is not obsolete – It’s essential for personalized data.
Monitor, monitor, monitor – Caching behavior can change with traffic patterns and updates.
Document your strategy – Team onboarding and debugging become much easier.

Final Thoughts

Caching in the App Router is powerful but requires intentional design. There’s no one-size-fits-all solution. By building a multi-layer caching strategy, you can optimize for both performance and freshness.

If you’re working on a Next.js app and thinking about caching, start by:

Auditing your content types – What’s static? What’s dynamic?
Mapping content to cache layers – Use the right tool for each job.
Implementing incrementally – Start with static pages, then add ISR, then client caching.
Measuring impact – Use Lighthouse and analytics to validate improvements.

Caching isn’t just a performance optimization—it’s a core part of your application architecture. Design it thoughtfully, and your users (and your infrastructure) will thank you.

Interested in more deep dives on Next.js performance?

Check out my other posts on React re-renders, bundle optimization, and WCAG compliance.

A More Structured Version of Frontend Master Prep Series

Sachin Maurya — Fri, 12 Dec 2025 14:49:04 +0000

I’ve updated the Frontend Master Prep Series with a focus on structure and clarity rather than adding more questions or problems.

The earlier versions of the repo were useful, but not very guided. There wasn’t a clear sense of where to begin, how to move through topics, or how the Q&A, challenges, and flashcards were meant to work together. This update focuses on solving that.

The README now includes three specific starting points:
• A four-week study plan for anyone preparing with a defined timeline
• A daily practice flow that combines flashcards and coding problems
• A short, focused revision checklist for last-minute preparation

The internal structure is now more intentional. Each topic has its own place, and Q&A, examples, and flashcards are no longer mixed together. The architecture section is also separated out so it can grow without affecting the rest of the repo.

The flashcards have been updated as well. They now work in both Markdown and the interactive version of the app, which uses spaced repetition and tracks progress locally.

Coding problems remain at 65 for now, but the grouping and purpose are clearer. They are organized by theme and difficulty instead of being a loose collection.

This update is mainly about usability. The goal is to make the repo something developers can return to regularly, whether they are revising fundamentals or preparing for interviews.

The repo is here if you want to explore the structure:
https://github.com/maurya-sachin/Frontend-Master-Prep-Series

I just shipped v3.0 of Frontend Master Prep Series — Study Paths, 374+ Q&A, 65 Coding Problems & 500+ Flashcards

Sachin Maurya — Fri, 28 Nov 2025 05:14:21 +0000

A while back, I shared two big milestones in my frontend prep journey:

A list of 650+ frontend interview questions — the raw brain-dump that started it all.
v2.0 of Frontend Master Prep Series — where that list evolved into a more structured “frontend mastery system.”

Since then, the repo has kept growing — but more importantly, how you use it has changed.

Developers didn’t just want more content.
They wanted:

Clear entry points (What do I do if my interview is tomorrow vs in 4 weeks?)
A way to revise quickly without scrolling through massive markdown files
A path that feels like a learning system, not just a massive question bank

So v3.0 is all about that.

Less “here are a thousand things you could read.”
More “here’s exactly how to use this to get better, fast.”

What’s new in v3.0?

Here’s what this release focuses on.

1. Guided Quick Start paths

The README now starts with four clear ways to begin:

4-Week Sprint → A complete study plan for people targeting interviews in a month
Interview Tomorrow? → A 30-card flashcard deck for last-minute revision
Daily Practice → A consistent routine with Essential 50 + coding problems
Interactive Study → A flashcard web app you can open in your browser

Instead of wondering “Where do I start?”, you pick the path that fits your timeline and dive in. (GitHub)

2. A cleaner content model (with real numbers)

The repo is now explicitly framed around three pillars:

✅ Core Q&A

374+ Q&A across 16 topics
JavaScript, TypeScript, React, Next.js, HTML/CSS, Testing, Performance, Accessibility, Security, System Design, Browser, Networking, PWA, Tooling, i18n, SEO
Each with explanations, follow-up questions, mistakes, and real-world context (GitHub)

This is the “deep reading + understanding” layer.

✅ Coding Problems

65 problems live right now, targeting 185+
Categories: JS fundamentals, DOM, React problems, algorithms, UI components, system implementations, company-style questions
Each problem aims to include: multiple solution approaches, tests, complexity, and real-world use cases (GitHub)

This is where you move from knowing to doing.

✅ Flashcards + Web App

514+ flashcards spread across curated decks and topic decks
Curated decks like Essential 50, Pre-Interview 30, Daily Review 20
Topic decks for JS, React, TS, Next.js, HTML/CSS, Performance, etc.(GitHub)
Two formats:
- Markdown (for GitHub / Obsidian / VS Code)
- An interactive React app with spaced repetition (SM-2), local storage, and progress tracking

This is your “maintenance mode” — keeping your brain warm daily.

3. A dev-friendly, scalable structure

One big change in v3.0 is treating the repo like a real product, not just a folder of notes.

Here’s the updated structure straight from the repo:

Frontend-Master-Prep-Series/
├── 01-javascript/          # Core JS concepts, async, engine internals (53 files)
├── 02-typescript/          # Type system, generics, advanced patterns (22 files)
├── 03-react/               # Hooks, patterns, performance, internals (71 files)
├── 04-nextjs/              # App Router, SSR, ISR, Server Components (16 files)
├── 05-html-css/            # Semantics, layouts, modern CSS (19 files)
├── 06-testing/             # Jest, RTL, E2E, testing patterns (5 files)
├── 07-performance/         # Core Web Vitals, optimization (6 files)
├── 08-accessibility/       # WCAG, ARIA, keyboard navigation (17 files)
├── 09-security/            # XSS, CSRF, auth, headers (6 files - expanding)
├── 10-system-design/       # Component & frontend design patterns (4 files)
├── 11-browser/             # Rendering pipeline, storage APIs (3 files)
├── 12-networking/          # HTTP/2/3, caching, CDNs (3 files)
├── 13-pwa/                 # Service workers, offline-first (3 files)
├── 14-tooling/             # Webpack, Vite, Babel (3 files)
├── 15-i18n/                # Localization, RTL, formatting (3 files)
├── 16-architecture/        # Coming soon - frontend architecture patterns
├── 17-seo/                 # Technical SEO, structured data (2 files)
├── 18-coding-challenges/   # 65 coding problems
│   ├── 01-javascript-fundamentals/
│   ├── 02-dom-manipulation/
│   ├── 03-react-problems/
│   ├── 04-algorithms/
│   ├── 05-ui-components/
│   └── 06-performance/
├── 19-flashcards/          # 514+ flashcards
│   ├── curated-decks/
│   └── by-topic/
├── src/                    # Flashcard web app (React + Vite)
├── public/                 # Static assets, manifest
└── resources/              # Study guides, checklists, learning paths

This is intentional: if someone clones the repo, they immediately understand where everything lives and how to extend it.

4. Study paths baked into the README

You no longer have to invent your own plan.

The README now includes:

A 4-week sprint plan (week-by-week focus + time estimates)
A Daily Practice path for long-term growth
An “Interview Tomorrow?” checklist that tells you exactly what to hit in 30–60 minutes (GitHub)

This makes the repo usable for:

Panic revision
Structured, medium-term prep
Slow, consistent mastery

The GitHub repo

👉 Frontend Master Prep Series v3
https://github.com/maurya-sachin/Frontend-Master-Prep-Series (GitHub)

Open it in VS Code, Obsidian, or straight in the browser.
Use it as a reference, a study plan, or a daily practice system.

Why this version matters

The first post (650+ questions) was about volume.
The second one (v2.0) was about turning that volume into a mastery system.

v3.0 is different.

This release is about experience:

How fast can you get from “I found this repo” to “I’m using it daily”?
How easy is it to switch between reading, solving, and revising?
Can you use it whether you have 10 minutes or 2 hours?

I’ve tried to answer those questions with:

Clear quick-start paths
A predictable structure
A flashcard app that actually respects how memory works
Study plans you don’t have to design yourself

What’s next?

I’m actively working on:

Filling out Architecture and System Design sections
More company-style question sets
Expanding React + Next.js patterns
More performance & networking case studies
Potentially a Notion/Obsidian template wired to this structure

If there’s something specific you’d like:

A deck for a specific company?
More problems in a certain category?
A deep-dive on a topic inside this repo?

Open an issue, comment on the repo, or ping me — I’m building this in public and your feedback genuinely shapes the roadmap.

Why I keep building this

Honestly, I built this for myself first.

I wanted to:

Stop prepping from scattered YouTube playlists and notes
Have a single place that respects both interview prep and real-world engineering
Turn my own interview scars into something useful for other devs

If even one developer walks into their next interview a little more confident because of this repo, all the late-night organizing, refactoring, and writing has already paid off.

⭐ If this helps you, consider:

Starring the repo
Sharing it with a friend who’s prepping
Sending feedback so v4.0 can be even better

Let’s make frontend interview prep feel less chaotic — and a lot more intentional.

The 7 Mistakes I Made as a Junior Frontend Developer (and the Engineering Fixes That Helped Me Grow Faster)

Sachin Maurya — Fri, 21 Nov 2025 17:00:34 +0000

Early in my frontend career, I wasn’t struggling because JavaScript was hard.
I struggled because I didn’t understand engineering thinking.
Here are the mistakes that slowed me down — and the exact technical shifts that finally pushed me forward.

1. Focusing on UI output instead of understanding the architecture

I used to write components quickly… and rewrite them even quicker when the project grew.

What I learned:
Frontend is architecture-heavy. Naming, data ownership, routing boundaries, API strategy, state placement — everything matters.

Fix in practice:

Co-located state with the smallest responsible component
Used “feature-first” folder structure
Adopted clear boundaries between server state (React Query) and UI state (Zustand/Context)
Removed cross-feature imports to avoid spaghetti

This alone made my codebases far more predictable.

2. Copy–pasting solutions without understanding internals

I solved problems fast, but only on the surface.
Whenever something broke, I couldn't debug deeper because I never knew how it actually worked.

Fix in practice:

Studied the React reconciliation RFC
Read how the browser event loop schedules microtasks vs macrotasks
Explored how React Query caches and invalidates data
Learned how Next.js handles RSC hydration boundaries

Reading internals gave me “X-ray vision” during debugging.

3. Treating performance as a final step instead of a design constraint

I used to optimise only when Lighthouse screamed at me.

Fix in practice:

Measured hydration cost and moved heavy UI to server components
Reduced bundle size using dynamic imports + route-level code splitting
Cached expensive calculations using useMemo only where profiling proved it helped
Added proper caching headers + ISR for API-heavy pages

Performance improved because I designed with it in mind.

4. Over-engineering small features

I thought adding abstraction made me “senior”.

Fix in practice:

Used reducers only for genuinely complex state transitions
Avoided wrapper components when plain JSX worked
Stopped making utility functions for one-line logic
Followed the “start simple → scale when needed” rule

Removing unnecessary layers made my code easier to read and maintain.

5. Taking CSS lightly

My layouts looked fine… until they broke on a different screen size or when content changed.

Fix in practice:

Learned CSS cascade layers (huge mental unlock)
Used logical properties for RTL-friendly layouts
Adopted consistent spacing/typography tokens
Designed components with intrinsic sizing first, not pixel-perfect assumptions

CSS became less “trial and error” and more “predictable behaviour”.

6. Random learning with no system

I bounced between tutorials, and it felt like progress… except nothing stuck.

Fix in practice:

Followed a clear roadmap
Built real projects instead of cloning UIs
Took notes with examples, not theory
Revised older codebases to see improvement clearly

This structured approach finally created momentum.

7. Ignoring accessibility until a real project forced me to care

My mindset changed when I worked on a government project that had to meet WCAG.

Fix in practice:

Ensured every interactive element was keyboard-first
Used semantic markup before ARIA
Tested with screen readers
Checked contrast ratios and focus paths
Avoided “div soup” that confuses assistive tech

Accessibility stopped being a checkbox; it became a performance and UX enhancer.

Why I Wrote This

Every engineer grows through mistakes — but some mistakes slow the journey more than others.
These were mine.
If you're somewhere in this list, you’re not behind — you’re right where most of us started.

I just shipped v2.0 of Frontend Master Prep Series — 1,020+ Q&A + 185 coding problems + 600 flashcards

Sachin Maurya — Mon, 10 Nov 2025 16:36:25 +0000

A few days back, I published a list of 650+ frontend interview questions.

That post got attention, feedback, and a surprising amount of messages from developers (both junior and senior) telling me it helped them prep better.

But something didn’t feel complete.

Because questions alone are not enough.

So I continued learning deeply, exploring each topic, facing more interviews, reading docs, breaking code, and then documenting the patterns I found.

And that small side note list turned into something else completely.

What’s new in v2.0?

1,020+ questions with detailed answers
185+ coding problems (each solved step-by-step)
600+ flashcards for fast revision
new sections: TypeScript, Security, Testing, Tooling
difficulty tags, interview frequency, company tags
code examples + common mistakes + time to answer estimates

This is no longer “a question bank”.
This is a complete frontend mastery system.

GitHub Repo

📘 Frontend Master Prep Series v2
https://github.com/maurya-sachin/Frontend-Master-Prep-Series

Open-source. Free. Well-structured.
Use it in VS Code / Obsidian / Notion.

Why this matters

Most interview prep content online is too shallow.

It teaches the what.

But senior interviews check the why.

Why does React re-render?
Why does this promise resolve later?
Why Next.js instead of client-side React?

This project grew because I kept asking that exact question myself.

What’s next?

I’m currently working on:

a Notion version with progress tracking
a PDF cheat sheet for 1-day revision
a “Roadmap style” resource guide by topics

Why I built this

To be honest — I built this for myself first.
Because I wanted to really understand this craft.

But if even one developer somewhere uses this repo and gets more confident before their next interview —
then this work is already worth it.

If you find this useful — consider giving a ⭐ to the repo.
That’s how I’ll know this should continue growing.

tags: frontend react nextjs javascript typescript webdev career interviewprep learning

650+ Frontend Interview Questions (JavaScript, React, Next.js & More) — My Complete Prep Journey

Sachin Maurya — Sat, 01 Nov 2025 13:36:16 +0000

After giving a few frontend interviews recently, I noticed a pattern.

Almost every interviewer went beyond surface-level coding questions and asked about how things actually work under the hood —

things like the event loop, React Fiber, Next.js routing, and JavaScript internals that power our apps every day.

Instead of just memorizing answers, I decided to deeply explore every topic I encountered.

So I began building a small question list.

Then it became 50.

Then 200.

And finally — a collection of over 650 questions and concepts covering everything from core JavaScript to advanced React and Next.js internals.

🔍 What’s Inside

💻 JavaScript Deep Dives — event loop, call stack, microtask vs macrotask queues, shadowing, closures, promises, async/await, debouncing, throttling, memory leaks, and more.
⚛️ React Concepts — reconciliation, Fiber, lifecycle with hooks, memoization, custom hooks, performance tuning, suspense, error boundaries, and rendering optimization.
🔗 Next.js — SSR, SSG, ISR, RSC, parallel routing, middleware, static optimization, SEO, and API routes.
🎨 UI / CSS / HTML — accessibility, animations, layouts, BEM, flexbox vs grid, performance, and responsive systems.

This isn’t just a question dump — it’s a structured learning roadmap for frontend engineers preparing for interviews or aiming to grow into senior roles.

📘 The GitHub Repository

📘 View the full guide here:

Frontend Master Prep Series (650+ Questions)

It’s a single Markdown file you can open directly in VS Code, Obsidian, or Notion for easy reading and note-taking.

Each section is cleanly structured so you can use it as a reference or learning log.

🧩 How I Built It

This list came together from:

Real interview questions I faced during recent rounds
Discussions with mentors and frontend peers
Topics I explored deeply using ChatGPT, MDN, and official documentation
Debugging challenges from my own projects like
- GENAI Document Analyzer
- Kreate Energy Platform
- Kreate Technologies

Each section evolved organically as I learned — not just what to answer, but why things work that way.

💬 What’s Next

I’m planning to release:

🧾 A PDF cheat sheet (condensed quick notes for revision)
🧠 A Notion version for interactive prep and progress tracking
📚 A topic-wise resource roadmap with links to docs and tutorials

If that sounds useful, comment below — I’ll make them public soon.

🧠 Why I Wrote This

Because frontend interview prep shouldn’t be about memorizing buzzwords —

it should be about understanding what makes the web actually work.

This guide started as a personal learning log, but I realized it could help others too.

If it helps even one developer feel more confident walking into their next interview, it’s worth every late-night deep dive into React Fiber, microtask queues, and performance tuning.

⭐ If you find it helpful, consider starring the GitHub repo and sharing it with someone preparing for frontend interviews.

Let’s make learning a bit easier for the next person in line.

frontend #react #nextjs #javascript #webdevelopment #career #interviewprep #learningjourney

The Cost of Re-Renders: How to Make React Apps Actually Reactive

Sachin Maurya — Thu, 30 Oct 2025 09:44:35 +0000

Introduction

React’s biggest selling point has always been simple:

“It’s fast because it re-renders efficiently.”

But here’s the uncomfortable truth — React isn’t fast by default.
It’s just forgiving.

If you don’t design your state carefully, React’s virtual DOM can easily become your bottleneck.
And the more complex your app grows, the more expensive every unnecessary re-render becomes.

Let’s dissect why re-renders happen, how to avoid them, and what being “reactive” actually means in 2025.

1. Every Re-Render Has a Cost

Every React render triggers a reconciliation cycle:

Components re-run,
Hooks re-evaluate,
JSX re-diffing happens,
Child components may re-render too.

It’s all virtual, but it’s not free.
When your app scales to hundreds of components, these micro re-renders add up — especially when tied to global or context-based state.

2. The Silent Villain: Shared State

Developers often push everything into Context or Redux for “simplicity.”
The problem? Every value change triggers re-renders across all consumers, even if most don’t use that specific part of the state.

// Common pattern
const ThemeContext = createContext();

function App() {
  return (
    <ThemeContext.Provider value={{ darkMode, toggleDarkMode }}>
      <Header />
      <Sidebar />
      <Content />
    </ThemeContext.Provider>
  );
}

Even if only Header uses darkMode, all children inside the provider re-render when it changes.
That’s death by a thousand re-renders.

3. Memoization Isn’t a Silver Bullet

You might say, “I’ll just memo everything.”
Sure — but memoization has its own cost.

React.memo() prevents re-renders only if props are shallow-equal.
useMemo() and useCallback() cache computations, but add complexity and memory overhead.

If you’re wrapping half your tree in React.memo(), you’re fighting React — not optimizing it.

The better solution is state locality — keeping state as close as possible to where it’s used.

4. Localize, Slice, and Select

The more granular your state, the fewer components React needs to re-render.

That’s why libraries like Zustand, Jotai, and Valtio are so effective — they allow components to subscribe only to the data they need.

Example (Zustand):

const useStore = create(set => ({
  count: 0,
  increment: () => set(state => ({ count: state.count + 1 })),
}));

function Counter() {
  const count = useStore(state => state.count);
  return <p>{count}</p>;
}

Here, React re-renders only components using count, not the entire app.
That’s true reactivity, not reconciliation.

5. Fine-Grained Reactivity Is the Future

React’s model is coarse-grained: it re-renders entire components when state changes.
But new paradigms (like Signals in Solid, Qwik, and even React Canary builds) use fine-grained reactivity — updating only the exact DOM nodes that depend on changed data.

This shift reduces the cost of re-renders dramatically, making UI feel instantaneous.

If React 18 was about concurrency, React 19+ will be about reactivity.

6. Measuring Re-Render Costs

You can’t optimize what you can’t see.
Use the React DevTools “Profiler” to measure where re-renders happen — you’ll often be surprised.

Look out for:

Components re-rendering without prop/state changes
Context-heavy trees
Missing key attributes
Inline object/array props

Identifying hot spots is half the battle.

7. The Real Goal: Flow, Not Frames

When your React app feels slow, it’s rarely the algorithm — it’s usually the render flow.
True performance comes from structuring your app around reactive data flow, not just faster diffing.

It’s not about “preventing re-renders”; it’s about making every render count.

Conclusion

React doesn’t slow down your app — your architecture does.

Stop chasing useMemo everywhere.
Start designing state locality, reactive data flows, and granular subscriptions.

That’s how modern UIs achieve “speed” — not by skipping renders, but by rendering intelligently.

Why I Wrote This

I wrote this after noticing how often React developers (my past self included) equate “performance” with “memoization.”
But performance doesn’t come from avoiding renders — it comes from understanding when they happen and why.

If this post helped you see React’s rendering model differently, I’d love to hear your take —
How do you handle re-renders in your projects?
Do you rely more on memoization or on state locality patterns (like Zustand/Jotai)?

Drop your thoughts below — let’s make this a conversation rather than just another React article.

Optimizing for Perceived Performance: The Psychology Behind Fast UIs

Sachin Maurya — Sat, 11 Oct 2025 18:04:16 +0000

When we talk about performance in frontend engineering, we usually mean metrics:
LCP, FID, CLS, INP, TTFB — numbers that quantify “speed.”

But here’s the truth most developers learn the hard way:
Users don’t experience speed as numbers. They experience it as feel.

And that’s what perceived performance is about — how fast your app feels, not just how fast it actually is.

1. Performance ≠ Perception

I’ve seen products that hit 95+ Lighthouse scores yet feel sluggish to users.
At the same time, I’ve built apps that score 80 but feel “instant.”

Why? Because our brains don’t measure milliseconds. They respond to feedback, continuity, and control.

A user who sees immediate feedback (even if data isn’t ready) perceives speed.
A user who waits with no visual cue perceives slowness — even if it’s technically faster.

2. Skeletons, Placeholders, and the Illusion of Speed

Let’s take an example:
When your app fetches data, showing nothing makes the user wait.
Showing a skeleton makes them feel progress.

{isLoading ? <SkeletonList /> : <UserList users={data} />}

Skeleton UIs don’t reduce load time.
They reduce wait perception — the most important performance metric that Lighthouse can’t measure.

3. The Power of Optimistic Updates

Optimistic updates are the perfect intersection of UI and psychology.

You’re not waiting for the server; you’re trusting the user’s intent.

Example: liking a post, updating a task, or toggling a switch — don’t wait for confirmation. Assume success and sync later.

setLiked(true);
updateLikeOnServer(postId).catch(() => setLiked(false));

This pattern creates instant feedback, even in high-latency environments.
It’s a small gesture that makes your product feel confident — and that confidence transfers to the user.

4. Transitions: The Hidden Layer of Perceived Speed

React’s useTransition and concurrent rendering introduced a new way to separate urgent vs. non-urgent updates.

This isn’t micro-optimization — it’s UX optimization.

const [isPending, startTransition] = useTransition();

startTransition(() => {
  setFilteredItems(filterData(items, searchTerm));
});

Your UI stays responsive while heavy updates happen in the background.
The user keeps typing, scrolling, navigating — uninterrupted.

That’s perceived performance in motion.

5. Small Delays That Feel Fast

It’s counterintuitive, but sometimes adding delay makes interfaces feel smoother.

A quick example:
If you show a spinner for only 50ms, users perceive flicker.
If you delay it for 150–200ms, transitions feel natural.

The brain interprets fluid motion as quality.
That’s why Framer Motion and GSAP animations are performance tools — not just aesthetics.

6. Perception Is a Design System Concern

Frontend performance isn’t only a React problem.
It’s a design system problem.

Designers define visual hierarchy; engineers define interaction hierarchy.
Knowing what needs to respond instantly (click feedback) vs. what can wait (data rendering) is what creates perceived speed.

When design and engineering collaborate on feedback loops, even slow backends can feel fast.

Conclusion

We obsess over performance metrics — and we should.
But metrics can’t capture the emotional velocity of your product.

Users don’t thank you for your 100 Lighthouse score.
They thank you for making things feel instant, fluid, and alive.

So next time your app “feels slow,” don’t just open DevTools.
Ask: Where is the user waiting without feedback?

That’s your real performance bottleneck.

Tags:

FrontendDevelopment #ReactJS #WebPerformance #UXDesign #NextJS #JavaScript

Lessons I Took Away from the Meta Front-End Developer Career Certificate

Sachin Maurya — Tue, 07 Oct 2025 08:40:14 +0000

Introduction
When I picked up the Meta Front-End Developer Career Certificate on Coursera, I thought of it as just another structured path to sharpen my React and frontend skills. What I didn’t expect was how it would shift my perspective from building pages to engineering user experiences.

Here’s what stood out to me.

1. Frontend engineering is more than visuals

The course emphasizes HTML, CSS, and JavaScript fundamentals, but the deeper value is in accessibility and responsive design.

I learned that:

Semantic HTML improves accessibility for real users (and screen readers).
ARIA roles aren’t optional if inclusivity is the goal.
Responsive layouts are not “mobile-friendly hacks” but part of design systems.

This mindset helps move from “does it render?” to “does it serve everyone?”

2. Performance is a feature

One big takeaway: performance isn’t something to patch later — it’s something to design for.

From my projects, I experimented with:

Code-splitting and dynamic imports to reduce JS bundles.
Caching and ISR in Next.js for faster delivery.
Image and font optimization to improve Core Web Vitals.

When performance is prioritized early, users notice.

3. Error states matter more than happy paths

The course introduces testing and debugging, but I pushed this further with error boundaries and resilient components.

The lesson: a broken app erodes trust immediately.

A fallback message is better than a crash.
A retry button tells the user you thought ahead.

Good UI is defined by how it behaves under stress.

4. Learning compounds when you share

I didn’t stop at completing exercises. I extended them into projects and wrote about accessibility audits, state management tradeoffs, and rendering strategies.

By sharing, I not only reinforced my learning but also connected with developers who challenged me with new ideas (like diving into useTransition).

Conclusion
The Meta Front-End Developer Career Certificate isn’t just about checking a box. It’s about developing the discipline to think about accessibility, performance, resilience, and communication as core parts of frontend engineering.

Courses give you the scaffolding — but it’s the building, testing, and sharing that turn it into real growth.

Mastering React’s useTransition: Smooth UI Updates Without Blocking the Main Thread

Sachin Maurya — Wed, 24 Sep 2025 06:32:26 +0000

Introduction:
A few days ago, I was diving into rendering strategies in React and Next.js, discussing CSR, SSR, SSG, and ISR. One comment really caught my eye:

“useEffect ❌, useTransition ✅”

This got me curious—how can we make our React apps feel instantly responsive even under heavy state updates? That’s where useTransition shines. Let’s break it down and see how to use it effectively.

1. Why We Need useTransition
In complex React apps, updating state in big components (like large lists, dashboards, or filtered tables) can block the main thread. Typing, clicking, or scrolling feels sluggish. Traditional useEffect updates can cause noticeable lag because React treats them as urgent updates.

useTransition (introduced in React 18) lets us mark some updates as transitions, which are non-urgent. React can then prioritize keeping the UI responsive while handling heavier updates in the background.

2. Basic Usage

import { useState, useTransition } from 'react';

function SearchList({ data }) {
  const [query, setQuery] = useState('');
  const [filtered, setFiltered] = useState(data);
  const [isPending, startTransition] = useTransition();

  const handleChange = (e) => {
    const value = e.target.value;
    setQuery(value);
    startTransition(() => {
      const result = data.filter(item => item.includes(value));
      setFiltered(result);
    });
  };

  return (
    <div>
      <input type="text" value={query} onChange={handleChange} />
      {isPending && <p>Loading...</p>}
      <ul>
        {filtered.map((item, idx) => (
          <li key={idx}>{item}</li>
        ))}
      </ul>
    </div>
  );
}

Explanation:

isPending: true while the transition is in progress
startTransition: wraps state updates we want to defer
Result: typing remains smooth, even for large lists

3. When to Use useTransition

Typing/search in large datasets
Filtering or sorting heavy lists
Updating dashboards with multiple components
UI interactions that must stay responsive

4. Best Practices

Don’t overuse: simple state toggles don’t need transitions
Combine with React.memo to avoid unnecessary re-renders
Use with Suspense for async updates to show loaders

5. Real-World Example

Imagine a product catalog with 1000+ items. Without useTransition, typing in a search bar blocks the UI. With useTransition:

Typing stays fluid
Filtered results update progressively
Optional “Loading…” feedback via isPending

6. Measuring Improvements

Use React Profiler to see which components re-render
Check Core Web Vitals for interactive performance
Verify that deferred updates don’t compromise UX

Conclusion:
useTransition is simple but powerful. It prioritizes UX over raw computation speed, making apps feel smoother and more professional. Next time your React app feels sluggish during large updates, consider marking some updates as transitions—you might be surprised by the difference.

CTA:
Have you tried useTransition yet? Share your experiences or tricky edge cases in the comments—I’d love to hear how you make your React apps feel lightning-fast!

Rendering Strategies in Next.js: CSR, SSR, SSG, ISR Explained

Sachin Maurya — Thu, 18 Sep 2025 12:41:25 +0000

Next.js gives us the flexibility to decide how each page should be rendered.
That flexibility is powerful — but also confusing if you don’t know the tradeoffs.

In this post, let’s break down the 4 main rendering strategies in Next.js with examples and use cases.

1. Client-Side Rendering (CSR)

How it works:

Page loads with minimal HTML.
Data is fetched in the browser using useEffect or similar hooks.

import { useEffect, useState } from "react";

export default function Profile() {
  const [user, setUser] = useState(null);

  useEffect(() => {
    fetch("/api/user")
      .then(res => res.json())
      .then(setUser);
  }, []);

  if (!user) return <p>Loading...</p>;
  return <h1>Hello {user.name}</h1>;
}

✅ Good for: dashboards, private user pages.
❌ Bad for: SEO and initial load performance.

2. Server-Side Rendering (SSR)

How it works:

Page HTML is generated on each request.
Always up-to-date but increases server load.

export async function getServerSideProps() {
  const res = await fetch("https://api.example.com/products");
  const products = await res.json();
  return { props: { products } };
}

export default function Products({ products }) {
  return products.map(p => <p key={p.id}>{p.name}</p>);
}

✅ Good for: user-specific dashboards, search pages.
❌ Bad for: pages with high traffic but static data.

3. Static Site Generation (SSG)

How it works:

Pages are built into static HTML at build time.
Served instantly via CDN.

export async function getStaticProps() {
  const res = await fetch("https://api.example.com/blog");
  const posts = await res.json();
  return { props: { posts } };
}

✅ Good for: marketing pages, blogs, docs.
❌ Bad for: content that changes often (stock prices, news).

4. Incremental Static Regeneration (ISR)

How it works:

Pages are pre-rendered statically, then revalidated on a schedule.
Combines the speed of SSG with freshness of SSR.

export async function getStaticProps() {
  const res = await fetch("https://api.example.com/products");
  const products = await res.json();
  return { props: { products }, revalidate: 60 }; // revalidate every 60s
}

✅ Good for: product catalogs, dashboards, news feeds.
❌ Requires caching strategy & CDN setup to be effective.

Choosing the Right Strategy

Strategy	Speed	Freshness	SEO	Best Use Case
CSR	Slow	Fresh	Poor	Private dashboards
SSR	Medium	Fresh	Good	User-specific pages
SSG	Fast	Stale	Great	Blogs, docs
ISR	Fast	Semi-fresh	Great	Product listings

Closing Thoughts

The beauty of Next.js is that you don’t need a one-size-fits-all solution.
You can mix rendering strategies across routes to balance speed, freshness, and scalability.

👉 Pro tip: Start with SSG/ISR for performance, and use SSR/CSR only where absolutely necessary.

💬 Which rendering strategy has worked best in your projects — and where did it fail?

DEV Community: Sachin Maurya

How I Got My Portfolio to 100 PageSpeed on Mobile and Desktop

1. I reduced unnecessary client-side work

2. I kept the UI simple

3. I cleaned up SEO metadata

4. I improved accessibility

5. I added better error and offline states

6. I checked with GTmetrix too

7. I kept performance features minimal

8. I verified everything before shipping

What I learned

Building a Multi-Layer Caching Strategy in Next.js App Router: From Static to Real-Time

Understanding Next.js Caching Layers

Layer 1: Fully Static Pages with force-static

Layer 2: Incrementally Static Pages with ISR

Step 1 – Basic ISR

Step 2 – On-Demand Revalidation

Layer 3: Personalized Dashboards – No Server Cache

Layer 4: Real-Time Components with Streaming

Component Structure

Wrapping in Suspense

The Hybrid Page Problem

Our Solution: Isolate Caching Boundaries

Monitoring & Debugging

1. Lighthouse + Web Vitals

2. Custom Cache Logging

3. Vercel Analytics

Results & Metrics

Lessons Learned

Final Thoughts

A More Structured Version of Frontend Master Prep Series

I just shipped v3.0 of Frontend Master Prep Series — Study Paths, 374+ Q&A, 65 Coding Problems & 500+ Flashcards

What’s new in v3.0?

1. Guided Quick Start paths

2. A cleaner content model (with real numbers)

✅ Core Q&A

✅ Coding Problems

✅ Flashcards + Web App

3. A dev-friendly, scalable structure

4. Study paths baked into the README

The GitHub repo

Why this version matters

What’s next?

Why I keep building this

The 7 Mistakes I Made as a Junior Frontend Developer (and the Engineering Fixes That Helped Me Grow Faster)

1. Focusing on UI output instead of understanding the architecture

2. Copy–pasting solutions without understanding internals

3. Treating performance as a final step instead of a design constraint

4. Over-engineering small features

5. Taking CSS lightly

6. Random learning with no system

7. Ignoring accessibility until a real project forced me to care

Why I Wrote This

I just shipped v2.0 of Frontend Master Prep Series — 1,020+ Q&A + 185 coding problems + 600 flashcards

What’s new in v2.0?

GitHub Repo

Why this matters

What’s next?

Why I built this

650+ Frontend Interview Questions (JavaScript, React, Next.js & More) — My Complete Prep Journey

🔍 What’s Inside

📘 The GitHub Repository

🧩 How I Built It

💬 What’s Next

🧠 Why I Wrote This

frontend #react #nextjs #javascript #webdevelopment #career #interviewprep #learningjourney

The Cost of Re-Renders: How to Make React Apps Actually Reactive

Introduction

1. Every Re-Render Has a Cost

2. The Silent Villain: Shared State

3. Memoization Isn’t a Silver Bullet

4. Localize, Slice, and Select

5. Fine-Grained Reactivity Is the Future

6. Measuring Re-Render Costs

7. The Real Goal: Flow, Not Frames

Conclusion

Why I Wrote This

Optimizing for Perceived Performance: The Psychology Behind Fast UIs

1. Performance ≠ Perception

2. Skeletons, Placeholders, and the Illusion of Speed

Layer 1: Fully Static Pages with `force-static`