DEV Community: Osibajo Inioluwa

Optimizing Performance Without Falling for the RSC Hype

Osibajo Inioluwa — Mon, 21 Sep 2026 08:21:45 +0000

Optimizing Performance Without Falling for the RSC Hype

Today's nuggets – 2026‑09‑21

How Preply saved $200 k / yr and cut INP in half while staying on the Pages Router.

The React Server Components (RSC) and the new App Router have generated a lot of excitement. Many teams assume that moving to these features is the fastest way to improve Core Web Vitals, especially Interaction‑to‑Next‑Paint (INP).

Preply’s engineering team proved otherwise. By staying on the stable Pages Router and applying disciplined performance work, they reduced INP from ≈ 300 ms to ≈ 150 ms and saved ~ $200 k per year in cloud spend.

The takeaway is simple: measure, prioritize, and optimize the real bottlenecks before you adopt new abstractions. This article walks through the methodology, the concrete changes they made, and a checklist you can apply to any Next.js codebase.

1. Why the RSC/App Router Hype Is Misleading

Claim	Reality
Server‑rendered components automatically reduce client‑side JavaScript	RSC only moves the rendering of some components to the server. The overall bundle size can stay the same or even increase if you add more server‑only data fetching.
App Router replaces `getStaticProps`/`getServerSideProps` with a unified API	The new `fetch`‑based data layer is powerful, but it also introduces streaming and edge‑caching complexities that require careful tuning.
Switching promises immediate Core Web Vitals gains	Vitals are driven by real user interactions, network latency, and critical rendering path. Without addressing those, a framework upgrade is just a cosmetic change.

Preply’s engineers wanted hard data before committing to a migration. Their process is worth replicating.

2. Baseline: Measuring INP in the Wild

2.1 Instrumentation

Web Vitals SDK – web-vitals npm package, reporting INP to a custom analytics endpoint.
Real‑User Monitoring (RUM) – Captured per‑page, per‑session data for the top 20 traffic‑heavy routes.
Synthetic Lighthouse – Baseline for lab‑controlled comparison, not a decision driver.

import { onINP } from 'web-vitals';

onINP(metric => {
  fetch('/api/collect-vitals', {
    method: 'POST',
    body: JSON.stringify(metric),
    keepalive: true,
  });
});

2.2 Findings

Average INP = 298 ms across the 20 most visited pages.
70 % of the INP budget was consumed by long‑running JavaScript handlers (e.g., on‑click debounced search, analytics initialization).
The remaining 30 % came from large layout shifts caused by late‑loading images and dynamic content.

The team set two concrete targets:

INP < 180 ms for the top 20 pages (the threshold for “good” in Chrome UX Report).
Reduce server‑side compute cost by at least 15 % (to hit the $200 k saving).

3. The Optimization Playbook

3.1 Trim the JavaScript Payload

Tree‑shake unused libraries – Enabled next-plugin-optimized-images and ran npm dedupe.
Dynamic import for heavy UI widgets – Search box, rich text editor, and analytics were lazy‑loaded.

// pages/search.tsx
import dynamic from 'next/dynamic';
const SearchWidget = dynamic(() => import('../components/SearchWidget'), {
  ssr: false,
  loading: () => <p>Loading…</p>,
});

Remove polyfills – Modern browsers cover most features; disabled the polyfills flag in next.config.js.

module.exports = {
  experimental: {
    polyfillsOptimization: false,
  },
};

Result: Bundle size fell from 2.8 MB to 1.9 MB gzipped, shaving ~ 80 ms off INP.

3.2 Prioritize Critical Rendering Path

Preload key fonts – Added <link rel="preload" as="font" href="/fonts/inter.woff2" crossorigin> to _document.js.
Inline above‑the‑fold CSS – Extracted the minimal CSS required for the hero section using next-critical.

// pages/_document.js
import Document, { Html, Head, Main, NextScript } from 'next/document';

