DEV Community: Nayan Kyada

Why I Use Next.js + Sanity for Content Sites

Nayan Kyada — Wed, 20 May 2026 17:02:56 +0000

If you’re building a marketing site or content platform, you want three things:

pages that load fast,
content that’s easy to edit,
and an SEO setup you can trust.

For most projects I ship, Next.js + Sanity is the sweet spot.

What Next.js gives you

Great performance defaults: route-based code splitting, image optimisation, and server rendering when needed.
Metadata control: canonicals, Open Graph, Twitter cards, and structured data can be treated as first-class code.
Deployment simplicity: ship to Vercel (or any Node host) and keep it boring.

When Next.js is the right tool (and when it’s not)

Next.js is ideal when you care about speed + SEO + developer velocity together:

Marketing sites with landing pages that must load instantly and share well.
Content sites where posts need to be crawlable, linkable, and structured.
Hybrid apps where some pages are static (blog) and others are dynamic (pricing, dashboards, gated content).

When I don’t reach for Next.js:

If the site is purely static and will never need dynamic data, a simpler static generator can be enough.
If you’re building an internal tool with no SEO needs, you may prioritise different trade-offs.

The SEO primitives you get “as code”

The big win is that SEO becomes part of your engineering surface area:

Canonical URLs: avoid duplicate indexing.
OpenGraph/Twitter: previews that look consistent across platforms.
Structured data (JSON-LD): help Google understand the page type and relationships (author, breadcrumbs, collections).
Sitemaps + robots: generated + validated like any other build artifact.

If you’re building a blog, that means every post can ship with:

a canonical,
a BlogPosting schema,
and a stable OG image route (like /api/og/blog/[slug]).

What Sanity gives you

Flexible content modelling: you can represent real business concepts instead of forcing everything into a “blog post” shape.
Editorial velocity: drafts, previews, and publishing without developer tickets.
Structured SEO fields: titles, descriptions, canonicals, and share images can be part of the schema.

Sanity is not “just a CMS” — it’s a content database

Most teams hit limits when their CMS only supports “Page” and “Post”.
Sanity lets you model the real world:

Authors (with bios, socials, headshots)
Categories (and content verticals)
Reusable blocks (CTAs, testimonials, FAQs)
Relationships (related posts, featured projects, “learn more” links)

That structure is what makes a site scale without becoming chaos.

A blog model that scales (simple but future-proof)

If I’m setting up a blog, I start with a schema that supports:

slug (stable URL)
title + description (SERP + social)
publishedAt (ordering)
tags/categories (internal navigation + topical authority)
body (portable rich text)
optional featured image (sharing + in-article media)

You can keep it lightweight at first, and expand only when you need it.

The trade-offs

Sanity is another system to manage (datasets, roles, previews).
If you only need a handful of posts, MDX in the repo can be enough.

What it costs (so you can plan properly)

More moving parts: environment variables, datasets, permissions, preview URLs.
More decisions up front: your schema design affects how editors work every day.
Preview complexity: “draft vs published” needs a clean workflow (it’s worth it, but it’s work).

None of these are deal-breakers — they’re just real.

How to decide: MDX vs Sanity (quick framework)

Use MDX in the repo when:

you’ll publish infrequently (or you’re the only editor),
you want “blog as code” and don’t need editorial workflows,
you care about shipping fast and keeping infra minimal.

Use Sanity when:

multiple people need to publish,
content types will grow beyond “blog post”,
you want drafts, approvals, and previews,
you want a long-term content pipeline (case studies, landing pages, docs).

A practical implementation plan (what I ship for clients)

Here’s the sequence I follow for a high-performing content site:

Define content types: start minimal (post, author, category).
Build listing + detail pages: /blog and /blog/[slug].
Add technical SEO: canonicals, JSON-LD, sitemap, RSS, OG images.
Add internal linking: “related posts” + links from services/projects pages.
Measure + iterate: Search Console, Core Web Vitals, and content refresh cycles.

Common mistakes I see (and how to avoid them)

Thin posts: short posts without a unique angle won’t build authority. Prefer fewer, deeper articles.
No internal links: link your posts to relevant pages (and between posts) so crawlers understand structure.
Unstable slugs: never change slugs once indexed unless you have redirects.
Missing OG images: social previews matter for distribution (and distribution matters for links).

Signs your WordPress site needs a headless CMS rebuild

Nayan Kyada — Wed, 20 May 2026 17:00:52 +0000

If your marketing team is filing support tickets just to change a headline, or your Google Ads campaigns are bleeding budget because the landing pages load in four seconds, your WordPress site may have hit a structural ceiling — not a content problem, not a design problem. A structural one. These are the signs your WordPress site needs a headless CMS rebuild, and knowing them early saves you from throwing more money at band-aids.

What 'headless' actually means for your business

WordPress bundles everything together: the place editors write content, the code that decides how it looks, and the server that delivers it to visitors. That bundle made setup fast in 2012. In 2026 it creates friction at every layer.

A headless setup separates the content system from the presentation layer. Your editors still log in to a clean dashboard — usually something like Sanity Studio — and write, publish, and schedule exactly as before. But the front end is a purpose-built website (built on Next.js in my projects) that fetches that content and renders it at speed, with full control over layout, performance, and where the content goes next. The content isn't trapped in one theme's templates. It can feed your website, your mobile app, a digital signage screen in your showroom, or an email campaign — all from the same source.

That separation is the point. It removes the ceiling.

The warning signs worth taking seriously

Editors are hacking around the theme. I worked with a sports organisation whose content team had resorted to embedding raw HTML in text fields to get a two-column layout the theme didn't support. They'd built invisible spacer images to control padding. Every new page took 45 minutes and still looked slightly off. This is a sign that the editorial experience has calcified around a theme that was never designed for what the organisation actually needed to publish.

Performance scores are killing paid-ad ROI. A training academy I rebuilt was running Google Ads to a set of course landing pages. Their average mobile PageSpeed score was 41. Industry data is consistent here: pages loading beyond three seconds lose more than half of mobile visitors before the page even finishes loading. The academy's cost-per-conversion was two to three times what it should have been. The WordPress install had eleven active page-builder plugins, four of which loaded JavaScript on every page regardless of whether that page used them. No amount of caching plugin configuration was going to fix that. The payload was structural.

Dev time is eaten by plugin conflicts. When a WooCommerce update breaks the slider plugin which breaks the checkout page, and the fix involves downgrading a security patch — that's not bad luck, that's the compounding cost of a plugin ecosystem with no central contract. One housing developer I worked with was spending roughly two days per month on this kind of firefighting. That's 24 days a year of developer time producing zero new value.

Your content can't go anywhere except the website. The housing developer also wanted to launch a buyer portal — a separate web app where prospective buyers could track a property's construction milestones. All the project descriptions, floor plans, and images lived in WordPress. Getting that content into the portal meant either duplicating it manually or building a fragile custom REST API around a database schema that was never designed to be queried that way. In a headless setup, content is structured from day one to be delivered anywhere via a clean API. The buyer portal becomes a straightforward project, not a six-month integration nightmare.

You're adding pages by duplicating and editing old ones. This is quieter than the others but just as telling. When there's no real component system — just a grab-bag of shortcodes and widget areas — teams default to cloning whatever page last worked. The result is a site with 200 pages that are all slightly different versions of three templates, none of them documented, and any design change has to be made 200 times.

What the rebuild project actually looks like

A typical engagement runs eight to fourteen weeks depending on content volume and integration complexity. The first two weeks are spent on content modelling — mapping what you publish today into structured schemas that will work for years. This is the most important work and the part most agencies skip, which is why rebuilds sometimes recreate the same problems in a new tool.

Editors get a staging Studio environment by week three or four. The goal is for them to feel confident before the old site is retired, not after. By the midpoint, the new site exists alongside the old one. You can compare performance, share it with stakeholders, and catch gaps without any public risk.

Content migration from WordPress is usually scripted — posts, images, and structured data move across without manual copy-paste. The edge cases (custom post types built by a plugin that no longer exists, images stored in twelve different places) are where honest scoping matters. I flag these in discovery so there are no surprises at handoff.

When it's worth it — and when it isn't

