DEV Community: Shreyash Tripathi

Building a job portal with Next.js 15 route handlers: auth, applications, and the schema behind them

Shreyash Tripathi — Sun, 18 Oct 2026 11:39:57 +0000

I built a job portal on my own, end to end: job seekers search, save and apply for jobs, employers post openings, and everyone gets a dashboard. It's a single Next.js 15 app (App Router, TypeScript) where the API lives next to the pages as route handlers.

People sometimes assume a "job board" means the MERN stack. This one isn't: there's no Express server and no MongoDB. The backend is Next.js route handlers, and the data model is relational PostgreSQL.

This post walks through the real code, then ends honestly: the live demo is a prototype, and here's exactly what I'd change before it handled real users.

Live demo: v0-mern-job-portal-one.vercel.app
Source: github.com/Yaminam/jobportal
Full case study: shreyashtripathi.in/projects/mern-job-portal

The shape of the app

app/
  api/
    auth/register/route.ts   POST  create account (bcrypt)
    auth/login/route.ts      POST  check password, sign JWT
    jobs/route.ts            GET   search + filter jobs
    applications/route.ts    GET / POST  list + apply
    profile/route.ts
    resume/route.ts
  jobs/  companies/  dashboard/  post-job/  profile/  resume/ ...
scripts/
  create-database.sql        8-table PostgreSQL schema
  seed-data.sql

Twelve pages, six route handlers, one schema. Keeping the API inside the Next.js app means one deploy on Vercel, one TypeScript codebase and no CORS setup.

1. Registration: validate, then hash

The register handler checks the required fields, confirms the two passwords match, rejects a duplicate email, and only then hashes the password with bcrypt at 12 salt rounds:

// app/api/auth/register/route.ts
export async function POST(request: NextRequest) {
  const body = await request.json()

  const requiredFields = ["firstName", "lastName", "email", "password", "userType"]
  for (const field of requiredFields) {
    if (!body[field]) {
      return NextResponse.json({ error: `${field} is required` }, { status: 400 })
    }
  }

  if (body.password !== body.confirmPassword) {
    return NextResponse.json({ error: "Passwords do not match" }, { status: 400 })
  }

  const hashedPassword = await bcrypt.hash(body.password, 12)
  // ...save the user, then strip the hash before responding
  const { password, ...userResponse } = newUser
  return NextResponse.json({ message: "User registered successfully", user: userResponse }, { status: 201 })
}

Two small habits matter here. The password hash never leaves the server: it's destructured out of the response object. And userType (jobseeker or employer) is set at sign-up, because the two roles see different parts of the app.

2. Login: one error message for both failures

// app/api/auth/login/route.ts
const user = users.find((u) => u.email === body.email)
if (!user) {
  return NextResponse.json({ error: "Invalid email or password" }, { status: 401 })
}

const isPasswordValid = await bcrypt.compare(body.password, user.password)
if (!isPasswordValid) {
  return NextResponse.json({ error: "Invalid email or password" }, { status: 401 })
}

const token = jwt.sign(
  { userId: user.id, email: user.email, userType: user.userType },
  JWT_SECRET,
  { expiresIn: "7d" },
)

"Unknown email" and "wrong password" return the same message on purpose, so the login form can't be used to check which emails have accounts. The token carries the user's role, so later requests can tell an employer from a job seeker without another lookup.

3. Job search: filters as query parameters

The jobs handler reads search, location and type from the URL and narrows the list step by step. Search matches the title, the company or any skill tag:

// app/api/jobs/route.ts
export async function GET(request: NextRequest) {
  const { searchParams } = new URL(request.url)
  const search = searchParams.get("search")
  const location = searchParams.get("location")
  const type = searchParams.get("type")

  let filteredJobs = jobs

  if (search) {
    const q = search.toLowerCase()
    filteredJobs = filteredJobs.filter(
      (job) =>
        job.title.toLowerCase().includes(q) ||
        job.company.toLowerCase().includes(q) ||
        job.tags.some((tag) => tag.toLowerCase().includes(q)),
    )
  }
  if (location) {
    filteredJobs = filteredJobs.filter((job) => job.location.toLowerCase().includes(location.toLowerCase()))
  }
  if (type) {
    filteredJobs = filteredJobs.filter((job) => job.type.toLowerCase() === type.toLowerCase())
  }
  // ...return the filtered list
}