export default class MyDoc extends Document {
  render() {
    return (
      <Html>
        <Head>
          <link rel="preload" href="/fonts/inter.woff2" as="font" type="font/woff2" crossOrigin="anonymous" />
          <style dangerouslySetInnerHTML={{ __html: criticalCSS }} />
        </Head>
        <body>
          <Main />
          <NextScript />
        </body>
      </Html>
    );
  }
}

Result: First Contentful Paint (FCP) dropped 120 ms, which indirectly reduced INP because the UI became responsive sooner.

3.3 Optimize Data Fetching on the Pages Router

The team resisted moving to the App Router’s fetch‑based server components and instead refined the classic data‑fetching APIs.

Issue	Fix
`getServerSideProps` ran on every request, causing cold‑start latency on Vercel Edge Functions.	Switched to Incremental Static Regeneration (ISR) where content was cacheable for 10 min.
Large payloads for the homepage (≈ 500 KB JSON).	Implemented selective field fetching on the GraphQL layer (`query { lessons { id title } }`).
Redundant calls to third‑party translation API.	Added server‑side memoization using `lru-cache`.

// pages/index.tsx
export async function getStaticProps() {
  const lessons = await fetchLessons({ fields: ['id', 'title'] });
  return {
    props: { lessons },
    revalidate: 600, // 10 minutes
  };
}

Result: Server‑side response time fell from 420 ms to 180 ms, eliminating a major INP contributor.

3.4 Image Delivery & Layout Stability

Next/Image with layout="responsive" – Ensured intrinsic aspect ratios, eliminating layout shifts.
CDN‑based WebP conversion – Served AVIF/WebP when supported, falling back to JPEG otherwise.

import Image from 'next/image';

<Image
  src="/images/hero.jpg"
  width={1200}
  height={630}
  layout="responsive"
  priority
  placeholder="blur"
/>

Result: Cumulative Layout Shift (CLS) dropped from 0.18 to 0.04, removing its impact on INP.

3.5 Edge Middleware for A/B Experiments

Instead of moving the entire page to an RSC, the team used Edge Middleware to serve pre‑computed variants for a limited set of experiments.

// middleware.ts
import { NextResponse } from 'next/server';

export async function middleware(req) {
  const url = req.nextUrl.clone();
  if (url.pathname.startsWith('/search')) {
    const variant = await getExperimentVariant(req.ip);
    url.searchParams.set('variant', variant);
    return NextResponse.rewrite(url);
  }
  return NextResponse.next();
}

Edge execution cost is ~ $0.000005 per request, negligible at scale, and it avoided a full migration to the App Router.

4. Financial Impact

Metric	Before	After	Δ
Monthly compute (Vercel Serverless)	$28,400	$20,500	-$7,900
Bandwidth (CDN)	3.2 TB	2.6 TB	-0.6 TB
Estimated annual savings	—	$200 k	—

The savings stemmed mainly from ISR (fewer SSR invocations) and smaller payloads. The performance gains were a by‑product, not the primary driver of cost reduction.

5. When RSC & App Router Actually Make Sense

Scenario	Recommended
Heavy data‑heavy pages where streaming is required (e.g., infinite scroll feeds)	App Router with `fetch` and `use` hooks.
Team wants to co‑locate data fetching with component logic and can invest in streaming SSR	RSC can reduce duplication, but only after baseline performance is acceptable.
Legacy codebase heavily reliant on Pages Router	Stick with Pages Router, optimize first. Migrate only if you need features like nested layouts that App Router uniquely provides.

In short, adopt only when the feature solves a problem you already own, not because it’s the newest thing.

6. Practical Checklist for Your Next.js Project

Instrument real‑user INP before any change.
Audit JavaScript bundle – look for unused imports, large libraries, and polyfills.
Apply lazy loading to non‑critical widgets (dynamic with ssr: false).
Shift from getServerSideProps to ISR where data can be stale for ≤ 10 min.
Enforce aspect ratios for every image (layout="responsive").
Preload fonts & inline critical CSS.
Use Edge Middleware for lightweight request‑time variations instead of full SSR.
Re‑measure INP after each step; stop when you reach your target.
Only then evaluate whether RSC/App Router would provide additional value.