A headless rebuild earns its cost when performance is directly tied to revenue (paid advertising, e-commerce, lead generation), when content needs to reach more than one channel, or when editorial bottlenecks are slowing down a team that publishes frequently.

It is not the right call for a five-page brochure site with no editorial team and no plans to grow. WordPress with a well-configured theme and no unnecessary plugins is genuinely fine for that use case. The rebuild conversation is for organisations that have outgrown the bundle — where the original setup is now fighting against what the business needs to do.

If you recognise two or more of the situations above, the question isn't really whether to rebuild. It's whether to do it now or after the next plugin conflict takes down a campaign you can't afford to lose.

Sanity CMS vs Contentful for Next.js projects: an honest comparison

Nayan Kyada — Wed, 20 May 2026 17:00:49 +0000

When a client asks me to recommend a CMS for their Next.js project, the choice almost always comes down to Sanity CMS vs Contentful. Both are mature headless platforms with solid Next.js support, but they make very different bets on query language, pricing, and developer experience. I've shipped production projects on both, and the gap is more nuanced than the marketing suggests.

What you're actually comparing

Contentful is a SaaS-first platform. You get a hosted API, a structured content model editor, and a well-documented REST/GraphQL API. Everything is managed for you — schema migrations, Studio hosting, CDN delivery. That's the value proposition.

Sanity ships a content lake (the hosted backend) plus an open-source Studio that you own, configure, and deploy yourself. Schemas live in your repo as TypeScript files. You query with GROQ, a purpose-built query language. The Studio runs as a Next.js route or a standalone Vite app depending on how you wire it.

That distinction — schema-in-repo vs schema-in-dashboard — changes almost every downstream decision.

GROQ vs GraphQL: the real query language trade-off

This is where most developers form a strong opinion fast.

Contentful's GraphQL API is standard and predictable. If your team already knows GraphQL, you're productive on day one. Tooling like GraphQL Code Generator gives you typed responses with minimal config.

GROQ is Sanity's query language and, after a week with it, I find it meaningfully more expressive for content shapes. You can dereference, filter, slice, and project in a single query without nested fragment boilerplate. Here's a real GROQ query I use for a blog index:

// Used in: app/(blog)/blog/page.tsx
*[_type == "post" && defined(publishedAt) && !(_id in path("drafts.**"))]
  | order(publishedAt desc)[0...12] {
  _id,
  title,
  "slug": slug.current,
  publishedAt,
  "author": author->{ name, "avatar": image.asset->url },
  "categories": categories[]->{ title, "slug": slug.current },
  "lqip": coverImage.asset->metadata.lqip,
  "dimensions": coverImage.asset->metadata.dimensions
}

The equivalent in Contentful GraphQL requires separate authorCollection and categoryCollection queries or deeply nested fragments. It's not unmanageable, but it accumulates friction on complex content models.

The downside for GROQ: it's proprietary. New engineers need to learn it, and there's no ecosystem of generic tooling. Sanity TypeGen partially bridges this by generating TypeScript types from your queries, but you have to run it as part of your build pipeline.

Contentful GraphQL wins on ecosystem familiarity. GROQ wins on expressiveness for relational content.

Pricing for small teams in 2026

This has shifted. As of mid-2026, Sanity's free tier gives you 3 users, 2 non-admin users, and a 500k API CDN request per month limit with 10 GB bandwidth. Their Growth plan starts around $15/month per seat.

Contentful's free tier is more generous on seat count (5 users) but caps content types at 48 and API calls at 1M per month on the Community plan. Their Basic plan starts around $300/month flat, which jumps hard for small teams.

For a freelance engagement with 2–4 editors and a modest content volume, Sanity is cheaper by a wide margin. For enterprise teams already on Contentful with existing contracts, switching cost outweighs the savings.

The Sanity free tier is also genuinely usable for client handoffs — I regularly leave clients on the free plan for low-traffic sites.

Next.js integration DX

Both platforms have official Next.js packages. The experience differs in meaningful ways.

Contentful's contentful npm package is typed but ships its own SDK with a non-trivial bundle size. Fetching content in an RSC looks clean, but you lose granular control over caching because you're going through their SDK rather than native fetch.

Sanity's next-sanity package wraps the Sanity client and plugs directly into Next.js's fetch cache with revalidate tags. This matters for ISR. Here's what a cache-tagged fetch looks like:

// app/(blog)/blog/[slug]/page.tsx
import { sanityFetch } from '@/sanity/lib/fetch'
import { postBySlugQuery } from '@/sanity/lib/queries'
import type { PostBySlugQueryResult } from '@/sanity/types'

export default async function PostPage({ params }: { params: { slug: string } }) {
  const post = await sanityFetch<PostBySlugQueryResult>({
    query: postBySlugQuery,
    params: { slug: params.slug },
    tags: [`post:${params.slug}`],
  })

  if (!post) return notFound()

  return <PostLayout post={post} />
}

The tags array maps directly to on-demand revalidation from a Sanity webhook. Contentful can do tag-based revalidation too, but it requires more manual wiring through their webhook payload.

Sanity also wins on Portable Text. Contentful's Rich Text requires @contentful/rich-text-react-renderer, which outputs relatively flat HTML. Sanity's Portable Text lets you map block types to custom React components — useful when editors need inline callouts, embedded components, or custom image crops inside prose.

Where Contentful wins

Contentful's content model tooling in the web UI is more approachable for non-developers. A content strategist can add a field without touching code. For teams where the CMS owner is not a developer, that matters.

Contentful also has stronger built-in localization support at the field level, a more mature roles and permissions system, and a larger library of third-party integrations (AI assistants, DAM connectors, translation workflows). If you're building for a mid-market brand with a dedicated content ops team, Contentful's workflow features justify the cost.

Where Sanity wins

Schema-in-repo is the right model for teams that treat content structure as part of the codebase. You get version control on your schema, environment-specific studios, and type safety from TypeGen. For a developer-led team, this is a significant productivity edge.

The Studio is also genuinely customizable. Structure Builder, custom input components, and document badges let you shape the editorial experience for your specific content model — not the other way around.

For Next.js specifically, the combination of GROQ's join capabilities, native fetch cache integration, and Portable Text's component mapping makes Sanity the more productive platform for complex page architectures.

How I decide on a new project

Three questions:

Who owns the content model long-term? Developer-owned → Sanity. Marketing/content ops → Contentful.
What's the team size and budget? Under 5 editors on a lean budget → Sanity free tier covers it. Large team with compliance needs → Contentful's enterprise tier might already be the choice.
How complex is the content graph? Many cross-references, portable text with custom blocks, image focal points → Sanity's tooling handles this more gracefully.

Neither platform is wrong. They serve different principals. But for Next.js projects built by a small developer-led team, Sanity's schema-in-code model and GROQ's query expressiveness usually win on the work that actually matters.

Sanity vs Strapi vs Payload CMS: an honest comparison for 2026

Nayan Kyada — Wed, 20 May 2026 17:00:20 +0000

Choosing between Sanity, Strapi, and Payload is one of the questions I get most often from teams starting a greenfield Next.js project. All three are legitimate headless CMS options in 2026, but they solve meaningfully different problems. This post is a direct comparison across the dimensions that actually matter in production: pricing, developer experience, schema modelling, image handling, and how hard it is to leave.

Pricing and hosting model

This is the sharpest difference between the three.

Sanity is fully managed SaaS. You pay per seat on the Growth plan (around $15/editor/month at the time of writing) once you exceed the free tier. The CDN, the Studio, the asset pipeline — all hosted by Sanity. There's no infrastructure to run.

Strapi is open-source and self-hosted by default. You run it on a VPS, Railway, Render, or your own Kubernetes cluster. The Community edition is free forever. Strapi Cloud exists and gives you a managed option, but most teams I've seen pick Strapi specifically because they want control over where data lives — data-residency requirements, GDPR, or just cost certainty at scale. If you have 50 editors, Strapi won't invoice you $750/month for seats.

Payload is also open-source and ships as a Node package that runs inside your own project. There's no separate Strapi-style server — Payload is your backend. It connects to MongoDB or Postgres (Postgres support matured significantly in v3) and exposes a REST and GraphQL API plus a generated Admin UI. Payload Cloud exists for managed hosting, but the local dev story requires zero external services.

