Forem: Roman

Measuring the Real Impact of a Performance Refactor (Not Just Lighthouse)

Roman — Tue, 28 Oct 2025 10:05:22 +0000

Every team I’ve worked with has had this moment:

Someone ships a “massive performance refactor.”

They post a screenshot of Lighthouse:

🌈 “We went from 67 → 95!”

Everyone celebrates… and nothing changes.

Conversion doesn’t move. Bounce rates don’t drop. Users don’t even notice.

That’s when you realize: Lighthouse isn’t the finish line. It’s a lab test.

Real performance is what happens when real users use your app — on bad devices, slow networks, and bloated pages full of third-party scripts.

Let’s talk about what lab tests really are, how they differ from real-world testing, and how to actually measure performance impact that matters.

Lighthouse Isn’t the Finish Line — It’s a Lab Test

Lighthouse, WebPageTest, or PageSpeed Insights are what we call lab tests —

synthetic, controlled, reproducible environments that tell you how your app should perform under ideal conditions.

They’re run in Google’s Chrome datacenters or your local environment, usually with:

A single device type (often high-end desktop or emulated mobile)
A fixed network profile (Fast 3G or 4G)
A cold cache (first load)
No background scripts, extensions, or user data

That makes them consistent — great for detecting regressions.

But also isolated — bad for measuring reality.

The Four Major Types of Performance Tests

Type	Description	Use Case	Tools
🧪 Lab Tests	Controlled, reproducible environment. Usually one device/network setup.	Detecting regressions, comparing builds, CI checks.	Lighthouse, WebPageTest, Calibre CI
🌍 Field Tests (RUM)	Data collected from real users via browser APIs.	Measure real-world experience (LCP, INP, CLS).	Perfume.js, Vercel Analytics, SpeedCurve, Datadog RUM
⚙️ Synthetic Monitoring	Automated tests that simulate users at intervals from multiple regions.	Detecting live performance drops or regressions in production.	Checkly, Pingdom, Uptrends, Datadog Synthetics
🧭 A/B Performance Experiments	Compare old vs optimized builds or feature flags under real traffic.	Measuring the business impact of optimizations.	LaunchDarkly, Optimizely, custom rollouts

Why You Need Both Lab and Real Data

Lab tests are like a medical check-up — they show how healthy your app looks in a clean environment.
RUM and synthetic data are the real patient data — they show how your app behaves in the wild.

You need both:

Lab to catch regressions early.
RUM/Synthetic to confirm real impact.

Without RUM, you’re optimizing for the lab, not the user.

Without lab tests, you can’t prevent accidental slowdowns.

Example: When the Lab Lies

Imagine your team ships a huge performance refactor — lazy loading, image compression, and bundle splitting.

Lighthouse score jumps from 70 → 95.

Everyone cheers.

Then you check RUM data a week later:

Median LCP barely moved.
INP got worse on low-end Android devices.
Conversion rate didn’t change.

Why?

Because Lighthouse runs on a clean, high-end environment.

Your real users run on throttled CPUs, 3G networks, or under thermal throttling on mobile.

Those factors dominate actual experience far more than your code improvements.

In other words — the lab said your app was healthy, but the patients are using different hardware.

That’s the gap between synthetic success and real-world performance.

Lab tools show potential; real data shows impact.

Step 1. Stop Treating Synthetic Metrics as Success

Lab tests are useful — but only as early indicators.

They show regressions, not user experience.

If you ship a refactor that scores 95 but feels identical, you didn’t make the app faster — you just optimized for a benchmark.

The real goal isn’t to improve a score.

It’s to make your app feel faster for real people.

Step 2. Define What “Fast” Actually Means for Your Product

Performance is not absolute — it’s contextual.

Ask yourself:

“What does fast mean for our users?”

For an e-commerce site:

Time from landing → product visible (LCP)
Time to first interaction (INP)
Time to checkout confirmation

For a SaaS dashboard:

Chart render time after data load
Response time between user actions

For a content site:

Perceived load time
Scroll latency

These are the moments users actually feel.

Before you refactor, define what metric equals “user happiness” in your context.

Step 3. Measure with Real-User Data (RUM)

Synthetic tests show potential; RUM (Real User Monitoring) shows reality.

Use libraries like Perfume.js or analytics such as Vercel Analytics, SpeedCurve, or Datadog RUM.

Measure from actual browsers:

LCP (Largest Contentful Paint) — the time when the largest visible element in the viewport is painted.
- It’s not “main content,” but whichever element is largest at render time.
- Valid LCP candidates include:
- <img> elements
- <image> inside <svg>
- Background images via url()
- Video poster images
- Block-level text elements (<p>, <h1>, etc.)
- LCP represents when the most significant visual element becomes visible — a strong proxy for perceived load time.
INP (Interaction to Next Paint) — measures how quickly the page responds to user input during the entire session.
CLS (Cumulative Layout Shift) — quantifies how much visible content unexpectedly moves while loading.

How Google Actually Measures INP