7. Actionable Takeaways

Metrics first, hype second – Your migration budget should be justified by a measurable gap.
Pages Router is still performant – Incremental static regeneration and disciplined bundling can rival App Router’s promises.
Cost and performance are coupled – Reducing server‑side work often yields both lower spend and better INP.
Iterative optimization beats big‑bang rewrites – Smaller, verifiable changes keep risk low and ROI high.

Conclusion

Preply’s experience shows that you don’t need React Server Components or the App Router to achieve world‑class interaction performance. By focusing on the fundamentals—payload size, critical rendering path, and efficient data fetching—the team cut INP in half and saved $200 k per year.

Use the checklist above to audit your own Next.js applications. Measure, prune, and only then consider a framework upgrade. The results will speak louder than any hype.

Source: “How Preply Improved INP on a Next.js Application Without React Server Components and App Router” – Preply Engineering

https://medium.com/preply-engineering/how-preply-improved-inp-on-a-next-js-application-without-react-server-components-and-app-router-491713149875

performance #nextjs #webvitals

Why Package Managers Keep Trying to Use Git as a Database (And Why It Always Fails)

Osibajo Inioluwa — Mon, 21 Sep 2026 05:35:10 +0000

Why Package Managers Keep Using Git as a Database (And Why It Always Fails)

Package managers need a place to store package metadata, version histories, and integrity hashes.

Many of them have chosen Git as that store. The pattern looks convenient—Git already handles versioning, is distributed, and is battle‑tested. In practice it creates more problems than it solves.

The anti‑pattern in practice

Problem	What happens when Git is used as a DB	Why a relational store is better
Concurrent writes	Git uses a single‑writer lock (`git lock`). When two processes push at the same time one fails with “could not lock ref”. The manager must retry or abort.	Relational databases provide row‑level locking and transaction isolation. Multiple writers can succeed without manual retries.
Missing indexes	Package metadata lives in plain text files (e.g., `package.json`). Searching for a package version requires scanning the entire repository or loading many objects into memory.	A relational table can index `name`, `version`, and `checksum`. A simple `SELECT` uses the index and returns in milliseconds, regardless of repo size.
Atomicity	A Git commit groups changes, but the commit is atomic only at the repository level. If a manager writes two related files and crashes after the first, the repository can end up in an inconsistent state.	A DB transaction can roll back all changes if any step fails, guaranteeing consistency.
Scalability	Large registries (hundreds of thousands of packages) blow up the `.git` directory. Object packing becomes costly and fetches slow down.	Relational engines store rows efficiently and can shard or replicate as needed.

A concrete example

Below is a minimal illustration of the same operation—adding a new package entry—implemented with Git vs. SQLite.

Using Git (pseudo‑code)

import subprocess
import json
import os

def add_package(name, version, sha):
    # Write metadata file
    pkg_path = f"packages/{name}/{version}.json"
    os.makedirs(os.path.dirname(pkg_path), exist_ok=True)
    with open(pkg_path, "w") as f:
        json.dump({"name": name, "version": version, "sha": sha}, f)

    # Commit to Git
    subprocess.run(["git", "add", pkg_path], check=True)
    subprocess.run(
        ["git", "commit", "-m", f"Add {name}@{version}"],
        check=True,
    )

Problems:

No lock handling. If two processes call add_package simultaneously, the second git commit fails with a lock error.
To find a version you must walk the packages/ tree or run git grep, both O(N) operations.

Using SQLite (real code)

import sqlite3

def init_db():
    conn = sqlite3.connect("registry.db")
    conn.execute(
        """CREATE TABLE IF NOT EXISTS packages (
               name TEXT NOT NULL,
               version TEXT NOT NULL,
               sha TEXT NOT NULL,
               PRIMARY KEY (name, version)
           )"""
    )
    conn.commit()
    return conn