Winner on cost at scale: Strapi or Payload — neither charges per-seat, and both can run on hardware you already own.

Winner for teams that don't want to run servers: Sanity.

Developer experience and schema modelling

All three define schemas in code, but the ergonomics differ.

Sanity schemas live in TypeScript files and feed directly into Sanity Studio. The type system is mature, TypeGen generates fully-typed GROQ query results, and the Studio renders your schema as a polished editing UI without extra configuration. The constraint is that Sanity's content lake is a proprietary document store — you don't own the database, and your data model is shaped by Sanity's document/field primitives.

// sanity/schemas/article.ts
import { defineType, defineField } from 'sanity'

export default defineType({
  name: 'article',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: r => r.required() }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
  ],
})

Strapi schemas are defined either through a GUI in the Content-Type Builder or by editing JSON files in src/api/<name>/content-types/. The GUI is beginner-friendly but can produce messy diffs in version control. Teams that commit to code-first schema editing in Strapi end up with a solid workflow, but it takes discipline to avoid drift between local and production schema state. Relations in Strapi map to actual SQL joins, which is useful when you need to run arbitrary Postgres queries alongside the CMS.

Payload schemas feel the most like writing a database ORM. You define collections in TypeScript and Payload generates the Admin UI, REST endpoints, and database migrations automatically. If your team already knows Drizzle or Prisma, Payload's schema syntax will feel familiar. The tight Postgres integration means you can join CMS data with application tables in the same database — a real advantage for product teams building SaaS or e-commerce where content and business data coexist.

// payload/collections/Articles.ts
import type { CollectionConfig } from 'payload'

export const Articles: CollectionConfig = {
  slug: 'articles',
  fields: [
    { name: 'title', type: 'text', required: true },
    { name: 'body', type: 'richText' },
    { name: 'author', type: 'relationship', relationTo: 'users' },
  ],
  admin: { useAsTitle: 'title' },
}

Winner on DX for content-rich sites: Sanity — TypeGen plus GROQ plus the Studio is a complete, opinionated stack.

Winner for Postgres-native product apps: Payload — you get a CMS and an application database in one.

Editor UX

This is where Sanity has a durable lead. The Studio is the most polished editing interface of the three. Real-time collaboration, document presence, Portable Text with inline components, image hotspot editing, and a structure builder for custom navigation — all are production-grade and have been refined over years.

Strapi's Admin UI is functional and non-technical editors can learn it quickly, but it feels like a form builder rather than a publishing tool. There's no equivalent to Portable Text; rich text relies on a Quill or Slate integration that varies by version.

Payload's Admin UI is impressive given how recently it was rebuilt in v3, but it's still primarily developer-facing. For content-heavy teams where editors work daily, the gap with Sanity is real.

Winner on editor UX: Sanity, and it's not close.

Image pipeline

Sanity's image CDN is one of the strongest arguments for the platform. Images are stored in the content lake and served via cdn.sanity.io with on-the-fly transforms: width, height, format (WebP/AVIF), quality, crop, and hotspot-aware focal cropping. Combined with next/image and a custom loader, you get automatic format negotiation and LCP-optimised delivery with minimal setup.

// lib/sanity-image-loader.ts
export default function sanityLoader({ src, width, quality }: ImageLoaderProps) {
  return `${src}?w=${width}&q=${quality ?? 75}&auto=format&fit=crop`
}

Strapi stores uploads locally or in an S3-compatible bucket via a provider plugin. There's no built-in image transform pipeline — you either run your own (Cloudinary plugin is common) or handle transforms at the Next.js layer. More moving parts, more configuration.

Payload handles media similarly to Strapi: uploads go to disk or cloud storage, transforms require a plugin or an external service. The @payloadcms/plugin-cloud-storage covers S3, GCS, and Azure, but image optimisation is still on you.

Winner on image pipeline: Sanity — the built-in CDN with on-the-fly transforms removes an entire category of infrastructure decisions.

Lock-in and portability

This is the honest conversation clients avoid until it's too late.

Sanity stores content in a proprietary NDJSON document store. You can export all data via the API, and the format is readable, but your GROQ queries and schema primitives (especially Portable Text) don't map directly to any other CMS. Migrating away is a project, not an afternoon.

Strapi and Payload both use standard SQL or MongoDB. Your data lives in tables or collections you own. Moving from Strapi to Payload (or to a raw Postgres app) is a SQL migration, not a CMS-to-CMS content export. That's a meaningful difference if you're building something long-lived and want optionality.

Winner on portability: Strapi or Payload — you own the database.

When each one wins

Pick Sanity when editor experience and image delivery are the priority — marketing sites, editorial platforms, content-heavy agencies. The managed CDN, Studio polish, and TypeGen workflow justify the seat cost for most content teams.

Pick Strapi when data residency, self-hosting, or seat-count economics are non-negotiable. Enterprise clients with GDPR requirements and 30+ editors will often mandate self-hosted; Strapi is the most mature option in that lane.

Pick Payload when you're building a product app and want your CMS and application database in the same Postgres instance. Authentication, collections, and business data unified under one Node app, with a generated Admin UI included. It's the option that most blurs the line between CMS and application framework.

Sanity CMS website cost in 2026: what founders actually pay

Nayan Kyada — Wed, 20 May 2026 17:00:19 +0000

Budgeting for a Sanity CMS website is harder than it should be. The platform itself is free to start, which makes early quotes feel reassuring — then the final invoice lands and founders wonder where the number came from. This post breaks down every real cost driver so you can scope a project honestly before you hire anyone.

What drives sanity cms website cost more than anything else

The licence fee is almost never the problem. Sanity's free tier covers most small sites comfortably (up to three users, generous API limits). Growth and custom plan pricing starts to matter around 10+ editors or high-traffic content APIs, but even then you are looking at a few hundred dollars a month at most — not the dominant line item.

What actually drives cost is the work required to model your content, build the editing experience your team will use every day, and connect the site to everything else your business runs on. Let me walk through each layer.

Content modelling is the architectural work done before a single page is built. A developer has to define what a "product", a "case study", or a "press release" looks like as structured data — what fields it has, what relationships it holds, what validation rules prevent editors from publishing broken content. A simple marketing site might need five or six document types. A content platform with tags, authors, series, and gated posts might need twenty, each with their own rules. More document types means more hours, and mistakes here are expensive to fix later.

Page count and template variety compound the modelling work. Twelve pages built from three templates costs far less than twelve pages each with a unique layout. Before you get a quote, list your pages and honestly count how many are genuinely different from each other. Agencies and freelancers price template variety, not raw page count.

The editor experience is underquoted and then complained about. Sanity Studio is highly customisable — you can build a clean, opinionated interface that guides your content team, or you can ship the default and watch editors call you weekly. A well-structured studio with filtered views, conditional fields, and sensible document ordering takes real time to build. Budget for it. It pays back in reduced support requests from your team.

Integrations are where budgets stretch

Sanity stores your content. It does not handle payments, email, search, or video — and most real products need at least one of those.

Stripe: Connecting a product catalogue in Sanity to Stripe for checkout adds meaningful complexity. You need to decide what lives in Sanity (marketing copy, images, variant descriptions) versus what lives in Stripe (prices, inventory, webhooks). Scoping that boundary alone is a half-day conversation. Building it is typically two to four days of development.
SendGrid: Triggered emails off content events — a new post published, a form submitted, a membership renewed — require route handlers that listen for Sanity webhooks and call SendGrid's API. Straightforward in isolation, but each trigger adds test coverage and edge cases.
Algolia: Full-text search across a large Sanity content library almost always lands on Algolia. You need a sync pipeline that pushes content to Algolia when it changes, an index schema that matches your search UX, and a search component on the front end. Expect three to five days for a well-tuned integration.
Mux: Video-heavy sites — course platforms, media brands — use Mux for adaptive streaming. Uploading from Sanity Studio via a custom asset source, storing the Mux playback ID in your schema, and rendering a player with the right poster frame is around two to three days of work.

Each integration is a multiplier, not an add-on. If you want Stripe and Algolia and Mux, those do not add up linearly — shared infrastructure, authentication patterns, and error handling overlap in ways that skilled developers manage efficiently, but the work is real.