INP (Interaction to Next Paint) is the newest Core Web Vital replacing FID (First Input Delay).

Unlike FID, which captured only the first input, INP observes all interactions (clicks, taps, keypresses) throughout a session and reports the worst one — the longest delay between input and the next frame rendered.

Google collects this data progressively from real Chrome users through the Chrome User Experience Report (CrUX) and browser telemetry.

Each session contributes anonymized samples aggregated by domain, producing real-world performance data visible in:

PageSpeed Insights → Field Data tab
CrUX Dashboard (BigQuery / Looker Studio)

Google’s thresholds:

Good INP ≤ 200 ms (P75)
Needs improvement 200–500 ms
Poor > 500 ms

That 75th percentile (P75) is the line Google Search uses when evaluating Core Web Vitals for ranking.

So even if Lighthouse shows a perfect 100, CrUX field data may still rank your site as slow if your real users experience higher interaction latency.

Then break it down by:

Device (desktop vs low-end mobile)
Region / network
App version (old vs new)

RUM gives you percentile data (P75, P95) across real users — the difference between “it’s fast on my machine” and “it’s fast for 80 % of our audience.”

Step 4. Create an A/B Test for Performance

If you want to know whether your performance work mattered, you need a controlled comparison.

✅ Set up an A/B or gradual rollout:

Group A → old build
Group B → optimized build

Then compare:

Web Vitals (LCP, INP, CLS)
Business metrics (conversion, retention, bounce)

If your app got “faster” but conversion didn’t move → you probably optimized something users didn’t care about.

Performance work must always connect to user or business outcomes.

Step 5. Correlate Technical Metrics with Business Outcomes

Real impact = when you can say:

“Reducing LCP from 4 s → 2 s improved checkout completion by 3 %.”

That’s a win you can show to both engineers and product managers.

How to get there:

Capture performance metrics via RUM.
Log key business events (purchase, signup, retention).
Correlate them in your analytics system.

Even a simple scatter plot (LCP vs conversion rate) can reveal patterns.

That’s how you go from “we think it’s faster” to “we know it’s paying off.”

Step 6. Close the Feedback Loop in CI/CD

Once you know what matters, automate it.

Use Lighthouse CI or Calibre to detect regressions in PRs.
Add RUM dashboards visible to everyone (Datadog, Grafana, Vercel Analytics).
Set alerts for real metrics, not just lab ones (e.g. LCP P75 > 3 s).

The goal isn’t to chase 100/100 — it’s to never regress on what truly affects users.

Step 7. Communicate Results Like an Engineer, Not a Salesperson

The biggest mistake is presenting performance wins as vanity metrics:

“We improved Lighthouse by 20 points!”

No.

Say this instead:

“We reduced LCP by 35 %, and users now see the product 1.2 s sooner. Checkout conversions went up 2.8 %.”

That’s how you make performance work visible and valuable.

Step 8. Recognize When “Faster” Stops Paying Off

Every optimization has diminishing returns.

If your app already loads in ~2 s on average devices, shaving another 200 ms won’t move metrics — but fixing layout shifts or input delay might.

The goal isn’t perfection; it’s perceived speed.

Real users care about “feels fast,” not “measured fast.”

Key Takeaways

Lighthouse = lab test, not success metric.
Combine Lab + RUM + A/B for complete performance visibility.
Define what fast means for your users.
Correlate technical and business outcomes.
Once users stop noticing slowness, you’re done.

Final Thoughts

Performance is the easiest thing to brag about and the hardest thing to prove.

You can’t screenshot real impact — you have to measure it.

The next time you optimize something, ask yourself:

“Did this make my users’ experience faster — or just my metrics look better?”

That’s the difference between a performance refactor and a performance result.

Things to Remember When You Test Your React App

Roman — Wed, 17 Sep 2025 06:53:22 +0000

Many teams I have worked with had the same problem:
They had tests, but nobody trusted them.

The coverage report was green. The CI pipeline was slow and running for a while to pass your PR check. And yes, bugs still slipped to production - while developers quietly skipped running tests because they knew half of them were flaky or meaningless.

That’s the real danger: once team stops trusting tests, the whole test suite becomes dead weight, it’s just extra code to maintain which gives you zero confidence.

And everyone learned the same lesson: a test suite that isn’t trusted is even worse than having no tests at all.

So how do we avoid that? What makes tests trustworthy instead of just existing?

Here are some lessons I’ve learned the hard way.

Coverage Doesn’t Equal Quality

I’ve been on projects where hitting “90% coverage” was treated like a milestone. The dashboard turned green, the manager smiled, and… we still shipped broken features.

Why? Because coverage only measures lines executed, not whether a test proves the app works.

I’ll give you an example.

it("renders the login form", () => {
  const { container } = render(<LoginForm onSubmit={() => {}} />);
  expect(container.querySelector("input[name='email']")).toBeVisible();
});

That test executes almost every line in the component, so coverage shoots up. But if someone removed the submit logic tomorrow, it would still pass. The suite looks great on paper - and yet the feature is broken.

What you really need are intention-driven tests.

