DEV Community: Srikar Phani Kumar Marti

Debugging React Context Performance Issues: When and Why Components Re-render

Srikar Phani Kumar Marti — Thu, 16 Jul 2026 11:34:11 +0000

Ever had this happen? You change a value in your React Context Provider, expecting just a few components to update. But suddenly, half your app re-renders, and your performance tanks. You scratch your head and wonder: why is React context so slow? I’ve been there. This article pulls back the curtain on React Context's update mechanism, why components re-render aggressively, and how to tame the beast.

The React Context gotcha: Every consumer re-renders on update

Imagine you have a ThemeContext with a theme value (say, "light" or "dark"). You wrap your app:

<ThemeContext.Provider value={theme}>
  <App />
</ThemeContext.Provider>

Now, anywhere you call useContext(ThemeContext), React will re-render that component every time the value changes.

Sounds obvious? The surprise is that React does not do a deep comparison on the context value. It just checks if the reference changed (with Object.is). So if you provide a new object or primitive value, all consumers re-render.

Here’s the kicker: even if your components only use part of the context, or even if the value they read is unchanged inside a new object, they still re-render.

Why React doesn’t do partial updates inside context

React Context is designed as a simple pub-sub model: context value changes notify all consumers. React doesn’t track which consumer reads which part of the context value , it can’t know which slice matters to a component without explicit help.

Under the hood, when the provider’s value changes (meaning the reference changes), React triggers an update for every subscribed consumer. This is a fast operation for a handful of components, but not when your context is huge or used widely.

Common anti-patterns that cause unnecessary re-renders

1. Passing inline objects or functions as `value`

Developers often write:

<ThemeContext.Provider value={{ theme, toggleTheme: () => setTheme(t => t === 'dark' ? 'light' : 'dark') }}>

This creates a new object and a new function on every render, so the context value changes every time, even if theme is the same.

Fix: Memoize the value with useMemo and functions with useCallback.

const toggleTheme = useCallback(() => {
  setTheme(t => t === 'dark' ? 'light' : 'dark')
}, [])
const value = useMemo(() => ({ theme, toggleTheme }), [theme, toggleTheme])

<ThemeContext.Provider value={value}>
  ...
</ThemeContext.Provider>

2. Using one big context for many unrelated values

Storing lots of state in a single context causes any change to trigger re-renders everywhere. For example, a context with { user, theme, settings, notifications } means a theme change re-renders components that only care about user.

Fix: Split your context into multiple smaller contexts, each responsible for a specific piece of state.

3. Deeply nested consumers that don’t memoize

If you use useContext inside deeply nested components without memoization, you may get more re-renders than necessary.

Fix: Use React.memo or useMemo to avoid re-renders when props or context values haven’t changed.

Profiling context-related re-renders

React DevTools Profiler is your friend here.

Start recording.
Trigger your context update.
Look for components that re-render unexpectedly.

You’ll often notice many components updating even if they don’t use the changed part of the context.

How React Context actually triggers updates

Under the hood, React keeps a linked list of all consumers subscribed to the provider. When the context value changes:

React compares the new value with the old reference using Object.is.
If they differ, React schedules an update for all consumers.
Each consumer re-renders and reads the new context value.

There is no built-in mechanism to track which consumers care about which parts of the value.

Alternatives and patterns to optimize context usage

Use multiple contexts

Split your state across several contexts. For example:

UserContext
ThemeContext
SettingsContext

This way, updating theme won’t cause user-related components to re-render.

Use selectors with `useContextSelector` (third-party)

Libraries like use-context-selector let you subscribe to specific slices of context values, so components re-render only when their selected slice changes.

Example:

const theme = useContextSelector(ThemeContext, ctx => ctx.theme)

Only components whose selected slice changes will re-render.

Lift state closer to where it’s needed

Sometimes, context is used for convenience but state can live closer to components that need it, reducing unnecessary propagations.

Memoize components and values

Use React.memo, useMemo, and useCallback to avoid re-renders caused by changing references.

When context re-renders are unavoidable

Sometimes, your app is small enough or updates infrequent enough that simple memoization suffices. Premature optimization adds needless complexity.

But if you spot lag, jank, or excessive re-renders tied to context, start here:

Profile with React DevTools
Check your context value references
Split contexts
Use selectors if needed

Wrapping up

React Context is incredibly useful but comes with this gotcha: any change to the context value triggers all consumers to re-render.

Understanding this helps you avoid performance pitfalls and write snappy apps. Next time your context update slows things down, you’ll know exactly where to look and what to fix.