def add_package(conn, name, version, sha):
    try:
        conn.execute(
            "INSERT INTO packages (name, version, sha) VALUES (?, ?, ?)",
            (name, version, sha),
        )
        conn.commit()
    except sqlite3.IntegrityError:
        raise ValueError(f"{name}@{version} already exists")

Advantages:

SQLite handles concurrency with file locks internally; multiple writers are serialized safely.
A lookup SELECT * FROM packages WHERE name=? AND version=? uses the primary‑key index and returns instantly.
The schema enforces uniqueness, preventing duplicate entries.

Why the pattern persists

Historical inertia – early npm and similar tools were built before robust, embedded DBs were common in JavaScript runtimes.
Perceived simplicity – a single Git repo feels like “just files”.
Distributed nature – Git’s push/pull model matches the idea of a decentralized registry.

These reasons are understandable, but they ignore the cost of maintaining correctness at scale.

Takeaway

Git excels at source code versioning, not at random‑access data queries or high‑concurrency writes. For a package registry:

Use a relational database (SQLite, PostgreSQL, MySQL) for the core metadata store.
Keep Git only for the immutable artifact blobs if you need content‑addressable storage.
Treat the DB as the source of truth for lookups, version resolution, and access control.

Switching away from Git as a database removes lock contention, enables indexed queries, and provides transactional safety—exactly the guarantees a package manager needs.

Source: Package managers keep using Git as a database

Next.js + Server-Side Tables Done Right

Osibajo Inioluwa — Mon, 21 Sep 2026 04:33:32 +0000

Next.js + Server‑Side Tables Done Right

Intro

Server‑side sorting, filtering, and pagination are the backbone of any production data table. With Next.js 13+ you can keep the UI declarative while letting the server do the heavy lifting. Below is a step‑by‑step guide that wires the shadcn/ui table component to a Next.js API route (or server‑action) so the browser only receives the rows it needs.

1. Set up the shadcn table component

The repo sadmann7/shadcn-table provides a fully typed table wrapper that works with React 18 and Next.js app router. Install the package and copy the component files:

npm i @shadcn/ui
# or yarn add @shadcn/ui

// components/ui/DataTable.tsx
import { Table, TableHeader, TableBody, TableRow, TableCell } from "@shadcn/ui";
import { ColumnDef, flexRender } from "@tanstack/react-table";

interface DataTableProps<TData> {
  columns: ColumnDef<TData>[];
  data: TData[];
  total: number;          // total rows in DB
  pageIndex: number;
  pageSize: number;
  onSortChange: (col: string, dir: "asc" | "desc") => void;
  onFilterChange: (col: string, value: string) => void;
  onPageChange: (newIndex: number) => void;
}
export function DataTable<TData>(props: DataTableProps<TData>) {
  const {
    columns,
    data,
    total,
    pageIndex,
    pageSize,
    onSortChange,
    onFilterChange,
    onPageChange,
  } = props;

  // Build a TanStack Table instance (client‑side only for UI state)
  const table = useReactTable({
    data,
    columns,
    getCoreRowModel: getCoreRowModel(),
    manualSorting: true,
    manualFiltering: true,
    manualPagination: true,
  });

  return (
    <div className="space-y-4">
      <Table>
        <TableHeader>
          {table.getHeaderGroups().map(headerGroup => (
            <TableRow key={headerGroup.id}>
              {headerGroup.headers.map(header => (
                <TableCell
                  key={header.id}
                  onClick={() => {
                    const col = header.column.id;
                    const dir = header.column.getIsSorted()
                      ? header.column.getIsSorted() === "asc"
                        ? "desc"
                        : "asc"
                      : "asc";
                    onSortChange(col, dir);
                  }}
                >
                  {flexRender(header.column.columnDef.header, header.getContext())}
                  {header.column.getIsSorted()
                    ? header.column.getIsSorted() === "asc"
                      ? " ▲"
                      : " ▼"
                    : null}
                </TableCell>
              ))}
            </TableRow>
          ))}
        </TableHeader>

        <TableBody>
          {table.getRowModel().rows.map(row => (
            <TableRow key={row.id}>
              {row.getVisibleCells().map(cell => (
                <TableCell key={cell.id}>
                  {flexRender(cell.column.columnDef.cell, cell.getContext())}
                </TableCell>
              ))}
            </TableRow>
          ))}
        </TableBody>
      </Table>

      {/* Pagination controls */}
      <div className="flex justify-between items-center">
        <span>
          {pageIndex * pageSize + 1}‑{Math.min((pageIndex + 1) * pageSize, total)} of {total}
        </span>
        <div className="flex gap-2">
          <button disabled={pageIndex === 0} onClick={() => onPageChange(pageIndex - 1)}>
            Prev
          </button>
          <button disabled={(pageIndex + 1) * pageSize >= total} onClick={() => onPageChange(pageIndex + 1)}>
            Next
          </button>
        </div>
      </div>
    </div>
  );
}