Because filters live in the query string, a filtered search is just a URL: it can be bookmarked, shared or cached.

4. Applying: no double applications

A double click or a retried request shouldn't create two applications. The handler checks first:

// app/api/applications/route.ts
const existingApplication = applications.find(
  (app) => app.jobId === body.jobId && app.userId === body.userId,
)
if (existingApplication) {
  return NextResponse.json({ error: "You have already applied to this job" }, { status: 400 })
}

The schema enforces the same rule at the database level, which is the check that actually holds under concurrent requests:

CREATE TABLE IF NOT EXISTS applications (
    id SERIAL PRIMARY KEY,
    job_id INTEGER REFERENCES jobs(id),
    user_id INTEGER REFERENCES users(id),
    cover_letter TEXT,
    resume_url VARCHAR(500),
    status VARCHAR(50) DEFAULT 'applied' CHECK (status IN
      ('applied', 'under_review', 'interview_scheduled', 'rejected', 'accepted')),
    applied_at TIMESTAMP DEFAULT CURRENT_TIMESTAMP,
    UNIQUE(job_id, user_id) -- prevent duplicate applications
);

The CHECK on status also means the application pipeline can only move through states the app knows how to display.

5. The data model

A job board's data is very connected, which is why I chose a relational schema. Eight tables:

Table	Holds	Key relations
`users`	both roles, `CHECK (user_type IN ('jobseeker','employer'))`
`companies`	company profiles	`created_by → users`
`jobs`	openings, salary range, `skills TEXT[]`, remote flag	`company_id → companies`, `posted_by → users`
`applications`	status pipeline	`UNIQUE(job_id, user_id)`
`saved_jobs`	bookmarks	`UNIQUE(user_id, job_id)`
`user_skills`	skill + proficiency	`user_id → users`
`work_experience`	past roles	`user_id → users`
`education`	degrees	`user_id → users`

Constraints like CHECK and UNIQUE push the business rules down into the database, so they hold even if a future API route forgets to check.

What I'd fix before real users (the honest part)

The live demo is a working prototype. These are the gaps, in the order I'd close them:

Connect the schema. The route handlers use in-memory arrays and the dashboard keeps saved jobs and applications in localStorage. The SQL schema is written but not wired up. Next step: a Postgres connection (or Prisma) in each handler.
No fallback secret. The login route falls back to a hard-coded string when JWT_SECRET is missing. That should be a startup error instead, so a misconfigured deploy fails loudly:

   const JWT_SECRET = process.env.JWT_SECRET
   if (!JWT_SECRET) throw new Error("JWT_SECRET is not set")

Verify the token on protected routes. POST /api/applications takes userId from the request body. It should come from the verified JWT, otherwise anyone can apply on someone else's behalf. Store the token in an httpOnly cookie rather than localStorage.
Schema validation. Swap the manual "field is required" loops for a Zod schema per route: one place for types, required fields and email format.
Search in the database. Filtering in JavaScript is fine for a demo list. With real data it belongs in SQL (ILIKE, or Postgres full-text search), with pagination.

Takeaways

Next.js route handlers are enough of a backend for a product like this: one codebase, one deploy.
Put business rules in the schema (UNIQUE, CHECK, foreign keys), not only in API code.
Never trust identity from the request body; take it from the verified token.

The full case study, with the architecture and results, is on my site: shreyashtripathi.in/projects/mern-job-portal.

I'm Shreyash Tripathi, a Full-Stack Developer & UI/UX Engineer in Noida, India. I build with React, Next.js, TypeScript, Node.js and PostgreSQL. More of my work: shreyashtripathi.in.