Helpful learning resources

MDN Web Docs
web.dev performance guidance
React documentation Originally published at Under The Hood. Get the next deep dive in your inbox: subscribe to Under The Hood.

HTTP QUERY is here: what changes for frontend data fetching?

Srikar Phani Kumar Marti — Wed, 15 Jul 2026 11:22:57 +0000

You’ve probably hit this frustrating moment: your frontend needs to fetch data with complex filters or queries, but GET just won’t cut it because your URL grows unwieldy or exceeds length limits. So you switch to POST, shove your JSON search parameters in the body, and call it a day.

Except now your POST request is meant to be a safe, read-only fetch. But HTTP semantics say POST is neither safe nor idempotent. That kills caching on CDNs, disables certain browser optimizations, and confuses intermediaries. You’re stuck in a weird limbo.

Enter HTTP QUERY , the new kid on the block, standardized by RFC 10008 in June 2026. It's safe and idempotent like GET but also lets you send a request body like POST. Sounds like the best of both worlds, right? Let’s dig into what this means for frontend data fetching and why you probably shouldn’t just flip the switch on all your POST /search routes tomorrow.

What is HTTP QUERY, exactly?

HTTP QUERY is a new request method defined to address a long-standing gap: how to send complex, structured queries in a safe, cacheable way.

GET requests are safe and idempotent, which means they’re perfect for fetching data. But their parameters live in the URL, which has length limits (around 2000 characters in many browsers) and poor ergonomics for deeply nested or complex JSON-like filters.

POST requests let you send a rich body but are considered unsafe and non-idempotent by default. This kills caching on the CDN and browser layers, since intermediaries assume POST changes server state.

HTTP QUERY combines the best of both:

It’s safe and idempotent, so intermediaries treat it like GET.
It supports a request body, so you can send complex JSON queries without cramming them into a URL.
It keeps your URLs clean and uncluttered.

Why does safe + body matter?

The HTTP spec has historically struggled with this. Safe methods (GET, HEAD) can’t have bodies according to some interpretations, so complex queries get shoved into URLs or POST bodies.

That leads to practical downsides:

Cache busting: CDNs and browsers ignore POST responses for caching, even when you know the request is read-only.
Proxy confusion: Intermediaries treat POST as a possible state-changing method, so they don’t optimize or retry it safely.
Developer confusion: You have to choose between semantic correctness and practical needs.

HTTP QUERY says: let’s have a safe, idempotent method that supports bodies, so everyone knows it’s a read-only fetch with complex input.

What does this mean for frontend data fetching?

Complex search filters get a first-class home

Say you’re building a search UI with filters like date ranges, nested facets, or fuzzy matching. Encoding these in query strings quickly becomes a nightmare:

/search?dateFrom=2024-01-01&dateTo=2024-01-31&filter[category]=books&filter[price][min]=10&filter[price][max]=50

Ugly, error-prone, and brittle. Plus, some browsers or proxies might truncate the URL.

With HTTP QUERY, you can move this entire JSON payload into the request body cleanly:

QUERY /search HTTP/1.1
Content-Type: application/json

{
  "dateFrom": "2024-01-01",
  "dateTo": "2024-01-31",
  "filter": {
    "category": "books",
    "price": { "min": 10, "max": 50 }
  }
}

This keeps your URLs short and your request format consistent.

GraphQL-style queries get a simpler transport

GraphQL requests often use POST because their queries live in the body. But that means you lose GET semantics, caching, and some CDN optimizations.

HTTP QUERY lets you send a GraphQL query in the body while keeping the request safe and idempotent, opening doors for better caching.

Caching and CDN behavior improve

Because HTTP QUERY is explicitly safe and idempotent, CDNs and browsers can cache these requests like GETs. That means:

Edge caches serve responses faster
Reduced server load
Better offline and retry behavior

But this depends on your CDN and browser supporting HTTP QUERY correctly , which is still a work in progress.

Browser and framework support is still catching up

As of mid-2026, HTTP QUERY is brand new. Most browsers have started to support it at the network level, but APIs like fetch() and XMLHttpRequest are still rolling out support.

Frameworks, HTTP clients, and intermediaries (proxies, CDNs) also need updates:

fetch(): New versions accept method: 'QUERY'.
Axios, superagent: Libraries need to add explicit support.
CDNs: Providers must recognize QUERY as safe and cacheable.

Until then, you may need fallbacks or polyfills.

Why you shouldn’t blindly replace all POST /search calls