The component mirrors the API of @tanstack/react-table but delegates all data operations to the server via the callbacks.

2. Build a server‑side data endpoint

We’ll use a Next.js route handler (app/api/users/route.ts) that receives page, size, sort, and filter query parameters. The example assumes a Prisma‑backed Postgres table called User.

// app/api/users/route.ts
import { NextResponse } from "next/server";
import { prisma } from "@/lib/prisma";

export async function GET(request: Request) {
  const url = new URL(request.url);
  const page = Number(url.searchParams.get("page") ?? "0");
  const size = Number(url.searchParams.get("size") ?? "10");
  const sort = url.searchParams.get("sort") ?? "id";
  const order = url.searchParams.get("order") ?? "asc";
  const filterColumn = url.searchParams.get("filterColumn");
  const filterValue = url.searchParams.get("filterValue");

  // Build Prisma where clause only if filtering is active
  const where = filterColumn && filterValue
    ? { [filterColumn]: { contains: filterValue, mode: "insensitive" } }
    : {};

  const [data, total] = await Promise.all([
    prisma.user.findMany({
      where,
      orderBy: { [sort]: order },
      skip: page * size,
      take: size,
    }),
    prisma.user.count({ where }),
  ]);

  return NextResponse.json({ data, total });
}

Key points

Manual pagination – skip/take map directly to page and size.
Sorting – the orderBy object is built from query strings, avoiding string interpolation risks.

What Automated Slow-3G Testing Reveals About Frontend Assumptions

Osibajo Inioluwa — Sun, 20 Sep 2026 05:54:20 +0000

What Automated Slow‑3G Testing Reveals About Frontend Assumptions

Testing in a clean CI pipeline gives you green checks, but it also gives you a false sense of security. When I throttled my app to a real‑world slow‑3G connection, I uncovered race conditions and asset‑loading failures that never appeared in synthetic benchmarks. Below is a short guide to reproducing those findings and a few concrete patterns you’ll likely run into.

Why the default CI setup lies

CI runners run on fast, wired networks.
Most test frameworks assume instant responses when they mock APIs or serve static assets from a local server.
The browser’s networking stack is rarely exercised under realistic latency and bandwidth constraints.

The result? Code that works in CI can break for users on a congested mobile network.

Adding real‑world throttling to your test suite

1. Cypress + Chrome DevTools Protocol

// cypress/plugins/index.js
module.exports = (on, config) => {
  on('before:browser:launch', (browser = {}, launchOptions) => {
    if (browser.name === 'chrome') {
      launchOptions.args.push(
        '--disable-features=NetworkService',
        '--disable-features=NetworkServiceInProcess',
        '--network-emulation',
        '--netem',
        '--latency=200',            // 200 ms RTT
        '--download=400',           // 400 kbps down
        '--upload=200'              // 200 kbps up
      );
    }
    return launchOptions;
  });
};

The flags above emulate the “Slow 3G” profile used by Chrome DevTools.
Run cypress run as usual; the browser now respects those limits.