Realistic cost ranges for three common project types

Small marketing site — five to eight pages, one blog section, one or two editors, no integrations beyond a contact form and basic analytics.

Design-to-launch freelance rate: £4,000–£9,000 / $5,000–$12,000. Timeline: three to six weeks. Ongoing hosting: £20–£60/month (Vercel hobby or pro, Sanity free tier). This is the profile where Sanity's low entry cost genuinely shines. You get a clean editorial experience and a fast, modern front end at a sensible budget.

Mid-size content platform — blog with authors and tags, gated content, newsletter integration, Algolia search, twenty-plus document types, up to ten editors.

Freelance or small agency rate: £18,000–£40,000 / $22,000–$50,000. Timeline: eight to sixteen weeks. Ongoing hosting: £100–£300/month including Sanity Growth plan, Vercel Pro, and Algolia's starter tier. The range is wide because content modelling complexity and design fidelity vary enormously at this tier.

Complex multi-locale build — multiple languages with separate editorial workflows, market-specific pricing via Stripe, Mux video library, custom Sanity Studio plugins, five-plus integrations, fifteen-plus editors, compliance requirements.

Agency rate: £70,000–£180,000 / $85,000–$220,000. Timeline: four to eight months. Ongoing hosting and tooling: £500–£2,000/month. Internationalisation alone — routing, translation workflows, locale-specific content fallbacks — adds weeks of development that most initial scopes underestimate.

Editor training and ongoing maintenance

Training is skipped in more proposals than I can count. A Sanity Studio that took six weeks to build still needs two to four hours of structured walkthrough for your editorial team, plus documentation written for non-technical staff. Budget £400–£1,200 for this. It prevents three months of avoidable support tickets.

Maintenance is a separate question from hosting. Dependency updates, Sanity schema migrations when your content needs change, new page templates as your business grows — that work is either retained on a monthly contract (£400–£1,500/month is a common range for a freelance retainer) or quoted project by project. Neither is wrong, but know which model you are agreeing to before you sign.

How to get a quote you can actually trust

Before approaching a developer or agency, write down: how many distinct page layouts you need, which third-party tools your site must talk to, how many people will edit content, and whether you need multiple languages. That list turns a vague conversation into a scopeable brief. Developers who quote from a brief are giving you a number they can defend. Developers who quote from a thirty-minute call are guessing — and you will pay for the gap.

INP for React Apps: Profiling and Eliminating Long Tasks

Nayan Kyada — Wed, 20 May 2026 16:59:32 +0000

INP (Interaction to Next Paint) measures how quickly your UI responds after a user interacts.
If a click, tap, or keypress is followed by a noticeable delay, you’ll feel it — and so will your users.

INP is now the key responsiveness metric in Core Web Vitals, and it’s one of the most common issues on React apps that ship too much JavaScript.

What INP actually measures (in plain terms)

When a user interacts, the browser has to:

run your event handler,
run any state updates and rendering work,
paint the next frame.

INP captures the time from interaction to the next paint for the worst interactions users experience (within a page view).

Targets (baseline)

Good: ≤ 200ms
Needs improvement: 200–500ms
Poor: > 500ms

The main causes of bad INP in React apps

In most apps, INP is bad because of one or more of these:

Long tasks (main thread blocked for >50ms)
Render storms (too many components re-rendering)
Heavy work inside event handlers (sync parsing, sorting, filtering)
Third-party scripts (analytics, chat widgets, tag managers)
Too much JS shipped (hydration costs + runtime overhead)

You don’t “optimize INP” by tweaking one thing — you reduce main-thread work and make updates cheaper.

Step 0: Confirm you really have an INP problem

Start with field data:

Search Console’s Core Web Vitals report (pattern-level)
RUM if you have it (best)

Then use lab tools to reproduce:

Chrome DevTools Performance recording
React DevTools Profiler