It’s tempting to think: "Great, HTTP QUERY solves all my problems, I’ll just swap POST for QUERY everywhere!"

But hold your horses:

Some POST /search endpoints trigger server-side side effects or logging that aren’t safe. Changing method semantics without audit risks bugs.
Caching behavior depends on correct cache headers and CDN support; otherwise, you might see stale data or cache misses.
Client and server libraries need to handle QUERY correctly, or you’ll get unexpected failures.
Browsers and older environments might reject unknown methods or fail silently.

Best practice? Use HTTP QUERY for new endpoints designed for safe, read-only queries with complex bodies. For existing POST endpoints, evaluate method semantics carefully before switching.

How to experiment with HTTP QUERY today

Check your HTTP clients: Try fetch('/search', { method: 'QUERY', body: JSON.stringify(payload) }) in browsers with up-to-date support.
Update your backend: Make your server recognize and handle QUERY requests like GET but parse the body.
Test CDN behavior: Confirm your edge cache treats QUERY like GET for caching.
Monitor fallbacks: Have fallbacks to POST or GET for clients or intermediaries lacking support.

What I learned debugging QUERY support in my apps

I tried switching a complex filter endpoint from POST to QUERY in a staging app. It was smooth on the server side , minimal code changes. But the frontend fetch calls failed in older browsers. My CDN ignored QUERY requests initially, so no caching kicks in.

Adding a feature detection layer and a fallback to POST for unsupported clients fixed the problem. Also, ensuring my server sent proper Cache-Control headers was critical to leverage caching.

This showed me HTTP QUERY is promising but still early-stage. You’ll want to adopt gradually and monitor carefully.

So is HTTP QUERY the future?

It feels like a neat, principled way to fix a longstanding HTTP awkwardness. For frontend devs wrestling with complex read-only queries, it means cleaner URLs, better caching, and clearer semantics.

But like any new protocol feature, it needs ecosystem support, adoption, and time to mature.

In the meantime, keep using POST for complex queries when needed, but watch HTTP QUERY’s progress. When tooling and infrastructure are ready, it’ll be a handy tool in your data fetching toolbox.

And if nothing else, it’s nice to see the web’s foundations still evolving , one tiny method at a time.

Originally published at Under The Hood.

Get the next deep dive in your inbox: subscribe to Under The Hood.

New Newsletter Alert: Under The Hood Has a New Home

Srikar Phani Kumar Marti — Tue, 14 Jul 2026 10:49:57 +0000

I have wanted this one to feel a little loud, so here it is: Under The Hood has a new home.

For a while, I was publishing on Substack. It was convenient, familiar, and honestly a pretty good place to get started. But at some point I wanted the newsletter to feel more like mine. Not just another page inside someone else's platform, but a real owned space where the archive, design, subscribers, and publishing flow all live together.

So I moved.

I ported my old Substack posts into this new newsletter, and that turned out to be more interesting than I expected. There is something weirdly satisfying about watching an archive move from one system into another: titles, dates, cover images, old essays, little formatting quirks, all of it getting cleaned up and finding a new shape. It felt less like a migration and more like unpacking boxes after moving into a new place.

The stack is intentionally simple:

Next.js for the site and admin workflow
Postgres on Neon for posts, subscribers, publishing state, and platform records
Prisma for the database layer
Resend for newsletter email flows
Vercel for hosting
A small private admin app for drafting, publishing, syndication, and notifications

There is also a lightweight content pipeline behind the scenes, mostly so I can keep the writing process organized: ideas, drafts, publishing status, platform links, and the occasional reminder when something needs attention. I do not want the tooling to become the story, but I do want the system to make publishing easier to keep doing.

And that is the big difference between building a custom newsletter and just posting on LinkedIn or another feed.

A social post is borrowed attention. It can travel fast, but it lives inside someone else's rules, ranking system, and interface. A newsletter and owned archive are slower in a good way. They are easier to return to. They are easier to search. They can have their own voice, structure, and rhythm. They do not disappear into the feed ten minutes after you publish them.

I will still post on LinkedIn and other platforms when it makes sense. Those places are useful for discovery. But this site is the source of truth now. The full essays live here. The archive lives here. The subscriber list starts here.

That feels right.

This first post is mostly a marker in the ground: the new newsletter is live, the old posts have been moved over, and the next batch of writing starts from here.

If you have suggestions for what I should write next, or if there is something from the old Substack archive you want me to revisit, please leave a comment wherever you found this post or send the suggestion my way. I am going to start building the next backlog from here.