Building a zero-knowledge vault in the browser with WebCrypto (no crypto libraries)

Shreyash Tripathi — Sun, 27 Sep 2026 11:49:40 +0000

At work I built an internal tool for our team's hardware inventory, service logins, environment variables and vendor bills. Because it holds credentials, I gave it one hard rule: the database must never see plaintext. Not the passwords, not the titles, not even which services we use.

The whole encryption layer runs in the browser on the built-in WebCrypto API, with no third-party crypto libraries. This post walks through the design and the real code, trimmed for length.

The shape of it

master password + per-vault salt  --PBKDF2-SHA256 x600k-->  256-bit AES key
each record                       --AES-256-GCM--------->  { iv, ciphertext }
each attached file                --AES-256-GCM--------->  opaque blob

The backend (Postgres plus object storage) stores iv and ciphertext, nothing else. Titles, usernames, URLs and owners all live inside the ciphertext, so the database leaks no metadata either. The key exists only in the tab's memory and is dropped when the vault locks.

1. Password to key

PBKDF2 turns the master password into an AES key. The slowness is the point: 600,000 iterations of SHA-256 makes every password guess expensive.

export async function deriveKey(password: string, saltBase64: string, iterations: number) {
  const material = await crypto.subtle.importKey(
    "raw", new TextEncoder().encode(password), "PBKDF2", false, ["deriveKey"]
  );
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt: fromBase64(saltBase64), iterations, hash: "SHA-256" },
    material,
    { name: "AES-GCM", length: 256 },
    false,                    // non-extractable: the key can never be read back out
    ["encrypt", "decrypt"]
  );
}

extractable: false matters: even code running in the page can use the key, but can't export its bytes.

2. Sealing and opening records

Each record is JSON, encrypted with AES-256-GCM and a fresh 12-byte IV:

export async function seal(key: CryptoKey, value: unknown) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const plaintext = new TextEncoder().encode(JSON.stringify(value));
  const buffer = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, plaintext);
  return { iv: toBase64(iv), ciphertext: toBase64(new Uint8Array(buffer)) };
}

export async function open<T>(key: CryptoKey, sealed: { iv: string; ciphertext: string }) {
  try {
    const buffer = await crypto.subtle.decrypt(
      { name: "AES-GCM", iv: fromBase64(sealed.iv) }, key, fromBase64(sealed.ciphertext)
    );
    return JSON.parse(new TextDecoder().decode(buffer)) as T;
  } catch {
    // A failed GCM tag check is what a wrong password looks like.
    throw new DecryptionError();
  }
}

GCM is authenticated encryption: if a single byte of the ciphertext is changed, or the key is wrong, decryption fails instead of returning garbage.

To tell the user "wrong password" without trying every record, the vault stores one small verifier: a known string sealed under the key. Unlocking just tries to open it.

3. More than one password, without re-encrypting anything

The first version had a single master password. Then the team wanted separate passwords per person. The naive fix re-encrypts every record under a new key, which is slow, risky, and has to happen again whenever someone leaves.

Instead I added a key envelope. The vault key stays exactly what it always was, and each person stores their own copy of it, sealed under a key derived from their password:

// The vault key as raw bytes (same PBKDF2 output that deriveKey uses internally)
const vaultKeyBytes = await crypto.subtle.deriveBits(
  { name: "PBKDF2", salt, iterations, hash: "SHA-256" }, material, 256
);

// Each account: wrap those bytes under a key derived from that account's password
export async function wrapSecret(kek: CryptoKey, raw: ArrayBuffer) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const buffer = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, kek, raw);
  return { iv: toBase64(iv), ciphertext: toBase64(new Uint8Array(buffer)) };
}

Adding or removing a person rewrites one small record and touches no data. Because deriveBits(..., 256) returns byte-for-byte what deriveKey uses internally, records written before the change still open.

4. Files: encrypt before upload, and skip base64