Step 1: Find long tasks (your #1 enemy)

If the main thread is blocked, the browser can’t paint.

How to spot them

In a Performance recording:

Look for long yellow blocks (scripting).
Zoom into interactions and check what runs right after the input event.

If you see repeated long tasks, you’ve found your INP root cause.

Step 2: Make event handlers “light”

Event handlers should ideally:

update state,
schedule work,
and return quickly.

Common anti-patterns

Doing expensive filtering/sorting synchronously on click
Parsing large JSON payloads during input
Building huge arrays/objects during a scroll/typing event

Fix patterns

Precompute when possible (outside the interaction)
Debounce expensive work triggered by typing
Chunk big work into smaller pieces

Step 3: Reduce React re-render costs

Many INP problems are simply “too much renders happen per interaction”.

What I check first

Are we passing new objects/functions every render?
Are lists re-rendering on every keystroke?
Is global state causing whole pages to update?

Fix patterns that consistently help

Memoize hot components (only where it matters)
Use stable props (avoid {} and () => {} inline for hot paths)
Split state: keep “typing state” local, not global
Virtualize big lists/grids

The goal isn’t to “memo everything”. The goal is to stop re-rendering 200 components when the user clicks one button.

Step 4: Reduce hydration + client JS on content pages

If your page is mostly content (blog posts), you usually don’t need much JS.

Best lever

Avoid turning layout/typography into client components.

Ship interaction only where needed (search box, filters, forms), and keep everything else server-rendered.

Step 5: Defer third-party scripts (they often dominate INP)

Third-party scripts can easily:

add long tasks,
create layout thrash,
or block the main thread during interaction.

Practical strategy

Defer until after first interaction or idle
Load only on routes that need it
Remove anything you don’t use weekly

Most teams keep scripts forever. INP improves fast when you treat scripts like dependencies with a cost.

Step 6: Use a repeatable INP “playbook”

This is my default workflow:

Identify a bad interaction (field data or user report).
Reproduce in DevTools.
Find the longest task after the input event.
Reduce work in the handler.
Reduce re-renders triggered by that state update.
Re-test and confirm the long task is gone.

Quick checklist

Event handlers return quickly
Expensive work is deferred/chunked
Large lists are virtualized
Hot components are memoized appropriately
Client JS is minimized on content routes
Third-party scripts are deferred/audited

Why Core Web Vitals Matter (and How I Improve Them)

Nayan Kyada — Wed, 20 May 2026 16:59:31 +0000

Core Web Vitals are Google’s real‑user performance signals for how a page feels.
They’re not just “speed scores” — they influence:

SEO (page experience is a ranking signal),
conversion rate (slow, janky pages lose users),
trust (fast sites feel higher quality).

If you’re building a marketing site or content platform, improving Core Web Vitals is one of the highest-ROI technical tasks you can do.

What are Core Web Vitals?

Today, the core metrics are:

LCP (Largest Contentful Paint): how quickly the main content becomes visible.
INP (Interaction to Next Paint): how responsive the page is to user input.
CLS (Cumulative Layout Shift): how stable the layout is while loading.

These are measured using real user data (field data), not only synthetic tests.

Target thresholds (what “good” means)

Use these as your baseline:

LCP: good ≤ 2.5s, needs improvement 2.5–4.0s, poor > 4.0s
INP: good ≤ 200ms, needs improvement 200–500ms, poor > 500ms
CLS: good ≤ 0.1, needs improvement 0.1–0.25, poor > 0.25

If you hit “good” consistently, you’ll usually see improved crawl efficiency, higher engagement, and better rankings over time (especially in competitive queries where all content is similar).

Why they matter for SEO (the practical view)

Google has said for years: content relevance wins. That’s still true.
But on the margin — when two pages are equally relevant — performance can be the difference.

Core Web Vitals matter most when:

your niche is competitive (tooling, agencies, SaaS, ecommerce),
users bounce quickly (landing pages, blog posts),
your pages are media-heavy (images, embeds, third-party scripts).

Also: good UX improves how users behave (time on site, browsing depth). Those aren’t direct ranking factors in a simple way, but they correlate strongly with sites that perform well in search.

The “field vs lab” trap

Many teams ship optimisations that look great in Lighthouse but do nothing for real users.
That’s because:

Lighthouse runs on a simulated device/network.
Core Web Vitals in Search Console come from actual users across devices, geos, and connection types.

The right workflow is:

Use field data to find the real problems.
Use lab tools to reproduce and fix them.
Validate again in field data.

How to measure Core Web Vitals (what I use)

Field data (real users)

Google Search Console (Core Web Vitals report): broad view by template.
CrUX (Chrome UX Report): site-level + page-level trends.
RUM (real-user monitoring): best if you want per-route and per-release tracking.

Lab data (debugging)

Lighthouse: quick checks.
Chrome DevTools Performance: deep INP/debug.
WebPageTest: waterfalls, filmstrip, CDN/cache behaviour.

If you can’t measure reliably, you can’t improve reliably.

LCP: the fastest wins (and the common causes)

LCP is usually dominated by one of these:

a big hero image,
a large heading block (custom fonts),
a server response delay (TTFB),
render-blocking CSS/JS.

Fixes that consistently help LCP

Optimise the LCP element Make the hero image properly sized, compressed, and served via CDN.
Preload the right resources Fonts and the actual LCP image should load early.
Reduce TTFB Cache aggressively, avoid expensive server work on first request.
Avoid heavy client-side hydration Keep initial render simple; defer non-critical scripts.

In Next.js, the biggest LCP improvements usually come from image strategy + caching + avoiding unnecessary client components.

INP: responsiveness (the one many teams ignore)

INP measures how quickly the UI updates after an interaction (click, tap, type).
Bad INP usually comes from:

long tasks on the main thread,
expensive React re-renders,
heavy third-party scripts,
too much JS on the initial page.

Fixes that move INP

Reduce bundle size: ship less JS.
Split work: move expensive logic to the server or a worker.
Memoize thoughtfully: avoid re-render storms.
Defer third-party: load analytics/chat widgets after interaction or idle.

If your site is content-heavy (blog), INP improvements often come from simply reducing client JS.

CLS: layout stability (easy to fix, big UX win)

CLS happens when elements move after rendering.
The common causes:

images without dimensions,
fonts swapping late (FOIT/FOUT),
injected banners/popups,
components that load content without reserved space.

Fixes for CLS

Always reserve space for images/media.
Avoid late-injecting UI above content.
Use stable font loading strategies.
Skeletons should match final layout.

CLS is one of the easiest vitals to improve — and users notice immediately.

A simple checklist I apply on every site

Images: correct size, modern formats, CDN, don’t ship huge assets to mobile.
Caching: CDN + edge where possible; avoid dynamic work on every request.
JavaScript budget: keep initial JS minimal, defer non-critical scripts.
Fonts: preload only what you need, limit weights, avoid blocking.
Third-party: audit everything; most scripts are performance tax.

What results to expect

When you improve Core Web Vitals, the most common outcomes are:

better engagement (scroll depth, time on page),
improved conversion rate on landing pages,
more consistent rankings (especially where competitors are similar).

And the best part: these gains compound. Every future page you publish benefits from the same performance foundation.

Sanity vs WordPress headless CMS: when headless actually beats traditional

Nayan Kyada — Wed, 20 May 2026 16:58:09 +0000

Choosing between Sanity and WordPress as a headless CMS is rarely a pure technical question. It involves editor habits, hosting budgets, plugin dependencies, and how much custom work you want to own long-term. I migrated a mid-size marketing site — 400 pages, 3 content editors, ~180k monthly visits — from WordPress (with WPGraphQL) to Sanity + Next.js earlier this year. The numbers below come from that project.

Editor UX: familiarity vs fit-for-purpose

WordPress's editor is genuinely good for people who learned content editing on WordPress. Gutenberg's block library is wide, the media library is tactile, and non-technical editors can add pages without any developer help. That's a real advantage. When I've handed off WordPress sites to marketing teams who already know the platform, training time is near zero.

Sanity Studio is a different experience. The editing surface is structured rather than visual — you fill in typed fields rather than assembling blocks freehand. Editors who come from a publishing or ops background adapt quickly because it feels more like a form than a page canvas. Editors who came from Gutenberg needed about two weeks to stop reaching for the block inserter. The payoff is that the content model is explicit: a "hero" is always a hero, a "testimonial" always has a quote and an author reference, and GROQ queries stay predictable.

For the migration project, I ran both studios in parallel for three weeks. After go-live, none of the three editors asked to go back. The structured model reduced publishing errors — they'd previously broken layouts by pasting rich text with inline styles into heading fields.

Performance: the gap is real

On the old WordPress + WPGraphQL stack, the site averaged 2.8 s LCP on mobile (Lighthouse CI, median of 30 runs, same test pages). After migrating to Sanity + Next.js App Router with ISR, the same pages averaged 1.1 s LCP. TTFB dropped from 480 ms to 60 ms once pages were edge-cached on Vercel.

WordPress headless is not inherently slow — WPGraphQL is capable, and a well-cached WordPress API can perform well. But WordPress still loads PHP, initialises a plugin stack, and hits MySQL on cache misses. Sanity's CDN-backed Content Delivery API returns JSON from an edge node. The ceiling is higher with Sanity once you invest in the query layer.

CLS was the other win. WordPress's media library stores dimensions inconsistently — plugins resize images and lose the originals. Pre-calculating crop dimensions from Sanity's asset metadata let me pass explicit width and height to next/image on every image, eliminating layout shift entirely on image-heavy pages. That work is described in detail in a separate post; the short version is that Sanity stores the original dimensions in the asset document and you can project them at query time.

Developer experience

WordPress headless requires two distinct systems: the WordPress install (PHP, MySQL, plugins, theme files even if unused) and the front-end framework. You maintain both. WPGraphQL adds a third dependency. Schema changes require ACF or a custom plugin, which means PHP. TypeScript types for the API response are hand-written or generated from an introspection query that drifts the moment a plugin updates.

Sanity's developer experience is TypeScript-native end to end. Schemas are TypeScript objects. Sanity TypeGen generates types from those schemas, so your GROQ query results are typed at compile time. The Studio is a React app you extend with your own components. All of this lives in your repo — one deployment target per environment.

// sanity/schemas/post.ts
import { defineType, defineField } from 'sanity'

export const postSchema = defineType({
  name: 'post',
  title: 'Post',
  type: 'document',
  fields: [
    defineField({ name: 'title', type: 'string', validation: r => r.required() }),
    defineField({ name: 'slug', type: 'slug', options: { source: 'title' } }),
    defineField({ name: 'publishedAt', type: 'datetime' }),
    defineField({ name: 'body', type: 'array', of: [{ type: 'block' }] }),
  ],
})
// npx sanity typegen generate → PostDocument type available in queries

The friction point with Sanity is the content model itself. WordPress gives you posts and pages on day one with no schema design required. With Sanity you make decisions upfront — what document types do you need, how do references work, what goes in a global settings document. That's an upfront cost of roughly 8–12 hours on a medium-complexity site, but it pays back quickly in query predictability.

Plugin ecosystem: WordPress wins, with caveats

WordPress has ~60,000 plugins. Sanity has an ecosystem of official and community plugins (Mux video, Cloudinary, desk tools, internationalization) but it's much smaller. If you need a specific integration — a particular payment gateway, a niche LMS, a regional shipping provider — WordPress probably has a plugin. Sanity probably requires custom code.

The caveat is that WordPress plugins have a security and maintenance overhead that compounds. The migration project had 31 active plugins. Twelve of them existed to work around Gutenberg limitations or patch other plugins. Two had unfixed CVEs. Trimming to Sanity + a handful of focused API integrations reduced the attack surface substantially and removed a recurring maintenance cost the client had been absorbing as "normal".

Hosting cost and total cost of ownership

WordPress hosting with WP Engine (Growth plan) was running the client £65/month. Vercel Pro for the Next.js front-end added £18/month. Sanity's free tier covered their usage (under 10k API calls/day). Total after migration: £18/month ongoing, with Sanity free, versus £65/month before.

That's not always the outcome. High-traffic WordPress sites on shared hosting cost less than Vercel Pro. And the migration itself took 6 weeks of developer time — a one-time cost that only makes sense if you're planning to hold the site for 18+ months or if the WordPress maintenance overhead is already significant. I won't pretend Sanity is the cheaper option for a five-page brochure site that's been running on a £10/month shared host for three years.

When to stay on WordPress

WordPress headless makes sense when your team already runs WordPress at scale, when you have heavy WooCommerce dependencies, or when the editor team is large and deeply invested in Gutenberg. WordPress's user management, multisite, and comment/membership ecosystems are genuinely hard to replicate in a custom Sanity setup without third-party services.

WordPress also wins for projects with a tight timeline and a developer who knows the stack. A skilled WordPress developer can ship a new marketing site faster than a Sanity project if the Sanity content model needs to be designed from scratch.

When Sanity headless is the right call

Sanity earns its place when the content model is complex and needs to stay consistent across multiple front-ends (web, app, email), when the team wants TypeScript discipline across the CMS and the front-end, or when long-term maintenance cost matters more than setup speed. The performance ceiling is also meaningfully higher — not because Sanity's API is magic, but because the delivery layer is designed for edge caching from the start, whereas WordPress was designed for server rendering and has been adapted for headless use after the fact.

The migration numbers are real: 60% reduction in LCP, 87% reduction in TTFB on cached pages, and a hosting bill that dropped by more than half. That's a strong case — but it took six weeks to get there, and it would not have been worth it on a shorter-lived project.

How to Fix LCP on Image-Heavy Pages (Next.js Patterns That Work)

Nayan Kyada — Wed, 20 May 2026 16:56:16 +0000

If your page is image-heavy (portfolio, case studies, blogs with hero media), LCP is almost always dominated by one thing:

a hero image,
a gallery grid above the fold,
or an image carousel that loads too much too early.

This post is the exact workflow I use to get LCP < 2.5s reliably on real devices — not just in Lighthouse.

Step 0: Don’t guess — find the true LCP element

Before you change anything, identify what’s actually being reported as LCP.

Where to check

Chrome DevTools → Performance: record load and look for “Largest Contentful Paint”.
Lighthouse: use it to get hints, but verify in DevTools.
Field data: Search Console Core Web Vitals groups by URL pattern; it tells you where to focus.

If the LCP element is a heading, your issues are often fonts, CSS, or hydration.

If the LCP element is an image, your issues are usually bytes + priority + caching.

The main LCP killers on image-heavy pages

In practice, LCP gets worse because of:

Slow TTFB (server work, no caching, cold starts)
Too many bytes (oversized hero images, unoptimised formats)
Bad loading order (the hero image isn’t requested early)
Render-blocking work (fonts, CSS, heavy JS before paint)

You fix LCP by addressing these in order.

1) Reduce TTFB (because LCP can’t start without HTML)