And if you want future deep dives in your inbox, please subscribe. I would love for you to come along.

Originally published at Under The Hood.

Get the next deep dive in your inbox: subscribe to Under The Hood.

Optimizing React Suspense: How Concurrent Mode Handles Data Fetching and Rendering

Srikar Phani Kumar Marti — Mon, 13 Jul 2026 10:55:48 +0000

You know that awkward moment when your Suspense fallback flashes on the screen for just a split second before your real content pops in? Sometimes it feels like the loading spinner is playing peekaboo, and you wonder if you’re doing something wrong.

Spoiler: React’s Concurrent Mode isn’t broken. Suspense is designed to juggle data fetching and rendering in a way that feels smooth , if you understand what it’s doing behind the scenes.

The familiar pain: flickering loading states

Imagine you have a React component that fetches user data. You wrap it in a <Suspense fallback={<Spinner />}>. When the data isn’t ready, the spinner shows. When the data arrives, the real UI replaces it.

But sometimes you see the spinner flash, then the content appears, then maybe the spinner shows again briefly. This flicker isn’t just a UI glitch , it’s React’s scheduler at work.

Why?

React’s Scheduler and Priorities: The secret sauce

Concurrent Mode introduced a sophisticated scheduler inside React. Instead of rendering everything synchronously, React breaks work into small units and assigns priorities.

When data fetching suspends, React marks that work as low priority. It shows the fallback immediately , because that’s the quickest thing to do. Meanwhile, React keeps trying to fetch data and prepare the real UI.

The scheduler can pause, resume, or even abandon work if higher priority tasks come in (like user input). This flexibility lets React keep the app responsive, but it also means your Suspense fallback might show or hide multiple times as React juggles work.

How Suspense boundaries manage concurrent rendering

Suspense boundaries are like gates controlling what the user sees. When a component suspends (e.g., waiting for a Promise), React doesn’t throw an error , it throws the Promise up the tree to the nearest Suspense boundary.

That boundary catches it and shows the fallback UI.

But here’s the catch: React doesn’t block the entire tree. With Concurrent Mode, it continues working on other parts of the UI that don’t depend on the suspended data.

This means multiple Suspense boundaries can show independent loading states, and content can appear incrementally.

Data fetching under the hood: how React knows when to show what

React Suspense for data fetching usually relies on throwing Promises from your components , a pattern popularized by libraries like Relay and React Cache.

When a component tries to read data that isn’t ready, it throws a Promise. React catches it, shows the fallback, and retries the render when the Promise resolves.

This retry is scheduled with the scheduler’s priority rules. If the Promise resolves quickly, React can skip showing the fallback at all, resulting in zero loading flicker.

If it takes longer, the fallback shows up to give the user feedback.

Why Suspense fallback flickers , and how to fix it

The flicker often happens because the Promise resolves just after React commits the fallback UI.

React can’t know for sure if the data will be ready immediately or soon, so it shows the fallback first. Then it re-renders the content. This is a tradeoff between showing feedback early and avoiding unnecessary spinners.

To reduce flicker:

Use techniques like delayMs and timeoutMs in libraries like React Suspense’s experimental helpers to avoid showing fallback UI for very fast loads.
Cache data aggressively so that components can read synchronous results immediately.
Break your UI into smaller Suspense boundaries so React can show partial content as soon as it's ready.
Use startTransition from React 18 to mark data loading as low priority, allowing React to prioritize user interactions.

What actually happens during a Suspense update

Let’s walk through a concrete example:

Your component tries to read user data.
The data isn’t ready, so it throws a Promise.
React catches this, marks the component as suspended, and shows the fallback.
The Promise resolves.
React schedules a low priority update to retry rendering the component.
React renders the component with the data, replaces the fallback.

Step 3 → step 6 can happen quickly or with noticeable delay, depending on network and cache.

Concurrent Mode juggling multiple updates

Concurrent Mode also means React can interrupt a render mid-way.

If a high priority update arrives (like user input), React can pause the Suspense update, respond to the user, then resume rendering.

This behavior makes apps feel snappy but adds complexity to Suspense timing.

Why Suspense is still evolving

React Suspense and Concurrent Mode are a work in progress. The React team continuously improves the scheduler heuristics to minimize flicker and improve perceived performance.

Meanwhile, understanding these internals helps you design data fetching and UI boundaries that fit React’s model.

Wrapping up

Next time your Suspense fallback flashes unexpectedly, don’t panic. It’s React juggling priorities to give your users the best experience.