it("submits user login", () => {
  const handleSubmit = vi.fn();
  render(<LoginForm onSubmit={handleSubmit} />);

  fireEvent.change(screen.getByPlaceholderText(/email/i), { target: { value: "user@example.com" } });
  fireEvent.change(screen.getByPlaceholderText(/password/i), { target: { value: "password" } });
  fireEvent.click(screen.getByRole("button", { name: /submit/i }));

  expect(handleSubmit).toHaveBeenCalledWith({ email: "user@example.com", password: "password" });
});

This test doesn’t just run code. It protects the user intention: if I type credentials and hit submit, does the app behave correctly?

Coverage is a useful metric, but it’s not the goal. Trust comes from testing meaning, not lines.

How You Select Element - Matters

Another hidden trust killer (and performance) is how you select elements.

Early tests often relied on brittle selectors:

expect(screen.querySelector(".btn-primary")).toBeVisible();

The problem? CSS class changes → test fails, even though the UI still works.

Or overusing everywhere data-testid attributes.

expect(screen.getByTestId("submit-btn").toBeVisible()

Does it work - yes? But I often see how people keep brining huge constants file into their bundles with contains and creates necessary values for test ids.

That’s why React Testing Library recommends semantic queries:

getByRole → “there’s a button”
getByLabelText → “the input is labeled Email”
getByText → “the user can read this text”

It forces you to test the UI the way a user interacts with it.
And again - that’s what builds trust.

What (and When) to Mock

This is where many teams lose trust in their tests. Mocking is powerful, but it also comes with great responsibility.

Mock too little → tests hit the network or the database → slow, flaky, unreliable.
Mock too much → you’re not testing reality anymore, just your own fakes.

The rules I follow:

External systems and network → always mock (network calls, DB, filesystems, etc.)
Pure utilities → don’t mock (just use directly, they directly affect you output and expectations)
Internal modules / components → here you need to be careful. You need to keep balance here to avoid creating gap between what you need to test and how your app actually runs.

Once we had and issue on a project where the whole authService module was mocked:

vi.mock("../authService", () => {
    login: vi.fn().mockResolvedValue({ token: "fake" })
})

The test suite was always passing, but one day we got critical production issue with authorization management. None of the tests caught it - because test wasn’t using the actual authService , it was testing it’s own mock, and when output of service changes, everything was still green.

The solution? Don’t mock the service itself. Mock the external source the service depends on. For example, intercepting fetch calls with MSW. You still avoid real network calls, but you keep your real service logic intact.

That’s the key: mock at system boundaries, not inside your app’s core.

Unit vs Integration Tests (Do We Still Believe in the Pyramid?)

Remember the “testing pyramid”? Tons of unit tests at the bottom, fewer integration tests in the middle, and a few e2e tests on top.

In React projects, that pyramid often collapsed, We ended up with thousands of tiny unit tests for hooks and buttons… but they don’t really catch bugs. They don’t capture the whole picture of what is going on, they live in their small incapsulated world.

Most failures I’ve seen happen between units:

Data not passed correctly.
Validation breaking.
API responses mishandled.
Promises unhandled.

That’s why many developers now lean toward the Testing Trophy:

Unit tests for pure logic
Integration tests for flows (user fills form → API is called → success message shows)
e2e tests for critical paths

I won’t say the pyramid is dead - but in practice, an integration-first mindset has given me way more trust than an ocean of isolated unit tests.

Snapshot Tests: A False Safety Net

Snapshots felt like magic at first. One line of code, instant coverage:

expect(container).toMatchSnapshot();

In reality:

Snapshots broke constantly on minor markup changes.
Diffs were huge and unreadable.
Developers started clicking “update snapshot” without looking.

At that point, the tests weren’t protecting anything. They were just busywork.

The truth is simple: snapshots don’t prove behavior. They don’t tell you if the app actually works for the user.

You’ll always get more value from writing explicit assertions:

expect(screen.getByRole("heading", { name: /welcome/i })).toBeVisible();

Determinism vs Flakiness

I’ve watched test suites collapse under flakiness. Once developers stop trusting the suite, they stop running it. And from there, it dies.

The culprits are always the same:

Real timers (setTimeout, setInterval)
Random values (UUIDs, Math.random)
Async race conditions
Overuse of waitFor with arbitrary timeouts

The cure is determinism:

Freeze time (vi.setSystemTime).
Mock randomness (vi.mock("uuid")).
Use fake timers.

It’s not about making tests “less real.” It’s about making them reliable. If a test sometimes passes and sometimes fails, it’s worse than no test at all.

Flaky Tests: Detect and Eliminate

Once flaky tests creep in, trust goes out the window. That’s why finding and fixing them fast is critical.

Tools help:

Jest → --detectOpenHandles, --listTestsByDuration
Vitest → --slowTestThreshold

But prevention is even better:

Avoid leaking state between tests.
Don’t rely on arbitrary timeouts.
Always wait for explicit conditions (like findByRole).

When I see a flaky test in CI, I don’t ignore it. I either quarantine it or fix it immediately. Because the longer a flaky test lives in main, the faster your entire suite loses credibility.

Final Thoughts

The history of frontend testing is a history of false confidence:

Coverage numbers that didn’t mean safety.
Snapshots that didn’t mean stability.
Mocks that didn’t mean reality.

The lesson? Tests aren’t about numbers. They’re about trust.

A good test answers two questions:

If it fails, do I know something important is broken?
If it passes, do I trust the feature works?

If the answer is “no,” the test is noise.

That’s what I remind myself every time I write tests. Because at the end of the day, I don’t want more tests. I want a suite my team actually believes in.

Self-Hosting Next.js: What You Gain (and Lose) vs Vercel

Roman — Thu, 21 Aug 2025 09:07:02 +0000

Next.js and Vercel often feel inseparable - the framework and the platform evolving side by side. For many developers, deploying to Vercel is the default: zero-config, instant CI/CD, and all the modern features baked in.

Let’s be honest - at some point Next.js started to feel like a Vercel-first framework, rather than a truly standalone one.

But at the end of the day, we’re still able to run Next.js outside of Vercel in standalone mode, and deploy it anywhere Node.js is supported - AWS, GCP, Azure, or even bare metal. This remains a solid option for many companies that need to self-host for cost, compliance, security, or control reasons.

So what do we actually gain, and what do we lose, when self-host Next.js instead of running it on Vercel?

Why Even Consider Self-Hosting?

If Vercel works that well (and it is!), why move away then?
The answer usually comes down to scale, compliance, and control:

Cost predictability at scale → Vercel’s usage-based pricing can spike unpredictably
Custom caching → use Redis, S3, DynamoDB, or hybrid cache strategies
Enterprise compliance → data residency or vendor restrictions may block SaaS usage
Deep cloud integration and security → private VPC databases, IAM roles, WAF, custom logging
Infrastructure control → tune cold starts, multi-region routing, autoscaling rules

Yes, Vercel makes it easy to scale at globe from start, but it still does not give you that control over you infrastructure, regions to deploy, controlling CDN and etc.

Cost: The Short-Run vs Long-Run Trade-Off

In the short run → Vercel is often cheaper

No DevOps team required
No need to build CI/CD, release processes, or monitoring pipelines
Pay-as-you-go pricing works well for unpredictable workloads

In the short run → Self-hosting is often more expensive

You must build deployment pipelines (GitHub Actions, Terraform, Kubernetes)
You need an infra/DevOps team to manage scaling, observability, and rollbacks
Upfront complexity often eats away the “theoretical” savings

In the long run → Self-hosting usually wins

Reserved capacity (EC2, ECS, K8s, or Lambda Savings Plans) drives down per-request costs
Costs become predictable and controllable - important for enterprises running steady high-traffic workloads
You fully control networking and its cost

💡 Think of it like this:

Vercel = renting a fully furnished apartment. Easy to move in, but rent grows with usage.
Self-hosting = buying a house. Expensive up front, but you own and optimize every detail long-term.

What You Gain with Self-Hosting

1. Full Control Over Infrastructure

On Vercel you get a black box. On your own infra, you decide:

Where builds run (AWS Lambda, ECS, Kubernetes, Cloud Run)
How caching works (Redis, S3, DynamoDB)
Which CDN powers your edge (CloudFront, Fastly, Cloudflare)
Deployment and rollback strategies
Regions to deploy

…and many other things.

👉 I’ve covered advanced caching strategies for self-hosted Next.js (including custom cache handlers) in a separate article - check that out if you want to go deeper.

2. Integration with Your Cloud Stack

Running Next.js inside AWS/GCP makes it seamless to:

Connect directly to private VPC databases
Use IAM roles instead of API keys
Plug into CloudWatch / Prometheus / Datadog
Deploy multi-region replicas behind Route53 or GCP Load Balancing

💡 With Vercel, you often need a separate backend service just to handle private resources.

3. Potentially Lower Costs at Scale

At high scale, self-hosting can be 3–5x cheaper:

Vercel Enterprise: usage-based, priced per request + bandwidth.
AWS Lambda: ~$0.20 per million requests + execution time., when Vercel costs ~$.60 per million requests.
EC2/K8s: fixed monthly cost, can be reduced further with reserved instances.

📊 Example:

50M requests/month

On Vercel: ~$1,000+
On AWS Lambda: $250–$400

Note: these numbers are rough estimates. Actual costs vary depending on execution time, region, and instance size.

But remember: these savings only show up once you’ve absorbed the DevOps overhead. That’s why self-hosting usually only pays off in the long run, and mostly when you hit specific requirements - like sustained high load or global infrastructure.

What You Lose with Self-Hosting

1. Zero-Config DX

Vercel: git push → deploy. And that’s it, no complex CI/CD, no scripts, no cdk or terraform.

Self-host: you own CI/CD, cache warming, rollbacks, infra debugging - and you’ll need a DevOps team to manage it.

2. Built-In Features

Vercel gives you out of the box:

Image optimization
Edge middleware at global scale
Analytics dashboards
Global Infrastructure (it keeps growing)
Full integration with git
Easy to create different environments (dev, stage, prod, etc.) + preview envs
Logging
All Next.js features are integrated immediately into vercel (like redirects, rewrites, etc.)

On self-host you need to implement or configure all of this yourself, and some features aren’t trivial to replicate quickly.

3. Scaling Complexity

Vercel makes scaling invisible.

Self-hosting means handling:

Cold starts on Lambda / Cloud Functions
Instances autoscaling
Global replication and routing

When to Choose Vercel vs Self-Hosting

Stay on Vercel if:

You want speed of iteration and zero DevOps overhead
Your workloads are mostly frontend + rendering, not heavy API/data crunching
You’re okay with usage-based pricing
Even at the enterprise level (e-commerce, SaaS, marketing) - Vercel is a solid choice, as long as:
- You monitor costs carefully
- You offload heavy compute/data work to dedicated backend services

Go self-hosted if:

You need predictable infra costs
Your app requires custom caching or storage strategies
Compliance or data residency block SaaS usage
You already have a DevOps team and cloud expertise
Your infrastructure already lives in a cloud provider, and you want your Next.js app to integrate tightly into that ecosystem

Final Thoughts

Vercel is unbeatable for time-to-market and simplicity, and it keeps growing, adding new features and trying to offer better pricing, so it’s definitely a solid choice for projects of any size.

But if you need control, compliance, or predictable cost at scale, self-hosting gives you the freedom to optimize every layer - from caching to scaling to infra costs.

The real takeaway:

Vercel is great for building products fast
Self-hosting is great for running them at scale on your own terms

The Hidden Performance Costs of React Server Components

Roman — Fri, 15 Aug 2025 08:25:47 +0000

React Server Components (RSC) are one of the most talked-about additions to React in recent years — and they’ve quickly become a core part of frameworks like Next.js (with App Router), Remix and other SSR React Frameworks.

But let’s get somethings straight before we dive in:
RSC is not a new standard, engine, or framework.
It is low-level React API that enables you to render components entirely on the server, stream the to the client, and hydrate only the parts that need interactivity.

Each framework (like Next.js, Remix, Hydrogen, etc.) builds its own opinionated implementation of RSC - deciding on key points:

How server rendering is integrated
How data is fetched
How streaming works
How server transfers data to browser
How caching and revalidation scenarios are handled

…and much more.

So if you are using the Next.js App Router, you are using Next’s RSC implementation specifically, not just “React Server Components” in the abstract.

Why do we need Server Components

Server component aim to solve long-standing web application pain points which were progressing over the time and releases of new tools, frameworks and requirements:

Less JavaScript shipped to the client

Yes! The problem what we hear for decades and each new tool, framework convinces us that problem is finally solved! But the idea is straightforward - render everything on server and pass to client

Direct server-side data access

This is still common issues and hot topic for lot’s of developers on “How should I fetch the data and how it affects my page rendering” or “Building Next.js internal API endpoints”, we no longer need it, since components can talk directly to databases, filesystems, or other APIs

Faster initial loads via streaming

No need to wait for full page rendering, specially when it contains some heavy parts, you can start sending your HTML chunk by chunk as soon as they are ready.

Improved developer experience

You can write UI and data fetching all together in single place, without worrying about serialization and fetching life cycles.

💡 Does this remind you of something?

Those old days when we just had an Express server with Handlebars (or PHP, or Rails) and rendering whole template on server and just sending it to client.
The difference? Now it is just React - with streaming, selective hydration, and all the modern bells and whistles.

Server Components Trade-Offs

As I already mentioned, you should keep an eye on exact implementation of server components for specific component, because implementation are uniq, there is no standard, so whatever was working for you in one framework might work absolutely differently in another framework.

But besides that we need to consider RSC changes where and how rendering happens:

Every render of a Server Component happens on the server, not in the browser.
Browser no longer receives compiled JavaScript with you page bundle which to render on the client - it receives a serialized “Flight” payload which is telling it how to rebuild UI (rsc specific format).
Client Components still exist in bundle, but they form of hydration islands inside server-render tree.
Crossing a Server <> Client boundary is serialization cost you pay every time.

These differences bring new pitfalls that we need to consider, and in the meantime it does not remove rest of the pitfalls what we had for SSR apps which we still need to consider as well.

The Real Performance Costs of Server Components

Flight Payload Overhead (Server <> Client Boundaries)

In RSC, only Client Components hydrate - so any props passed from Server to Client must be serialized onto a Flight payload. Large or deeply nested props props bloat the payload and delay hydration.

// ❌ Large object crossing boundary → huge Flight payload
export default async function ServerPage() {
  const bigData = await getLargeDataset(); // thousands of rows
  return <ClientChart data={bigData} />; // sent in Flight payload
}

// ✅ Send only what’s needed
<ClientChart data={summaryRows} />

Mental picture:

It’s like shipping an entire warehouse to the customer’s house when they only ordered a single chair — and having them unpack it before they can use anything.

Streaming Delays for long and heavy components. Suspense order matters!

RSC supports streaming - sending UI chunks to the browser as they are ready.
If a slow server component sites above others without a Suspense boundary, it blocks the whole stream until it finishes.

// ❌ One slow server call holds up the entire page
export default async function Page() {
  const data = await slowFetch();
  return <MainContent data={data} />;
}

// ✅ Wrap slow sections in Suspense
export default function Page() {
  return (
    <>
      <Header />
      <Suspense fallback={<Loading />}>
        <SlowSection />
      </Suspense>
    </>
  );
}

Mental picture:

Like waiting for the slowest dish at a restaurant before you’re allowed to eat anything.

Use client scope explosion

Putting “use client” at the top of a big/shared file promotes that file (and often its imports) to a Client Component, erasing the “no JS for server code” benefit and inflating bundles. Which might be okay for some of the cases, but it still requires additional learning curve for developers and understanding application specifics.

Community support

RSC changes the rules — and many libraries still aren’t ready for it. Some require "use client" to function, which negates many of RSC’s benefits.
Be prepared: your favorite library might not yet work well in a Server Component environment. For example, most CSS-in-JS frameworks (MUI, Chakra, Stitches, etc.) currently require "use client".

Final Thoughts

React Server Components open the door to faster, leaner, and more maintainable React applications - but they aren’t a silver bullet.

They shift complexity from the browser to the server, introduce new serialization and streaming considerations, and require a different way of thinking about component boundaries.

If you adopt RSC, keep a close eye on:

Where your Server ↔ Client boundaries are
What data you pass across them
How you use Suspense for streaming
Which libraries truly work well in a server-first model

RSC is a powerful tool - but like any tool, using it effectively means understanding both its benefits and its trade-offs.

Mastering Custom Cache Strategy in Next.js

Roman — Wed, 06 Aug 2025 08:07:30 +0000

Everybody knows that Next.js has powerful built-in caching capabilities — it usually just works. When deploying your app to Vercel or Netlify, you don’t need to worry about what’s happening under the hood: how caching is scaled, how it’s shared, or even where it lives (CDN or application cache).

But there are still many cases where you need to run your Next.js application on a cloud provider (a.k.a. self-hosting) like AWS, Azure, or GCP. This comes with its own trade-offs. Now you — or your DevOps — are responsible for managing infrastructure, instances, scaling, failover, networking… and yes, caching.

This article isn’t about deploying Next.js to the cloud — it’s about how you can build a custom cache strategy that improves reliability, performance, and opens the door for advanced features like A/B testing.

Default Caching Behavior in Next.js

Next.js uses the file system to cache rendered output (HTML, JSON, RSC), and supplements this with an in-memory cache for frequently accessed data.

Sounds solid, but here are some real-world limitations:

Auto-scaling: Cache is tied to the local instance. When you scale up, each new instance has a different, empty cache.
Persistence: If an instance is replaced (scale-in, crash, etc.), its cache is lost — recreating cache can be costly.
Fragmentation: Businesses often want A/B testing. That means rendering and caching multiple versions of the same page for different user segments.

So, to build a robust solution, you need to:

✅ Share cache across instances
✅ Persist cache between restarts
✅ Fragment cache for feature buckets or A/B testing

All of that becomes possible with a custom cache strategy.

Creating a Custom Cache Handler

Next.js allows you to provide a custom cacheHandler. You can configure this in your next.config.js:

// next.config.js
module.exports = {
  cacheHandler: require.resolve('./cache-handler.js'),
  // disable default in-memory caching
  cacheMaxMemorySize: 0,
}

Your cache-handler.js file should expose class which will be created during each request to your server, it is very important to remember that your class will be created for each request and not once node process.

Let’s create simple example of custom in-memory cache class to see what it does:

// cache-handler.js

// creating store outside, so it will be available on instance level
// and can be shared between different requests.
const store = new Map();

class CacheHandler {
  constructor(options) {
    this.options = options;   
  }

    // function to retrieve cache for the page
    // when returns null - then request will go to actual render function
    // otherwise when data in cache exists, will skip rendering the page
  async get(key) {
    const record = store.get(key);
    return record ? record.value : null;
  }

    // this will be triggered each time when next.js tries to write cache for the page
    // note: that for page router next.js caches only special types of pages, which are using ISR,
    // and for app router whenever your provide cache / revalidate properties
    // if you are using dynamic or SSR strategies it won't appear into cache handler.
  async set(key, data, ctx) {
    this.store.set(key, {
      value: data,
      lastModified: Date.now(),
      tags: ctx.tags || [],
    });
  }

  async revalidateTag(tags) {
    tags = Array.isArray(tags) ? tags : [tags];
    for (const [key, rec] of this.store) {
      if (rec.tags.some(tag => tags.includes(tag))) {
        this.store.delete(key);
      }
    }
  }

  resetRequestCache() {
    // optional, This method resets the temporary in-memory cache
    // for a single request before the next request.
  }
}

module.exports = CacheHandler;

Basically even this simple example shows how much power we receive and now we are able to solve all our issues and achieve.

Scaling & Persisting Cache

I decided to combine the first two issues — cache sharing and persistence — because they’re pretty closely connected. In most real-world setups, the most effective solution is to move your cache into some form of shared storage. That could be S3 (or any blob storage), a shared file system, or even Redis if you prefer in-memory caching. The idea is simple: make your cache available outside the individual instance.

This way, all of your instances — old or new — can access the same centralized cache. So even when auto-scaling kicks in and new instances spin up, they’re not starting from scratch. They just pick up where the others left off. Problem solved.

Here’s a minimal example of a custom cache handler that reads and writes directly to S3:

import { S3Client, PutObjectCommand, GetObjectCommand, DeleteObjectCommand } from "@aws-sdk/client-s3"

const client = new S3Client({})

class CacheHandler {
    constructore(options) {
        this.options = options
    }

    // Now we can read data directly from s3 and if there is no data
    // then next.js will render it and call `set` method to write cache
    async get(key) {
        const response = await client.getObject({
            Bucket: process.env.NEXT_BUCKET_KEY,
            Key: key
        })

        if (!response.Body) return null

        return JSON.parse(await response.Body.transformToString('utf-8')) || null
    }

    async set(key, data, ctx) {
        await client.putObject({
            Bucket: process.env.NEXT_BUCKET_KEY,
            Key: key,
            // optional, but nice to have if you want to serve response directly from s3,
            // so CDN will know how to cache response.
            ...(data.revalidate ? { CacheControl: `max-age=${data.revalidate}` } : undefined),
            body: JSON.stringify(data)
        })
    }
}

That’s it! Super straightforward, and yet we’ve already solved a lot. And what’s even better — we now have full control. You can extend this however you like and build a caching solution that fits your app’s architecture and scaling setup perfectly.

Now for my favorite part: let’s make it A/B testing–friendly.

Fragmenting Cache for A/B Testing

A/B testing is something most product teams want, and it’s actually pretty easy to support when you control your own cache handler.

Here’s a quick way to fragment your cache per user bucket — so users in different experiments don’t share cache entries:

// code stays the same ^^^

class CacheHandler {
    constructor(options) {
        this.options = options
    }

    getRequestBucket() {
        // we can have a function which will identify user's a/b test bucket based on request
        // we can use this.options and context which will have all necessary data about request and route
        // and return our value
        const cookie = this.options.req?.headers?.cookie ?? '';
        return cookie.includes('bucket_a') ? 'a' : 'b'
    }

    async get(key) {
        const currentBucket = this.getRequestBucket()
        // That's it, now you are able to fragment your cache
        // and read data for particular cache segment 
        const cacheKey = currentBucket + key
        //...
    }

    async set(key, data, ctx) {
        const currentBucket = this.getRequestBucket()
        // Same here, just we want to write unique key for our segment
        // so we can read it later on 
        const cacheKey = currentBucket + key
        // ...
    }
}

Easy! Wow we’ve got separate cache storage per experiment group. No more cache collisions between multiple experiments!

Final Thoughts

So now we’ve solved all the problems we started with. Cache is shared across instances, persistent across restarts, and even segmented per user group for A/B testing. And the best part — it’s all under your control.

Of course, real-world implementations can be more complex, especially when you throw in edge caching, CDN rules, or enterprise-scale observability. But the core idea remains simple: own your caching strategy, and you’ll unlock a ton of flexibility and performance.

And remember, there are only two hard things in programming:

Naming things
Managing cache 😅

Every strategy comes with trade-offs, but with this approach, you’ve got the tools to make the best choice for your setup. Happy caching!

Why You Should Use Zod Instead of TypeScript Alone

Roman — Fri, 01 Aug 2025 09:47:20 +0000

Have you ever encountered a situation where your TypeScript-powered application, despite having perfect type definitions, unexpectedly broke at runtime due to an unexpected API change or malformed user input? You're not alone. While TypeScript significantly improves developer experience by catching type errors during compile time, it does not protect you at runtime. TypeScript doesn't fix your data - it just makes the problems easier to see. But in order to simplify our lives and protect at runtime, we can combine it with zod (typescript + zod = ❤️).

What is Zod?

From their website:
”TypeScript-first schema validation with static type inference by @colinhacks”

Unlike TypeScript, which checks types only at compile-time, Zod ensures data adheres to defined schemas at runtime, preventing unexpected errors or misleading data.

Additionally, Zod offers various integrations with many tools, starting with simple schema validations, to complex forms, APIs, and database schemas validations, which helps you to protect your schema and data type at all stages of development.

Why TypeScript Alone Isn’t Enough

Yes, I know, it won’t be new for your or it won’t surprise you. TypeScript offers type safety only during build/compile phase. It still helps reduce errors and improve documentation — so even when revisiting old code, you can make a fairly confident guess about what it’s doing 🙂. However, at runtime, we’re back to plain JavaScript—dynamic, flexible, but without any built-in type safety, making our apps vulnerable to unexpected errors.

Here is quick example:

interface Profile {
 id: number
 name: string
 description: string
 imageSrc: string
}

const getProfile = (): Promise<Profile> => {
 return fetch('/api/profile')
  .then(res => res.json()) // Generally there is no guarantee that it will match the interface.
} 

const profile = await getProfile()

How Zod Complements TypeScript

Zod provides explicit runtime validation, which allows to make sure that your data’s shape is still what you expect and avoid surprising errors:

import { z } from 'zod'

const ProfileSchema = z.object({
 id: z.number(),
 name: z.string(),
 description: z.string(),
 imageSrc: z.string()
})

type Profile = z.infer<typeof ProfileSchema>

const getProfile = (): Promise<Profile> => {
 return fetch('/api/profile')
  .then(res => res.json())
  .then(profile => {
      return ProfileSchema.parse(profile) // Throws an error if validation failed.
  })
} 

const profile = await getProfile()

So with Zod’s usage we have:

Less boilerplate - fewer manual checks, cleaner code
Automatic type inference - instantly reflects schema updates
Easy to maintain and scale - centralized schema definitions
Simplified advanced error handling - clearer error outputs for debugging
Integration across your entire stack - from forms to APIs to database interactions

In real world you can integrate it with pretty much anything:

Form validation: e.g. integrate with React Hook Forms for validation
API Routes: validate incoming requests and outgoing response formats
External API integrations: check response structure from services like supabase, or stripe, .etc

API Example:

export async function POST(req: Request) {
 const body = await req.json()
 const result = BodySchema.safeParse(body)

 if (!result.success) {
  return Response.json({ errors: result.error.format() }, { status: 400 })
 }

 const requestData = result.data
 // at this moment we can safely proceed with valid request data
}

React Forms Example:

import { useForm } from 'react-hook-form'
import { zodResolver } from '@hookform/resolvers/zod'

const formSchema = z.object({ email: z.string().email() })

function MyForm() {
  const { register, handleSubmit, formState } = useForm({
    resolver: zodResolver(formSchema)
  })

  return (
    <form onSubmit={handleSubmit(data => console.log(data))}>
      <input {...register('email')} />
      {formState.errors.email && <span>{formState.errors.email.message}</span>}
      <button type='submit'>Submit</button>
    </form>
  )
}

Performance Impact

Overall Zod adds minimal overhead - practically unnoticeable in most real-world applications,
its simplicity and reliability easily justify the minimal performance cost — but keep in mind your specific use case, especially when dealing with deeply nested or large JSON structures.

Conclusion

So combining both Zod and TypeScript provides compile-time and runtime safety, enhancing reliability and confidence of the application and us as developers. If you're looking for a way to solve runtime safety issues, Zod is an excellent solution.

Forem: Roman

Measuring the Real Impact of a Performance Refactor (Not Just Lighthouse)

Lighthouse Isn’t the Finish Line — It’s a Lab Test

The Four Major Types of Performance Tests

Why You Need Both Lab and Real Data

Example: When the Lab Lies

Step 1. Stop Treating Synthetic Metrics as Success

Step 2. Define What “Fast” Actually Means for Your Product

Step 3. Measure with Real-User Data (RUM)

How Google Actually Measures INP

Step 4. Create an A/B Test for Performance

Step 5. Correlate Technical Metrics with Business Outcomes

Step 6. Close the Feedback Loop in CI/CD

Step 7. Communicate Results Like an Engineer, Not a Salesperson

Step 8. Recognize When “Faster” Stops Paying Off

Key Takeaways

Final Thoughts

Things to Remember When You Test Your React App

Coverage Doesn’t Equal Quality

How You Select Element - Matters

What (and When) to Mock

Unit vs Integration Tests (Do We Still Believe in the Pyramid?)

Snapshot Tests: A False Safety Net

Determinism vs Flakiness

Flaky Tests: Detect and Eliminate

Final Thoughts

Self-Hosting Next.js: What You Gain (and Lose) vs Vercel

Why Even Consider Self-Hosting?

Cost: The Short-Run vs Long-Run Trade-Off

What You Gain with Self-Hosting

1. Full Control Over Infrastructure

2. Integration with Your Cloud Stack

3. Potentially Lower Costs at Scale

What You Lose with Self-Hosting

1. Zero-Config DX

2. Built-In Features

3. Scaling Complexity

When to Choose Vercel vs Self-Hosting

Final Thoughts

The Hidden Performance Costs of React Server Components

Why do we need Server Components

Server Components Trade-Offs

The Real Performance Costs of Server Components

Final Thoughts

Mastering Custom Cache Strategy in Next.js

Default Caching Behavior in Next.js

Creating a Custom Cache Handler

Scaling & Persisting Cache

Fragmenting Cache for A/B Testing

Final Thoughts

Why You Should Use Zod Instead of TypeScript Alone

What is Zod?

Why TypeScript Alone Isn’t Enough

How Zod Complements TypeScript

Performance Impact

Conclusion

Links & Resources