Even perfect images won’t help if the server responds slowly.

Patterns that work

Cache full pages where possible (edge/CDN)
Avoid per-request expensive work on marketing pages (DB calls, heavy Markdown parsing)
Use static generation for content pages
Move non-critical work to after render (analytics, tracking, personalization)

Quick sanity check

If TTFB is > 800ms for most users, fix that first.

2) Ship the right image bytes (format + dimensions)

Most LCP wins come from sending fewer bytes earlier.

Rules I follow

Never serve a 2500px image to a 390px viewport.
Prefer AVIF/WebP when available.
Keep the LCP image as small as possible without looking soft.

Practical targets

Hero image often can be 100–250 KB (sometimes less) and still look great.
Avoid huge PNGs for photos (they’re almost always wrong).

3) Make the LCP request happen immediately

If the browser doesn’t request the hero image early, LCP will suffer even if the image is small.

Next.js patterns that work

Use next/image for responsive sizing and modern formats.
For the hero image, set priority so it’s fetched early.
Ensure the LCP image is not hidden behind a lazy-loaded carousel or a conditional render.

Common mistake

“Lazy-loading everything” feels like the right move but can backfire: the hero should be eager.

4) Use `sizes` correctly (this is where most teams fail)

If you don’t set sizes, the browser might choose a larger srcset candidate than needed.

The goal is simple: tell the browser the rendered width at each breakpoint.

Example thinking (not copy/paste):

If your hero is full-width on mobile, but constrained to 720px on desktop, sizes should reflect that.

5) Preload what matters (but don’t preload everything)

Preloading is powerful when used for the one resource that blocks LCP.

Good preload candidates:

the hero image (if it’s LCP)
the critical font file (if heading/text is LCP)

Bad preload candidates:

multiple gallery images
below-the-fold media

6) Avoid above-the-fold image “work”

Some patterns look nice but destroy LCP:

blur + heavy filters
client-side parallax effects on the hero
large background images applied via CSS that aren’t optimised

If you want motion, apply it after first paint.

7) Reduce JS before paint (especially client components)

On image-heavy pages, you often still lose LCP because the main thread is busy:

large client bundles,
third-party scripts,
hydration costs.

What I do

Keep the hero and initial layout server-rendered.
Move interactive widgets below the fold or load them after interaction.
Audit third-party scripts (most are a tax).

A repeatable debugging workflow (use this every time)

Identify the true LCP element.
Check TTFB and caching.
Check image bytes and format.
Ensure the hero request is early (priority/order).
Fix sizes so the browser chooses the right candidate.
Reduce JS/third-party blocking.
Validate in field data.

Quick checklist for image-heavy pages

LCP element is known (image vs text)
HTML response is cached
Hero image is compressed + correct dimensions
Hero image is requested early (priority)
sizes is accurate
No render-blocking surprises (fonts/JS)
Third-party scripts deferred

How I wire Sanity webhooks to Next.js ISR revalidation with HMAC verification

Nayan Kyada — Wed, 20 May 2026 16:56:15 +0000

Sanity webhooks and Next.js ISR revalidation are a natural pair, but the wiring has a few sharp edges: verifying the request is genuinely from Sanity, deciding between revalidatePath and revalidateTag, and making sure a failed revalidation doesn't silently swallow itself. This post walks through the exact setup I use on production projects.

Why on-demand ISR instead of a fixed interval

Time-based revalidation (e.g. revalidate: 60) is fine for low-traffic blogs, but it has two problems. First, an editor publishes a fix and waits up to a minute for it to appear — which generates support messages. Second, every page revalidates on a timer whether content changed or not, burning unnecessary compute on Vercel or your own infra. On-demand revalidation via Sanity webhooks flips this: pages stay cached until Sanity tells Next.js something changed, then only the affected paths regenerate.

Setting up the Sanity webhook

In Sanity Manage (manage.sanity.io), go to API → Webhooks → Create. Fill in:

URL: https://your-site.com/api/revalidate
Trigger on: Create, Update, Delete
Filter: _type == "post" || _type == "page" (scope it, don't fire on everything)
Projections: {_type, slug} — send only what you need, not the whole document
Secret: generate a random string (32+ chars), copy it into your env as SANITY_WEBHOOK_SECRET

Sanity signs each request with an HMAC-SHA256 signature in the sanity-webhook-signature header. You must verify this before doing anything else.

The route handler

Create the handler at app/api/revalidate/route.ts.

// app/api/revalidate/route.ts
import { revalidatePath, revalidateTag } from 'next/cache'
import { headers } from 'next/headers'
import { createHmac, timingSafeEqual } from 'crypto'

const SECRET = process.env.SANITY_WEBHOOK_SECRET ?? ''

async function verifySignature(rawBody: string, signatureHeader: string): Promise<boolean> {
  if (!SECRET || !signatureHeader) return false

  // Sanity sends: t=<timestamp>,v1=<hex-digest>
  const parts = Object.fromEntries(
    signatureHeader.split(',').map((p) => p.split('=')),
  ) as { t: string; v1: string }

  const expected = createHmac('sha256', SECRET)
    .update(`${parts.t}.${rawBody}`)
    .digest('hex')

  try {
    return timingSafeEqual(Buffer.from(expected), Buffer.from(parts.v1))
  } catch {
    return false
  }
}

export async function POST(req: Request) {
  const rawBody = await req.text()
  const headerList = await headers()
  const signature = headerList.get('sanity-webhook-signature') ?? ''

  const valid = await verifySignature(rawBody, signature)
  if (!valid) {
    return Response.json({ message: 'Invalid signature' }, { status: 401 })
  }

  let payload: { _type?: string; slug?: { current?: string } }
  try {
    payload = JSON.parse(rawBody)
  } catch {
    return Response.json({ message: 'Bad JSON' }, { status: 400 })
  }

  const { _type, slug } = payload

  try {
    if (_type === 'post' && slug?.current) {
      // Tag-based: revalidate just this post and the listing
      revalidateTag(`post:${slug.current}`)
      revalidateTag('posts')
    } else if (_type === 'page' && slug?.current) {
      revalidatePath(`/${slug.current}`)
    } else {
      // Fallback: nuke the whole site — use sparingly
      revalidatePath('/', 'layout')
    }
  } catch (err) {
    console.error('[revalidate] cache invalidation failed', err)
    // Return 500 so Sanity retries the webhook
    return Response.json({ message: 'Revalidation error' }, { status: 500 })
  }

  return Response.json({ revalidated: true, type: _type, slug: slug?.current })
}

A few things worth pointing out in this handler. req.text() comes before any JSON parsing — you need the raw string to recompute the HMAC. Parsing first discards the exact bytes Sanity signed. The timingSafeEqual call prevents timing attacks that could leak whether the secret is partially correct. And the try/catch around the revalidation block returns a 500 on failure, which matters for Sanity's retry logic (covered below).

revalidatePath vs revalidateTag

Both functions invalidate the Next.js Data Cache and the Full Route Cache, but they target different things.

revalidatePath(path, type?) invalidates every fetch call associated with a specific URL path. Use it when a document maps 1:1 to a route — a page type with a custom slug is the clearest case. Passing 'layout' as the second argument also busts nested layouts, which matters if your nav renders from CMS data.

revalidateTag(tag) invalidates every fetch call that opted into that tag via { next: { tags: ['post:my-slug'] } }. Use it for content types that appear on multiple routes — a post shows up at /blog/my-slug but also on /blog (the listing), maybe / (featured posts), and an RSS feed. One revalidateTag('posts') call busts all of them at once.

Tag your fetches at the data layer:

// lib/sanity/queries.ts
export async function getPost(slug: string) {
  return fetch(
    `https://${projectId}.api.sanity.io/v2024-01-01/data/query/${dataset}?query=${encodeURIComponent(postQuery)}&$slug=${JSON.stringify(slug)}`,
    {
      next: {
        tags: [`post:${slug}`, 'posts'],
        revalidate: false, // rely entirely on on-demand revalidation
      },
    },
  ).then((r) => r.json())
}

If you're using the Sanity client rather than raw fetch, wrap it in a Next.js fetch call or use unstable_cache with the same tags. The client's own caching doesn't participate in revalidateTag.

Handling failed webhooks

Sanity retries a webhook when your endpoint returns a non-2xx status. The default schedule is roughly: immediate, 5 s, 30 s, 5 min, 30 min — five attempts total. This means returning 500 on a revalidation error is the right move; Sanity will try again rather than silently dropping the event.

Two failure modes to plan for:

Signature mismatch on legitimate requests. This usually means the secret in your env doesn't match what Sanity stored. Verify by checking the raw header value in your logs and re-generating the secret in Manage if needed. A 401 response does not trigger Sanity retries, which is intentional — you don't want an attacker triggering infinite retries.

Clock skew. Sanity embeds a timestamp (t=) in the signature header. Some implementations reject requests older than 5 minutes. The code above doesn't enforce a time window, but if you want to add it, compare Date.now() / 1000 against parseInt(parts.t) and return 400 if the delta exceeds 300 seconds.

For observability, pipe the console.error in the catch block to whatever you use — Axiom, Better Stack, Sentry. At minimum, log _type, slug, and the error message so you can replay manually from the Sanity webhook delivery log if needed.

Local testing

Sanity can't reach localhost, so use a tunnel. With the Vercel CLI: vercel dev exposes a public URL automatically in some plans. Otherwise, npx localtunnel --port 3000 gives you a temporary URL. Update the webhook URL in Manage, publish a document, and watch the tunnel logs. You can also replay any delivery from the Sanity webhook log under API → Webhooks → recent deliveries — useful when debugging without re-publishing.

Once this is wired up, your editors get near-instant deploys on publish and you stop paying for pages that regenerate on a timer with no content change behind them.

How I wire next/image to Sanity hotspot focal point data for pixel-perfect crops

Nayan Kyada — Wed, 20 May 2026 16:55:32 +0000

Sanity's hotspot and crop fields exist for one reason: editors should be able to mark the subject of a photo once, and every downstream size should respect that mark. The problem is that next/image knows nothing about Sanity's coordinate system out of the box, so you have to wire them together yourself. Here's the exact approach I use on production sites to keep subjects centred across breakpoints without layout shift.

What Sanity stores and what next/image needs

When an editor clicks the hotspot tool in Sanity Studio, two objects are written to the document:

hotspot — { x, y, width, height } where x and y are 0–1 fractions of the original image dimensions.
crop — { top, bottom, left, right } fractions that trim the raw asset before delivery.

next/image accepts an object-position CSS property via its style prop, but it works in percentages of the rendered container — which maps almost directly to Sanity's hotspot.x and hotspot.y values. So the translation is cheap: multiply by 100 and append %.

The @sanity/image-url builder handles the crop rectangle server-side when you call .rect() or let the CDN do it via URL parameters. My preference is to let imageUrlBuilder apply the crop and pass the resulting URL to next/image, then use object-position to keep the hotspot centred in whatever box next/image renders into.

Setting up the image URL builder

Install the package once:

npm i @sanity/image-url

Then create a small utility module:

// lib/sanity-image.ts
import imageUrlBuilder from '@sanity/image-url'
import type { SanityImageSource } from '@sanity/image-url/lib/types/types'
import { client } from './sanity-client' // your configured createClient instance

const builder = imageUrlBuilder(client)

export interface HotspotCrop {
  hotspot?: { x: number; y: number; width: number; height: number } | null
  crop?: { top: number; bottom: number; left: number; right: number } | null
}

/**
 * Returns the CDN URL with crop applied and the CSS object-position
 * string derived from the hotspot coordinates.
 */
export function getSanityImageProps(
  source: SanityImageSource & HotspotCrop,
  width: number,
  quality = 80
) {
  const { hotspot, crop } = source as HotspotCrop

  let urlBuilder = builder.image(source).width(width).quality(quality).auto('format')

  if (crop) {
    // Apply the editor's crop rectangle so the CDN trims the raw file.
    urlBuilder = urlBuilder.crop('freeform').rect(
      // @sanity/image-url rect() wants pixel values; we skip that and
      // rely on the crop object being forwarded automatically when
      // the source contains asset + crop fields.
      0, 0, 0, 0 // placeholder — see note below
    )
    // Simpler: just pass the whole image object; the builder reads
    // _sanityAsset, crop, and hotspot automatically.
    urlBuilder = builder
      .image(source)
      .width(width)
      .quality(quality)
      .auto('format')
  }

  const src = urlBuilder.url()

  const objectPosition =
    hotspot ? `${Math.round(hotspot.x * 100)}% ${Math.round(hotspot.y * 100)}%` : '50% 50%'

  return { src, objectPosition }
}

One clarification on the builder: when you pass the full Sanity image object (the field value that contains asset, crop, and hotspot keys), imageUrlBuilder reads the crop rectangle automatically and applies it to the CDN URL. You do not need to call .rect() manually. The CDN returns the cropped pixel region, and then object-position steers the hotspot within whatever CSS container next/image occupies.

Using the helper in a Next.js component

// components/sanity-image.tsx
import Image from 'next/image'
import { getSanityImageProps, type HotspotCrop } from '@/lib/sanity-image'
import type { SanityImageSource } from '@sanity/image-url/lib/types/types'

interface Props {
  image: SanityImageSource & HotspotCrop & { alt?: string }
  width: number
  height: number
  sizes: string
  priority?: boolean
  className?: string
}

export function SanityImage({ image, width, height, sizes, priority, className }: Props) {
  const { src, objectPosition } = getSanityImageProps(image, width)

  return (
    <div
      className={className}
      style={{ position: 'relative', overflow: 'hidden', width: '100%', aspectRatio: `${width}/${height}` }}
    >
      <Image
        src={src}
        alt={image.alt ?? ''}
        fill
        sizes={sizes}
        priority={priority}
        style={{ objectFit: 'cover', objectPosition }}
      />
    </div>
  )
}

A few decisions worth explaining:

fill instead of explicit width/height. The outer div with a fixed aspect-ratio reserves the space in the document before the image loads, which is what kills CLS. next/image in fill mode injects position: absolute; inset: 0 on the <img> element, so it fills the container exactly.

object-position on the <img>. This is the hotspot translation. If an editor marks a face at 30% from the left and 20% from the top, object-position: 30% 20% keeps that point pinned when the browser letterboxes or pillboxes the image inside the container.

sizes prop. Always pass a realistic sizes string. Something like "(max-width: 640px) 100vw, (max-width: 1024px) 50vw, 33vw" tells Next.js which widths to generate in its srcset. Without it, the browser downloads a much larger file than it needs, which directly hurts LCP.

GROQ projection to pull only what you need

Don't fetch the entire image asset. This projection pulls the minimum fields the builder needs:

// In your page or component query
{
  "image": image {
    asset->{ _id, url, metadata { dimensions } },
    hotspot,
    crop,
    alt
  }
}

The asset-> dereference fetches dimensions so you can compute aspect ratios server-side if you want to set width and height on a non-fill image. For the fill pattern above it's optional, but I always include dimensions so I can drive the aspect-ratio CSS from real data rather than hardcoding it.

Avoiding the common pitfalls

Missing overflow: hidden on the container. If you forget it, the image bleeds outside the reserved space and object-position moves it in a way editors can see but you can't debug easily. Always pair fill with a relatively-positioned, overflow-hidden parent.

Passing hotspot values outside 0–1. Sanity Studio writes normalised fractions, but if you're importing legacy data or using a custom input, validate the range. A hotspot of x: 1.2 will push the image off-screen.

Not forwarding the full image object to the builder. If you pass only asset._ref as the source, the builder ignores crop and hotspot. Pass the whole field value — the object with asset, crop, and hotspot keys — and the builder wires them up automatically.

Over-generating srcset widths. The default Next.js deviceSizes config is broad. For a blog that maxes out at 800 px wide, trim the config in next.config.ts to avoid serving unnecessarily large files to the Sanity CDN.

Once the wiring is in place, editors can move the hotspot handle freely in Studio and every breakpoint crop adjusts without a code change — which is the actual promise of the hotspot feature.

How I use Sanity's structure builder to hide draft noise and speed up editor workflow

Nayan Kyada — Wed, 20 May 2026 16:55:31 +0000

The problem with default Sanity Studio structure

Sanity's default desk structure shows every document and every draft in a flat list. On a production site with 400+ pages, 60 blog posts, and 12 active editors, that list becomes unmanageable. Editors see drafts.blog-post-title and blog-post-title side by side. They ask: "Which one is published? Why are there two?" I've had clients accidentally publish the wrong version because they clicked the wrong item in a crowded list.

The default structure also surfaces internal documents — redirects, global settings, navigation singletons — that non-technical editors should never touch. Every support ticket I avoided started with a custom structure builder config.

How I use structure builder to partition documents

I create a src/sanity/structure.ts file and export a custom structure function. I import it in sanity.config.ts like this:

// src/sanity/structure.ts
import { StructureBuilder } from 'sanity/structure';

export const structure = (S: StructureBuilder) =>
  S.list()
    .title('Content')
    .items([
      S.listItem()
        .title('Pages')
        .child(
          S.documentTypeList('page')
            .title('Pages')
            .filter('_type == "page" && !(_id in path("drafts.**"))')
            .defaultOrdering([{ field: 'title', direction: 'asc' }])
        ),
      S.listItem()
        .title('Blog Posts')
        .child(
          S.documentTypeList('post')
            .title('Blog Posts')
            .filter('_type == "post" && !(_id in path("drafts.**"))')
            .defaultOrdering([{ field: 'publishedAt', direction: 'desc' }])
        ),
      S.divider(),
      S.listItem()
        .title('Site Settings')
        .child(
          S.document()
            .schemaType('siteSettings')
            .documentId('siteSettings')
        ),
      S.listItem()
        .title('Navigation')
        .child(
          S.document()
            .schemaType('navigation')
            .documentId('navigation')
        ),
    ]);

The key line is .filter('_type == "page" && !(_id in path("drafts.**"))'). This GROQ filter hides all drafts from the list. Editors only see published documents. When they click a document, Sanity automatically loads the draft if one exists. This cuts visual noise by 50% immediately.

I also surface singletons — siteSettings, navigation — as direct list items instead of making editors hunt through a "Settings" document type list. One click to the doc they need.

Grouping by status with custom list panes

On a blog with 60 posts, I want editors to see "Published" and "Drafts" as separate lists. I create a child structure with two filtered lists:

S.listItem()
  .title('Blog Posts')
  .child(
    S.list()
      .title('Blog Posts')
      .items([
        S.listItem()
          .title('Published')
          .child(
            S.documentTypeList('post')
              .title('Published Posts')
              .filter('_type == "post" && !(_id in path("drafts.**")) && defined(publishedAt)')
              .defaultOrdering([{ field: 'publishedAt', direction: 'desc' }])
          ),
        S.listItem()
          .title('Drafts')
          .child(
            S.documentTypeList('post')
              .title('Draft Posts')
              .filter('_type == "post" && _id in path("drafts.**")')
              .defaultOrdering([{ field: '_updatedAt', direction: 'desc' }])
          ),
        S.listItem()
          .title('Scheduled')
          .child(
            S.documentTypeList('post')
              .title('Scheduled Posts')
              .filter('_type == "post" && !(_id in path("drafts.**")) && publishedAt > now()')
              .defaultOrdering([{ field: 'publishedAt', direction: 'asc' }])
          ),
      ])
  ),

Now editors see three buckets: Published, Drafts, Scheduled. The publishedAt > now() filter requires a publishedAt datetime field in the schema. I use this pattern on every blog I build. It reduces "Where's my post?" Slack messages to zero.

Hiding internal document types entirely

I have document types like redirect, analyticsEvent, structuredData that only I touch. I don't want them in the desk at all. I filter them out in the structure builder and add them to a hidden "Internal" list:

S.list()
  .title('Content')
  .items([
    // ... public lists
    S.divider(),
    S.listItem()
      .title('Internal')
      .child(
        S.list()
          .title('Internal')
          .items([
            S.documentTypeListItem('redirect').title('Redirects'),
            S.documentTypeListItem('structuredData').title('Structured Data'),
          ])
      ),
  ]);

I collapse "Internal" by default. Editors never see it unless they explicitly expand.

Custom ordering with `defaultOrdering`

Sanity's default ordering is _createdAt desc. For pages, I want alphabetical by title. For blog posts, I want newest published first. For FAQs, I want a manual order field. I set these per list:

S.documentTypeList('faq')
  .title('FAQs')
  .filter('_type == "faq" && !(_id in path("drafts.**"))')
  .defaultOrdering([{ field: 'order', direction: 'asc' }])

This requires an order number field in the faq schema. I use validation: Rule => Rule.required().min(0) to enforce it.

Why this matters for large sites

On a 400-page corporate site I shipped last year, the client had 8 content editors across 3 departments. Before I added structure builder config, they complained the desk was "too cluttered" and "confusing". After I grouped pages by section ("Products", "Resources", "Legal"), hid drafts, and surfaced settings as top-level items, onboarding time dropped from 45 minutes to 15 minutes. Support tickets about "I can't find my page" went to zero.

The structure builder config is 150 lines of TypeScript. It's the highest ROI config file in a Sanity project.

Caveats and edge cases

If you use document internationalization (@sanity/document-internationalization), drafts behave differently. Each locale creates its own draft. I handle this by adding && !defined(__i18n_base) to my filters to hide translation metadata docs.

If you have a document type with thousands of items (product SKUs, for instance), consider adding a search-based list item instead of a flat list. Sanity's default search is fast, but a list of 5,000 items will timeout in the browser.

Structure builder functions are synchronous. You can't fetch data from an external API to build dynamic lists. If you need that, use an action or a custom input component instead.