With some tuning , smarter caching, strategic Suspense boundaries, and startTransition , you can help React show your UI at just the right moment.

Suspense isn’t magic, but it’s a clever balancing act. Knowing what happens under the hood is the first step to mastering it.

Originally published at Under The Hood.

Get the next deep dive in your inbox: subscribe to Under The Hood.

React Server Components: Under the Hood of Streaming and Client Boundaries

Srikar Phani Kumar Marti — Sat, 11 Jul 2026 20:24:08 +0000

You’ve probably hit that moment where your React app feels sluggish, or where splitting code between client and server logic gets messy fast. React Server Components (RSC) promise to fix that by letting you run components on the server while streaming their output to the client , all without losing interactivity. But how does this actually work under the hood?

I dug into the mechanics to understand why the new streaming format feels so fluid and how React knows when to run what.

The familiar pain: mixing server and client logic

Before RSC, if you wanted to fetch data on the server and then render it on the client, you usually did something like data fetching in getServerSideProps, then rendering with client-side hooks or hydration. It worked but had downsides:

You send the full HTML only after data arrives, blocking first paint.
Client code bundles bloat with data-fetching logic.
Hydration can cause flickers or UI mismatches.

React Server Components flip this by letting you write components that run entirely on the server , sending only serialized UI instructions to the client. But it’s not just a magic serialization trick.

Streaming the UI: chunking the response

When you request an RSC-enabled React app, the server doesn’t wait to render the whole tree. Instead, it starts streaming chunks of serialized component data immediately.

Imagine the server is assembling a puzzle but sends you pieces as soon as they’re ready, not the whole picture at once. React serializes each component’s output into a special format , basically a structured JSON that encodes elements, props, and where client boundaries are.

This stream arrives to the browser, where React’s client runtime incrementally parses each chunk and merges it into the current UI.

That means your users start seeing content way faster, because React never waits for the entire tree before flushing something.

Client boundaries: the handshake between server and client

A core concept is the client boundary , where a React Server Component hands off to a client component. Under the hood, React marks these boundaries explicitly in the serialized stream.

Here’s what happens:

Server renders a subtree and encounters a client component.
Instead of serializing that client component’s UI, it inserts a placeholder with a unique ID.
The client runtime sees the placeholder, fetches the necessary client code bundle asynchronously, and then hydrates that component in-place.

This handshake means server and client code stay separate, but React stitches them together seamlessly.

How React serializes components

The serialization format React uses isn’t just plain JSON. It’s a custom encoding that preserves React elements’ shape and references, plus some metadata:

Component type identifiers
Props, including special handling for functions and client references
Boundary markers that tell the client runtime where to hydrate

For example, if a prop is a client function, it gets replaced by a reference ID, so the client can wire up event handlers correctly after hydration.

This encoding is efficient and incremental , React streams each component or subtree as it’s ready, so your app can render progressively.

Streaming versus traditional SSR

You might ask, isn’t server-side rendering streaming already a thing?

Yes, but with traditional SSR, the server streams fully rendered HTML. React Server Components stream serialized React elements instead, which are then rendered on the client. This gives React more control to incrementally hydrate only the parts marked as client boundaries.

It also means your server components never send any client JavaScript or event handlers directly, just the instructions needed to build the UI.

Architectural implications: clean split of concerns

Because server components can’t contain client-only code, your data fetching, secret keys, and heavy logic stay safely on the server.

Meanwhile, client components handle interactivity, hooks, and browser-only APIs. The explicit boundaries mean you can reason about what runs where without messy hacks.

On top of that, streaming lets your app show meaningful UI faster, improving perceived performance.

What I learned debugging a mismatch

I ran into a tricky bug when I mixed a client component inside a server subtree but forgot to mark it properly. React’s stream sent a placeholder, but the client runtime never fetched the corresponding JS bundle.

Result? A blank spot in the UI.

The fix was to ensure I imported client components with a special directive ('use client') so React could identify and serialize the boundary correctly.

This highlighted how crucial those boundaries are , the entire streaming and hydration dance depends on them.

Wrapping up

React Server Components are more than just a new API , they’re a streaming protocol that rethinks how server and client communicate. By serializing component trees incrementally and marking client boundaries explicitly, they let you split logic cleanly and deliver UI faster.

If you’ve felt friction between server and client code in React apps, digging into how RSC streams and hydrates might inspire new ways to architect your projects , and build apps that feel snappier without swallowing your CPU or bandwidth.