Invoices (PDFs and photos) are encrypted in the tab before upload, so object storage only ever holds noise under random names:

export async function sealBytes(key: CryptoKey, bytes: ArrayBuffer) {
  const iv = crypto.getRandomValues(new Uint8Array(12));
  const buffer = await crypto.subtle.encrypt({ name: "AES-GCM", iv }, key, bytes);
  return { iv: toBase64(iv), data: new Blob([buffer]) };
}

Files stay as raw bytes instead of going through base64 like the JSON records. Base64 grows a file by a third, which on a small storage plan is a third of the budget spent on nothing.

5. Share links that are useless if leaked

Sometimes one credential has to go to one person. A share link is derived from two things: a random token in the URL fragment (the part after #, which browsers never send to a server) and the recipient's name:

async function deriveShareKey(tokenBytes: Uint8Array, recipientName: string) {
  // The token is already unique, so its hash doubles as the salt.
  const salt = new Uint8Array(await crypto.subtle.digest("SHA-256", tokenBytes));
  const name = new TextEncoder().encode("\0" + normalizeName(recipientName));

  const material = new Uint8Array(tokenBytes.length + name.length);
  material.set(tokenBytes, 0);
  material.set(name, tokenBytes.length);

  const base = await crypto.subtle.importKey("raw", material, "PBKDF2", false, ["deriveKey"]);
  return crypto.subtle.deriveKey(
    { name: "PBKDF2", salt, iterations: 300_000, hash: "SHA-256" },
    base, { name: "AES-GCM", length: 256 }, false, ["encrypt", "decrypt"]
  );
}

The name is never stored, not even as a hash; it's only an input to the key. A wrong name produces a wrong key, and the GCM tag fails. So a link pasted into the wrong chat is useless to whoever finds it, and the server has nothing to check a name against. The 300,000 iterations make guessing names against a leaked link slow.

6. The smallest possible supply chain

Every library that touches plaintext is a risk, so I kept that set small on purpose:

No crypto libraries. WebCrypto is built into every browser and is audited far more than any npm package.
A hand-written .xlsx reader on the browser's DecompressionStream instead of a spreadsheet library, for importing old spreadsheets.
Service logos bundled as path data, never fetched from a logo CDN. Asking a third party for a Stripe logo would tell them the vault holds a Stripe account.

What this design doesn't protect against

Zero-knowledge is strong, but it isn't magic:

XSS is the real threat. Anything that can run script in the unlocked tab can use the key. A strict Content Security Policy and few dependencies matter more than the cipher choice.
You trust the JavaScript you're served. A compromised deploy could ship code that leaks the password. Deploy access has to be protected like the data.
No password recovery. Lose every password and nobody can open the data, not even whoever owns the database. That's the point, but people need to know it upfront.
PBKDF2, not Argon2. WebCrypto has no memory-hard KDF, so PBKDF2 with a high iteration count is the best built-in option.

Takeaways

WebCrypto is enough for a serious vault: PBKDF2, AES-GCM, deriveBits and non-extractable keys cover it.
Encrypt metadata too. A database of encrypted passwords with plaintext titles still tells an attacker which services to target.
Key envelopes make multi-user access and offboarding cheap.
URL fragments are a great place for secrets that must reach the browser but never the server.

I wrote up the whole tool (asset inventory with QR labels, invoice OCR, spend tracking) as a case study on my portfolio: shreyashtripathi.in/projects/asset-credential-vault. I'm a Frontend Developer and UI/UX Engineer in Noida. Questions about browser crypto are welcome in the comments.

Building a real-time multiplayer drawing game with Socket.IO: rooms, timers, scoring (and the bugs I'd fix)

Shreyash Tripathi — Sat, 26 Sep 2026 08:38:51 +0000

SketchRace is a multiplayer drawing and guessing game: one player draws a secret word, everyone else races to guess it in the chat. A teammate and I built it; I worked on the game server, a Node.js + Express app with Socket.IO, and my teammate built the Next.js frontend.

This post walks through how the server works, with the real code, and ends with the bugs I'd fix if I built it again.

The whole game lives in memory

There's no database. One Node process keeps all game state in four plain objects, keyed by room id:

const rooms = {};          // players, owner, round, current drawer, current word
const points = {};         // points[roomId][playerName]
const correctGuessers = {};// who has already guessed this turn
const activeTimers = {};   // the running setInterval handles per room

const wordSelect = 7;  // seconds to pick a word
const wordGuess = 45;  // seconds to guess
const maxRounds = 3;
const hintTime = 20;   // reveal a hint when 20 s are left

For a game where a match lasts a few minutes and nobody needs history, that's enough, and it keeps every read and write instant.

Rooms

Each match has its own URL (/room/[roomId]). Joining puts the socket into a Socket.IO room and creates the room state the first time:

socket.on("join", ({ roomId, name }) => {
  socket.join(roomId);
  if (!rooms[roomId]) {
    rooms[roomId] = {
      users: [],
      ownerId: socket.id,
      gamestarted: false,
      currentDrawerIndex: 0,
      currentRound: 1,
      currentWord: "",
      hintRevealed: false,
    };
  }
  rooms[roomId].users.push({ id: socket.id, name });
  io.to(roomId).emit("user-list", { users: rooms[roomId].users, ownerId: rooms[roomId].ownerId });
});

When the last player disconnects, the room, its guessers and its timers are deleted, so nothing leaks between matches.

Live drawing: send strokes, not pictures

Sending the canvas as an image after every stroke would be slow and heavy. Instead each client sends tiny line segments, and the server relays them to everyone else in the room:

socket.on("drawing", ({ roomId, prevX, prevY, x, y, brushColor, brushSize }) => {
  socket.to(roomId).emit("drawing", { prevX, prevY, x, y, brushColor, brushSize });
});

socket.to(roomId) broadcasts to the room except the sender, who has already drawn the line locally. Each segment is a handful of numbers, so the other canvases keep up in real time.

The server owns the clock

If every browser ran its own timer, clocks would drift and players would see different time left. So the server runs the only clock and broadcasts a tick every second:

activeTimers[roomId].selectionTimer = setInterval(() => {
  timeLeft--;
  io.to(roomId).emit("word-selection-time", timeLeft);
  if (timeLeft === 0) {
    clearInterval(activeTimers[roomId].selectionTimer);
    wordGuessingTime(roomId);
  }
}, 1000);

A turn is: 7 seconds for the drawer to pick a word, then 45 seconds of guessing. After each turn the pen moves to the next player, and after everyone has drawn, the round counter goes up. After 3 rounds the server sends the final scores:

// proceedToNextTurn, simplified
room.currentDrawerIndex = (room.currentDrawerIndex + 1) % room.users.length;
if (room.currentDrawerIndex === 0) {
  room.currentRound++;
  if (room.currentRound > maxRounds) {
    io.to(roomId).emit("final-scores", points[roomId]);
    io.to(roomId).emit("game-ended");
    return;
  }
}
io.to(roomId).emit("clear-canvas");
wordSelectionTime(roomId);

Hints, sent only to guessers

When 20 seconds are left, the server reveals two random letters of the word. It sends the hint per player, skipping the drawer, using each socket's own id as a room:

room.users.forEach((user) => {
  if (user.id !== currentDrawer.id) {
    io.to(user.id).emit("word-hint", { hint: maskedWord });
  }
});

Scoring that rewards both sides

The scoring tries to be fair to guessers and the drawer:

Guesser: 10 points + a time bonus of up to 10, reduced by 20% if the hint was already shown.
Drawer: +5 for every correct guess, +10 more if everyone guesses it.
End of turn: the drawer also gets a bonus proportional to the share of players who got it.

If every guesser gets the word before time runs out, the server stops the timer and moves to the next turn after a 3-second pause.

What I'd fix if I built it again

Reading the code again with fresh eyes, four things stand out.

1. The time bonus is almost always 0. Time left is calculated from the timer's _idleTimeout, which is the interval (1000 ms), not the time remaining. So timeRemaining works out to about 1 second, and the "up to 10" bonus rounds to 0. The fix is to store when the turn ends and compute from that:

room.turnEndsAt = Date.now() + wordGuess * 1000;
// on a correct guess:
const timeRemaining = Math.max(0, (room.turnEndsAt - Date.now()) / 1000);

2. Every player receives the secret word. word-selected broadcasts word-to-guess to the whole room, so anyone with dev tools open can read it. The word should go only to the drawer, with guesses checked on the server.

3. The server trusts the client's correct-guess. A client can claim a correct guess without typing the word. With the word kept on the server (fix 2), the server can compare each chat message itself and award points only when it matches.

4. State in memory means one server. Everything lives in one Node process, so a restart ends every game, and it can't scale across instances. The Socket.IO Redis adapter plus Redis-backed room state would fix both.

None of these broke the game for friends playing together, but they're exactly the things that matter once strangers join.

What I learned

Make the server the single source of truth for time, turns and scores; clients just render what they're told.
Send the smallest possible update (a line segment, a tick) instead of whole states.
Never trust the client with anything that decides who wins.

You can play the game at sketchrace.vercel.app, and read the project case study on my portfolio at shreyashtripathi.in/projects/sketchrace. I'm a Frontend Developer and UI/UX Engineer in Noida. Questions about real-time games with Socket.IO are welcome in the comments.

tags:

cover_image: https://direct_url_to_image.jpg

Use a ratio of 100:42 for best results.

published_at: 2026-09-26 08:38 +0000

How I made my React portfolio 2x faster (Lighthouse 30 to 80) by prerendering a Vite app

Shreyash Tripathi — Sat, 26 Sep 2026 08:15:28 +0000

My portfolio is a Vite + React single-page app with a cyberpunk terminal theme: matrix rain, a live terminal, mini-games, easter eggs. It looked great on my laptop. Then I ran Lighthouse on mobile:

Metric (mobile)	Before
Performance	30
Largest Contentful Paint	8.1 s
Total Blocking Time	3,390 ms
Words a crawler sees without JavaScript	134

Two problems in one: the site was slow, and search engines and AI crawlers that don't run JavaScript saw an empty <div id="root"></div>. Here's what I changed, in order of impact.

1. Prerender the page at build time

A Vite SPA sends an empty shell, then builds the page in the browser. Instead, I render the React tree to HTML during the build and inject it into index.html, so the first byte already contains the real content.

First, an SSR entry that renders the same tree as the app, with StaticRouter instead of BrowserRouter:

// src/entry-server.tsx
import { renderToString } from "react-dom/server";
import { StaticRouter } from "react-router-dom";
import { AppShell, AppRoutes } from "./App";

export function render(url = "/"): string {
  return renderToString(
    <AppShell>
      <StaticRouter location={url}>
        <AppRoutes />
      </StaticRouter>
    </AppShell>
  );
}

Then a small Node script builds it and writes one HTML file per route:

// scripts/prerender.mjs (simplified)
const { render } = await import("../dist-ssr/entry-server.js");
const template = await readFile("dist/index.html", "utf8");

for (const page of pages) {
  const html = template.replace(
    '<div id="root"></div>',
    `<div id="root">${render(page.url)}</div>`
  );
  await writeFile(`dist/${page.file}`, html);
}

"build": "vite build && vite build --ssr src/entry-server.tsx --outDir dist-ssr && node scripts/prerender.mjs"

On the client, hydrate instead of rendering from scratch, so React reuses the HTML that's already painted:

// src/main.tsx
const container = document.getElementById("root")!;
if (container.hasChildNodes()) hydrateRoot(container, <App />);
else createRoot(container).render(<App />);

Result: crawlers now get 1,007 words instead of 134, and the text paints before any JavaScript runs.

Hydration gotchas I hit

Animated text started empty. My "decrypt" name effect initialised its state to "", so the prerendered <h1> was blank. Fix: start from the real text and scramble inside useEffect.
React error #419. renderToString can't wait for React.lazy, so a lazy chart inside <Suspense> made React bail out to client rendering. Fix: only render the lazy component after mount (see step 3), so server and client both render the fallback first.
Server and client trees must match exactly. Toasters and providers from App.tsx have to be in the SSR tree too, or hydration fails. I split App into a shared AppShell and AppRoutes used by both.

2. Load the fun stuff after the page is visible

The terminal, games, confetti and cursor effects were all in the main bundle and mounted immediately. Nobody needs a Snake game in the first second, so they now load when the browser is idle:

const InteractiveLayer = lazy(() => import("@/components/InteractiveLayer"));

const useIdleMount = () => {
  const [ready, setReady] = useState(false);
  useEffect(() => {
    const ric = window.requestIdleCallback;
    if (ric) {
      const id = ric(() => setReady(true), { timeout: 2500 });
      return () => window.cancelIdleCallback(id);
    }
    const t = setTimeout(() => setReady(true), 1200);
    return () => clearTimeout(t);
  }, []);
  return ready;
};

// in the page
{interactive && (
  <Suspense fallback={null}>
    <InteractiveLayer />
  </Suspense>
)}

I also removed an auto-playing boot screen that covered the page for ~3 seconds on every first visit. It was fun. It was also my LCP.

3. Load heavy libraries only near the viewport

The skills radar chart pulls in recharts (~354 KB). It now loads only when its section is within 400px of the screen:

const { ref, isVisible: near } = useReveal<HTMLDivElement>({
  threshold: 0,
  rootMargin: "400px 0px",
});

<div ref={ref}>
  {near ? (
    <Suspense fallback={<RadarSkeleton />}>
      <SkillsRadar />
    </Suspense>
  ) : (
    <RadarSkeleton />
  )}
</div>

4. Fix the image nobody noticed

My profile photo was a 1.5 MB PNG displayed at 288px. Converted to a 600×600 WebP it's 12 KB, and explicit width/height stop layout shift. The Open Graph image went from 275 KB to 89 KB.

5. Make the animations run on the GPU

Lighthouse's "non-composited animations" audit found two culprits:

A background grid animated with background-position, which repaints the whole screen every frame. I moved it to an oversized layer animated with transform:

'grid-pan': {
  '0%':   { transform: 'translate3d(0,0,0)' },
  '100%': { transform: 'translate3d(40px,40px,0)' },
},

A pulsing ring animated with box-shadow. It's now a pseudo-element that animates transform and opacity.

I also replaced three huge blur(130px) glow blobs with radial-gradient backgrounds, which look nearly identical but cost almost nothing to paint on phones.

6. Stop fonts from blocking the first paint

Three Google Font families were a render-blocking stylesheet. Now they're preloaded, applied from a small async script, and display=swap shows fallback text immediately.

The results

Metric (mobile)	Before	After
Performance	30	80
Largest Contentful Paint	8.1 s	3.4 s
Total Blocking Time	3,390 ms	240 ms
Cumulative Layout Shift	0.014	0
SEO / Accessibility / Best Practices	100 / 100 / 100	100 / 100 / 100
Words visible without JavaScript	134	1,007

(Lighthouse 12, mobile emulation, lab data.)

And the interactive terminal, games and easter eggs all still work — they just wait their turn.

Bonus: once pages are real HTML, SEO gets easy

Because every route is prerendered, I could give each project its own case-study page with its own title, description, canonical URL and JSON-LD structured data, all generated at build time from the same data file the UI uses. Add a sitemap and an llms.txt, and search engines and AI assistants can actually read the site.

You can see the result at shreyashtripathi.in — try the terminal (it loads after the page does). I'm a Frontend Developer and UI/UX Engineer in Noida; if you have questions about prerendering a Vite app, ask in the comments.