2. Playwright’s built‑in throttling

// tests/slow3g.spec.ts
import { test, expect } from '@playwright/test';

test.use({
  // Emulate the official "Slow 3G" preset
  viewport: { width: 375, height: 667 },
  network: {
    offline: false,
    download: 500 * 1024,   // 500 KB/s
    upload: 500 * 1024,
    latency: 400,           // ms
  },
});

test('home page loads critical assets', async ({ page }) => {
  await page.goto('https://myapp.example');
  await expect(page.locator('img.logo')).toBeVisible();
});

Playwright applies the throttling automatically, so you don’t need extra CLI flags.

What actually broke

Symptom	Why it’s easy to miss in CI	Fix
Image flicker / placeholder	Images load instantly from localhost, so `onload` fires before layout calculations.	Add a fallback CSS rule that hides the element until `naturalWidth > 0`.
Missing analytics ping	Mocked XHR resolves instantly; the `sendBeacon` call is dropped when the network is congested.	Queue the beacon and retry with exponential back‑off.
Stale UI after race condition	Two parallel fetches resolve in order on fast connections, but the slower one overwrites newer data on 3G.	Use a version token (e.g., ETag) and discard responses older than the latest request.
CSS‑in‑JS injection delay	Inline style injection runs after component mount; on slow networks the component renders before the style arrives, causing a flash of unstyled content.	Insert a `<style>` tag synchronously or use `requestAnimationFrame` to delay mount until styles are ready.

These issues were reproduced consistently across Chrome, Firefox, and Safari when throttled to the “Slow 3G” preset. No synthetic benchmark caught them because they rely on timing assumptions that only hold on high‑speed links.

Takeaway

Never trust passing tests alone. Add a “slow‑network” job to your CI pipeline and treat failures as real regressions.
Instrument your code for network variability. Explicitly handle out‑of‑order responses, timeouts, and asset‑load failures.
Run a sanity check on production‑like hardware. Even a cheap Android device on a 3G hotspot can surface bugs that a desktop VM never will.

If you haven’t yet added network throttling to your automated suite, start with the snippets above. In my experience, a single nightly “slow‑3G” run catches more bugs than a full suite of unit tests.

Source: I throttled my app to slow 3G – here’s what my tests never caught

DEV Community: Osibajo Inioluwa

Optimizing Performance Without Falling for the RSC Hype

Optimizing Performance Without Falling for the RSC Hype

1. Why the RSC/App Router Hype Is Misleading

2. Baseline: Measuring INP in the Wild

2.1 Instrumentation

2.2 Findings

3. The Optimization Playbook

3.1 Trim the JavaScript Payload

3.2 Prioritize Critical Rendering Path

3.3 Optimize Data Fetching on the Pages Router

3.4 Image Delivery & Layout Stability

3.5 Edge Middleware for A/B Experiments

4. Financial Impact

5. When RSC & App Router Actually Make Sense

6. Practical Checklist for Your Next.js Project

7. Actionable Takeaways

Conclusion

performance #nextjs #webvitals

Why Package Managers Keep Trying to Use Git as a Database (And Why It Always Fails)

Why Package Managers Keep Using Git as a Database (And Why It Always Fails)

The anti‑pattern in practice

A concrete example

Using Git (pseudo‑code)

Using SQLite (real code)

Why the pattern persists

Takeaway

Next.js + Server-Side Tables Done Right

Next.js + Server‑Side Tables Done Right

Intro

1. Set up the shadcn table component

2. Build a server‑side data endpoint

What Automated Slow-3G Testing Reveals About Frontend Assumptions

What Automated Slow‑3G Testing Reveals About Frontend Assumptions

Why the default CI setup lies

Adding real‑world throttling to your test suite

1. Cypress + Chrome DevTools Protocol

2. Playwright’s built‑in throttling

What actually broke

Takeaway

Next.js + Server‑Side Tables Done Right

1. Cypress + Chrome DevTools Protocol