Originally published at Under The Hood.

Get the next deep dive in your inbox: subscribe to Under The Hood.

I built a backend platform that generates REST APIs from a schema — no code, no server setup

Srikar Phani Kumar Marti — Fri, 29 May 2026 04:09:40 +0000

Every side project I've shipped starts the same way: I have a frontend idea, and I immediately have to stop and go build a backend for it.

Not because the backend is hard. Because it's tedious. The same patterns, every time. Define a model. Wire up routes. Handle errors. Write docs nobody reads. Set up auth. Repeat.

At some point I stopped asking "how do I build this backend faster" and started asking "why am I building it at all?"

That question became Crudly.

What it actually does

You create a project, add a collection (think: a database table with a name and fields), and Crudly instantly gives you a live REST API at:

https://api.crudly.org/v1/{your-project}/{collection-name}

GET, POST, PUT, DELETE — all working, all authenticated, all documented. You didn't write a single line of backend code.

Here's what that looks like in practice. I created a project called sample, added a todos collection, and within about 30 seconds I had:

# List all todos
curl "https://api.crudly.org/v1/sample/todos" \
  -H "Authorization: Bearer YOUR_API_KEY"

# Create a todo
curl -X POST "https://api.crudly.org/v1/sample/todos" \
  -H "Authorization: Bearer YOUR_API_KEY" \
  -H "Content-Type: application/json" \
  -d '{"title": "Repair Watch", "done": false}'

That's it. No Express. No Postgres migrations. No deploy step.

The architecture decision that makes this possible

Crudly doesn't generate code. There's no Express app being scaffolded and deployed per user. That approach sounds appealing until you think about what it costs — cold starts, isolated infra per project, deployment latency, and a maintenance nightmare.

Instead, the API server uses dynamic runtime routing. Every request to api.crudly.org/v1/{project}/{collection} hits the same handler. At request time, it reads your schema configuration, validates the request against it, and serves or persists data accordingly.

The schema is the source of truth. The routes don't exist as code — they're resolved at runtime from what you defined in the dashboard.

This is the same pattern that makes tools like Hasura and PostgREST compelling, except Crudly's surface area is intentionally smaller. You're not writing GraphQL. You're not pointing it at your own Postgres instance. You create a collection, you get endpoints. That's the whole contract.

What ships with it

The thing I kept running into with minimal API tools is that they solve one problem and leave you to figure out everything adjacent. Crudly ships the full surface:

Playground — A browser-based HTTP client (Postman style) built into the dashboard. Select your collection, pick a method, fire a request. I built this because switching to Postman or Insomnia mid-flow kills momentum. The response comes back formatted, with status codes and timing.

Auto-generated docs — Every collection gets docs that reflect the actual schema. They update when the schema changes. The curl examples use your real endpoint URLs. No Swagger YAML to maintain.

Request logs — Real-time traffic visible from the dashboard, filterable by method, status, endpoint, and date. Useful enough that I've caught integration bugs in client apps just from watching the log stream.

Webhooks — POST callbacks on create, update, or delete events per collection. If you're integrating with n8n, Zapier, or your own service — this is how you wire it up without polling.

API key auth — Read-only and read-write keys per project. Generate and revoke from the dashboard. Keys go in the Authorization: Bearer header.

Admin Panel — A generated data dashboard. Browse records, create entries, edit, delete. Useful during development and for non-technical stakeholders who need to manage content.

What I didn't build (deliberately)

No custom logic. No middleware hooks. No computed fields. No joins across collections.

If you need those things, you need a real backend and you should build one. Crudly is not trying to be Firebase or Supabase. It targets a specific use case: you have a frontend, you need persistent data with a REST interface, and you want it running in under five minutes.

The constraint is the feature. Every time I was tempted to add "just a bit of custom logic support," I asked whether it would break that five-minute promise. Usually it would.

Where it actually fits

The use cases where Crudly earns its keep:

Prototyping and MVPs — Wire up a real API before you've decided whether the product is worth building a proper backend for.
Frontend demos and portfolios — Stop mocking data in JSON files. Ship something that actually persists.
Internal tools — A quick admin data store for a side dashboard, without standing up another service.
Hackathons — The entire backend setup takes less time than arguing about which framework to use.

Try it

Crudly is live at crudly.org. Free plan available. Create a project, add a collection, hit the endpoint — it takes about two minutes to get to a working API call.

If you run into anything broken or have a use case it doesn't handle, I'm interested. Still actively building this.

I Ran AI Models Directly in the Browser and Measured What It Did to Core Web Vitals

Srikar Phani Kumar Marti — Sun, 17 May 2026 07:37:49 +0000

Everyone is shipping AI features. Sentiment analysis on user input, speech recognition without sending audio to a server, image classification that never leaves the device. The privacy pitch is real, the latency pitch is real. But nobody's asking the obvious question:

What does running a neural network in the browser actually cost the user?

I decided to find out. I built a benchmark harness, ran four quantized models in Chrome stable, and measured the impact on Core Web Vitals — specifically INP, the metric Google now uses to rank your site.

Here's what I found.

The Setup

The test uses Transformers.js — the library that lets you run Hugging Face models directly in the browser via WebAssembly. All models were loaded in INT8 quantized format (q8) to reflect real production conditions.

Four models, chosen to cover different architectures and modalities:

Model	Params	Task	Architecture
DistilBERT	66M	Sentiment analysis	Encoder (6 layers)
BERT-base	110M	Feature extraction	Encoder (12 layers)
Whisper Tiny	39M	Speech recognition	Encoder-Decoder
MobileViT-S	5.7M	Image classification	Vision Transformer

The benchmark harness is live at benchmark.mspk.me and open source at github.com/srikarphanikumar/cwv-ai-benchmark. Run it yourself.

What Is INP and Why Does It Matter?

INP (Interaction to Next Paint) replaced First Input Delay as Google's interactivity metric in March 2024. It measures how long it takes for the browser to respond to a user interaction — a click, a tap, a keypress — and paint the result.

Google's thresholds:

✅ Good: under 200ms
⚠️ Needs Improvement: 200–500ms
❌ Poor: over 500ms

INP affects your search ranking. More importantly, it affects whether users feel your app is responsive or broken.

When you run neural network inference on the browser's main thread, you're blocking it. That means if a user clicks something while inference is running, their click won't be processed until the model finishes. That delay IS your INP.

The Results

Here's the full table from Chrome stable on an Apple M-series MacBook Pro, 16GB RAM:

Model	Load Time	Avg Inference	INP	INP Class	Mem Δ	Mem Pressure
DistilBERT	7.85s	25.1ms ±0.5	27.8ms	✅ Good	+59.6MB	2.5%
BERT-base	6.07s	83.3ms ±1.5	85.0ms	⚠️ Needs Improvement	+65.3MB	4.1%
Whisper Tiny	6.71s	496.9ms ±6.2	540.3ms	❌ Poor	+123.9MB	7.1%
MobileViT-S	1.15s	66.7ms ±1.0	75.6ms	⚠️ Needs Improvement	+37.0MB	8.0%

The Surprising Findings

1. Parameter count doesn't predict INP

Whisper Tiny has only 39M parameters — the fewest of any model tested. It also produces the worst INP at 540.3ms, more than 19x worse than DistilBERT which has 66M parameters.

The culprit is architecture, not size. Whisper is an encoder-decoder model. It doesn't process the full input in a single forward pass — it runs an autoregressive decode loop, generating output tokens one at a time. Each iteration blocks the main thread. The total blocking time accumulates regardless of how aggressively you quantize the weights.

This means no amount of quantization will fix Whisper's INP on the main thread. It's an architectural constraint, not a tuning problem.

2. MobileViT-S loads 6x faster but still misses "Good"

MobileViT-S loads in 1.15s compared to 6–8 seconds for the text models. That's a huge UX win for initial load. But its INP of 75.6ms puts it in "Needs Improvement" territory despite having only 5.7M parameters.

Vision transformer inference carries disproportionate cost relative to parameter count in WASM environments. Something to watch if you're building image classification features.

3. Memory pressure ≠ memory delta

MobileViT-S has the lowest absolute memory consumption (+37MB) but the highest memory pressure at 8.0%. That 37MB represents a larger fraction of the available JS heap than you'd expect — with implications for mid-range Android devices where heap limits are much tighter.

What This Means for Your Architecture

If you're building with encoder-only text models (DistilBERT class):
You're fine on the main thread. 27.8ms INP is negligible. Trigger inference directly on user interactions without worrying about CWV degradation.

If you're using larger encoder models (BERT-base class):
Don't trigger inference synchronously on interactions. At 85ms, stacking this with other main thread work risks crossing 200ms. Move it to a post-interaction background step — run inference after you've already painted the response.

If you're using any encoder-decoder model (Whisper, T5, BART, etc.):
You must offload to a Web Worker. This isn't an optimization — it's a requirement. The main thread will be blocked for hundreds of milliseconds no matter what you do. Transformers.js supports Web Worker execution natively:

import { pipeline } from '@xenova/transformers';

// Run in a Web Worker to avoid blocking main thread
const transcriber = await pipeline('automatic-speech-recognition', 'Xenova/whisper-tiny', {
  worker: true
});

If you're using vision transformers:
Test on actual mobile hardware before shipping. The memory pressure numbers on an M-series Mac will look very different on a mid-range Android.

Limitations to Know

TBT couldn't be captured in the deployed environment. The Long Tasks API isn't available in cross-origin deployed contexts — only in locally-served or Chrome DevTools Protocol environments. The INP measurements are real, but the full main thread blocking profile requires a different setup to measure properly.

All numbers are from high-end hardware. An Apple M-series Mac is not the median global web user's device. INP values on mid-range Android will be significantly higher — potentially 3–5x. The relative ordering of models should hold, but don't use these absolute numbers as production thresholds for mobile.

Try It Yourself

The benchmark is live and open source. Run it on your device, your network conditions, your hardware profile. Export the results as JSON or CSV.

Live benchmark: benchmark.mspk.me
Source code: github.com/srikarphanikumar/cwv-ai-benchmark
Full paper: arXiv link coming soon

If you run it on a mid-range Android or a low-end device and want to share the numbers, I'd love to see them — that's exactly the follow-on data this research needs.

TL;DR

DistilBERT is the only model that stays in Google's "Good" INP range on the main thread
Whisper Tiny is "Poor" despite being the smallest model — architecture beats quantization
Encoder-decoder models require Web Worker offloading — no exceptions
Parameter count is a bad proxy for browser inference cost
Memory pressure on mobile is a separate concern from memory consumption

The era of client-side AI is here. Now we need to measure what it actually costs.

DEV Community: Srikar Phani Kumar Marti

Debugging React Context Performance Issues: When and Why Components Re-render

The React Context gotcha: Every consumer re-renders on update

Why React doesn’t do partial updates inside context

Common anti-patterns that cause unnecessary re-renders

1. Passing inline objects or functions as value

2. Using one big context for many unrelated values

3. Deeply nested consumers that don’t memoize

Profiling context-related re-renders

How React Context actually triggers updates

Alternatives and patterns to optimize context usage

Use multiple contexts

Use selectors with useContextSelector (third-party)

Lift state closer to where it’s needed

Memoize components and values

When context re-renders are unavoidable

Wrapping up

Helpful learning resources

HTTP QUERY is here: what changes for frontend data fetching?

What is HTTP QUERY, exactly?

Why does safe + body matter?

What does this mean for frontend data fetching?

Complex search filters get a first-class home

GraphQL-style queries get a simpler transport

Caching and CDN behavior improve

Browser and framework support is still catching up

Why you shouldn’t blindly replace all POST /search calls

How to experiment with HTTP QUERY today

What I learned debugging QUERY support in my apps

So is HTTP QUERY the future?

New Newsletter Alert: Under The Hood Has a New Home

Optimizing React Suspense: How Concurrent Mode Handles Data Fetching and Rendering

The familiar pain: flickering loading states

React’s Scheduler and Priorities: The secret sauce

How Suspense boundaries manage concurrent rendering

Data fetching under the hood: how React knows when to show what

Why Suspense fallback flickers , and how to fix it

What actually happens during a Suspense update

Concurrent Mode juggling multiple updates

Why Suspense is still evolving

Wrapping up

React Server Components: Under the Hood of Streaming and Client Boundaries

The familiar pain: mixing server and client logic

Streaming the UI: chunking the response

Client boundaries: the handshake between server and client

How React serializes components

Streaming versus traditional SSR

Architectural implications: clean split of concerns

What I learned debugging a mismatch

Wrapping up

I built a backend platform that generates REST APIs from a schema — no code, no server setup

What it actually does

The architecture decision that makes this possible

What ships with it

What I didn't build (deliberately)

Where it actually fits

Try it

I Ran AI Models Directly in the Browser and Measured What It Did to Core Web Vitals

The Setup

What Is INP and Why Does It Matter?

The Results

The Surprising Findings

1. Parameter count doesn't predict INP

2. MobileViT-S loads 6x faster but still misses "Good"

3. Memory pressure ≠ memory delta

What This Means for Your Architecture

Limitations to Know

Try It Yourself

TL;DR

1. Passing inline objects or functions as `value`

Use selectors with `useContextSelector` (third-party)