Forem: Nayan Kyada

How I serve WebP and AVIF from Sanity without double-encoding in Next.js

Nayan Kyada — Mon, 25 May 2026 08:45:03 +0000

Sanity's image CDN and Next.js both offer automatic WebP and AVIF conversion. When you stack them naively — passing a Sanity URL through next/image without thinking — you end up with double-encoding: Vercel's optimisation layer fetches an already-optimised AVIF from Sanity, re-encodes it, and caches a bloated result under a cache key you can't easily predict. I've debugged this on three production sites; here is the setup that avoids it.

Why double-encoding is a real problem

Next.js Image optimisation works by fetching the src URL you pass in, running it through Sharp (or the Vercel edge equivalent), and caching the result keyed on src + width + quality. If that src already points to an AVIF served by Sanity's CDN, Sharp receives a compressed AVIF as input. It decodes it, loses some quality to generation loss, re-encodes it, and stores the result. The cached file is often larger than what Sanity would have served directly, and the /api/image route adds a round-trip for every unique src string.

The practical symptoms are a slow LCP on first uncached load, a 2–4× cache storage increase on Vercel's image cache, and confusing Lighthouse scores where the "serve images in modern formats" audit fires even though your CDN is already doing it.

Understanding Sanity's `auto=format`

Sanity's image URL builder exposes an auto('format') method. When you call it, the CDN sniffs the Accept header on the incoming request and returns AVIF, WebP, or JPEG accordingly — no query-string change, same URL, content-negotiated response.

// lib/sanity-image.ts
import imageUrlBuilder from '@sanity/image-url'
import { client } from './sanity-client'

const builder = imageUrlBuilder(client)

export function urlFor(
  source: SanityImageSource,
  width: number,
  quality = 80
) {
  return builder
    .image(source)
    .width(width)
    .quality(quality)
    .auto('format') // CDN negotiates AVIF/WebP/JPEG per Accept header
    .url()
}

The URL produced looks like:
https://cdn.sanity.io/images/<projectId>/<dataset>/abc123.jpg?w=800&q=80&auto=format

Notice the extension is still .jpg. The format decision happens at the edge, not in the URL. That matters for cache keys, which I'll explain below.

When to bypass `next/image` entirely

If the image is above-the-fold and you have exact width/height from Sanity metadata, you can skip next/image and render a plain <img> with a srcSet built from Sanity URLs. You lose lazy loading and the built-in blur placeholder, but you gain:

Zero Vercel image optimisation costs
Sanity CDN cache hits instead of Vercel cache hits (better global PoP distribution)
A stable, predictable URL for <link rel="preload">

// components/SanityCdnImage.tsx
import { urlFor } from '@/lib/sanity-image'
import type { SanityImageSource } from '@sanity/image-url/lib/types/types'

interface Props {
  source: SanityImageSource
  alt: string
  width: number
  height: number
  priority?: boolean
}

const WIDTHS = [400, 800, 1200, 1600]

export function SanityCdnImage({ source, alt, width, height, priority }: Props) {
  const srcSet = WIDTHS.map((w) => `${urlFor(source, w)} ${w}w`).join(', ')
  const src = urlFor(source, width)

  return (
    <img
      src={src}
      srcSet={srcSet}
      sizes="(max-width: 768px) 100vw, 800px"
      alt={alt}
      width={width}
      height={height}
      loading={priority ? 'eager' : 'lazy'}
      decoding="async"
      fetchPriority={priority ? 'high' : undefined}
    />
  )
}

This works well for hero images where you know width and height at build time from Sanity's asset.metadata.dimensions. For thumbnails in a grid where layout shifts are unlikely and you want lazy loading managed by the browser, this is all you need.

When to keep `next/image` in the pipeline

next/image is worth keeping for:

Images served from a remote origin that isn't Sanity (user-uploaded avatars, partner logos)
Cases where you want the automatic blur placeholder without rolling your own LQIP
Responsive images inside MDX or Portable Text where you don't control the render context

If you do use next/image with a Sanity src, configure the loader to strip auto=format and let Next.js handle format negotiation instead of Sanity. Mixing both means the Accept header is set by Vercel's optimisation server, not the browser, so content negotiation still works — but Sanity will serve AVIF to Vercel's server regardless of the end user's browser support, which is fine but redundant.

The cleaner approach is to set a custom loader that removes auto=format and adds explicit format parameters based on the loader's context:

// lib/sanity-next-loader.ts
import type { ImageLoaderProps } from 'next/image'

export function sanityLoader({ src, width, quality }: ImageLoaderProps): string {
  const url = new URL(src)
  // Remove auto=format — next/image handles format negotiation
  url.searchParams.delete('auto')
  url.searchParams.set('w', String(width))
  url.searchParams.set('q', String(quality ?? 80))
  return url.toString()
}

Pass it as loader={sanityLoader} on any <Image> component that uses a Sanity CDN URL. Now the cache key Next.js builds is based on a plain JPEG URL, and Sharp receives the JPEG — not an AVIF — as input. Quality loss from re-encoding is minimal, and the output size is predictable.

Cache key hygiene

Sanity's CDN caches on the full URL including query parameters. auto=format doesn't change the cache key because format selection is header-based at the Sanity edge — same URL, different response body per client. That means two users with different browser support hit the same Sanity URL and get format-appropriate responses without busting the cache.

Vercel's image cache, on the other hand, keys on the src string as passed to <Image>. If you let auto=format stay in the URL and route through next/image, Vercel caches one response per src + width + quality combination, and that cached response is whatever format Vercel's server negotiated with Sanity (almost always AVIF). Users on older browsers that don't support AVIF will still receive the correct format because the browser never sees the Sanity URL directly — it sees the Vercel /api/image URL. So it isn't broken, just wasteful.

The rule I follow on every project

Above-the-fold images with known dimensions: plain <img> + Sanity CDN + auto=format. Preload with <link rel="preload" as="image" imagesrcset="...">.
Below-the-fold images in grids or listings: same, but no preload.
next/image only when you need blur placeholders or are sourcing from a non-Sanity origin. Use the custom loader to strip auto=format.

This keeps Sanity's CDN doing the format work it's already optimised for, avoids re-encoding overhead on Vercel, and gives you a clear mental model for where each image's cache lives.

What a real Sanity CMS development services proposal looks like

Nayan Kyada — Sun, 24 May 2026 07:36:15 +0000

A Sanity CMS development services proposal should tell you exactly what you're buying, when you'll see it, and what happens when scope shifts. Most proposals I see from developers — including ones I competed against early in my career — skip at least two of those three. Here is what a real one looks like, pulled from a proposal I sent to a mid-sized e-commerce brand in early 2026.

What the proposal structure actually contains

A well-structured proposal is not a price list. It is a project contract in plain language. Mine runs four sections: scope, milestones with deliverables, payment schedule, and change-order policy. Buyers should expect all four. If a developer sends you a single paragraph with a number at the bottom, that is not a proposal — it is a quote, and quotes do not protect either party.

Scope names every content type, every page template, every integration. My 2026 proposal listed: 9 Sanity schema types (product, article, author, category, FAQ, navigation, settings, redirect, legal page), one Next.js App Router front-end, Vercel deployment with preview URLs, and no Algolia or e-commerce API work unless a change order was signed. That last sentence is the boundary. Buyers often gloss over the exclusion list; it is actually the most important paragraph in the document.

Milestones map to real deliverables, not vague phases. Here is the milestone table from that proposal:

#	Milestone	Deliverable	Calendar day
1	Project kick-off	Staging URL live, schema skeleton deployed, Studio login sent	Day 1
2	Schema complete	All 9 document types, content entry guide (PDF)	Day 8
3	Front-end alpha	Every page template rendering from real Sanity data	Day 18
4	QA and revisions	Two rounds of change requests, Core Web Vitals report	Day 26
5	Production launch	DNS cutover, redirects live, handoff call recorded	Day 30

The staging URL on day one is non-negotiable for me. It costs almost nothing to spin up a Vercel preview deployment from a skeleton repo, and it gives the client a live URL they can bookmark, share with their team, and hold me accountable against. A developer who cannot give you a staging URL within 24 hours of kick-off either has no deployment workflow or has not started.

Payment schedule and what a fair split looks like

My standard split for a 30-day Sanity project: 40% on contract signing, 30% on milestone 3 (front-end alpha), 30% on production launch. Some developers ask for 50% upfront on smaller projects, which is reasonable. What is not reasonable is 100% upfront or 100% on completion — the first exposes you to a developer who disappears, the second exposes the developer to a client who stalls sign-off indefinitely.

For projects above ₹5 lakh or $6,000 USD, I split into four payments rather than three, adding a milestone 2 payment. This keeps cash flow predictable on both sides and creates natural checkpoints where either party can raise concerns before too much work has accumulated.

How scope creep is handled in writing

The change-order clause in my proposals reads something close to this:

Any work outside the scope defined in Section 1 — including new schema types, new page templates, third-party integrations, or design changes after milestone 3 — requires a signed change order before work begins. Change orders are priced at [day rate] and billed at the next milestone payment.

That clause protects both of us. Clients get a predictable process rather than surprise invoices. I get a paper trail rather than a verbal request that mutates over three Slack messages. The most common scope creep I see on Sanity projects: a client asks to add a blog after schema was already finalised, or they introduce a product configurator that requires a new document type mid-build. Neither is unreasonable — they just need to be priced and scheduled explicitly.

Red flags to watch for in a proposal you receive

If you are evaluating proposals from multiple developers, here is what to look for:

No staging URL commitment. If the proposal mentions a staging environment but gives no date, the developer has not thought through their deployment setup. Ask them directly: when will I receive a staging URL?

Milestones tied to hours, not deliverables. "Week 1: 20 hours of development" tells you nothing. Milestones should name something you can see — a URL, a document, a deployed schema.

Vague revision policy. "Revisions included" is not a policy. How many rounds? What counts as a revision versus a change order? My proposals specify two rounds of QA changes, each submitted as a single consolidated list.

No exclusion list. A proposal that does not say what is out of scope implicitly includes everything. That is how a ₹3 lakh project becomes a ₹6 lakh project.

Payment on client satisfaction. Final payment tied to subjective satisfaction — rather than a defined deliverable like production deployment — is a recipe for stalled projects. The deliverable should be objective: DNS pointing to the new site, redirects returning 301s, Lighthouse scores above a stated threshold.

What you should ask before signing

Three questions worth asking any developer before you accept a proposal: Who owns the Sanity project dataset if we part ways? (You should.) What is the handoff process — do you get a recorded walkthrough and written Studio guide? Is there a retainer option for post-launch support, and what is the response-time commitment?

Ownership of the dataset is particularly important with Sanity because all your content lives in Sanity's hosted infrastructure. The project ID and dataset should be registered under your organisation's Sanity account, not the developer's. This is a one-minute configuration decision that some developers skip for convenience. Do not let them.

WordPress to Sanity migration cost: does it actually pay back?

Nayan Kyada — Sat, 23 May 2026 11:58:49 +0000

The question I hear most often from founders and marketing directors isn't 'how does Sanity work?' — it's 'what will this actually cost, and will we ever see that money back?' That's the right question. WordPress to Sanity migration cost isn't just the development invoice; it's the full before-and-after picture across hosting, plugins, editorial time, and organic traffic. Let me walk through each piece honestly.

What a migration typically costs to build

Most WordPress-to-Sanity projects I scope fall into one of two buckets.

Smaller content sites — ten to thirty page types, a blog, no complex integrations — run between £6,000 and £14,000 for design-to-deployment work. That assumes the design system either exists already or is being simplified during the migration, and that the editorial team is small (one to five people).

Mid-size marketing or product sites — fifty-plus page types, multi-author workflows, localisation, custom landing-page tooling — land between £18,000 and £40,000. The wide range is real: it depends on how many legacy page layouts need rebuilding and how much content needs manual restructuring rather than automated export.

Those numbers assume a freelance senior developer or a small specialist agency. A large agency will charge more; an offshore team with no Sanity production experience will charge less but often costs more in rework.

The migration itself — exporting WordPress content, mapping it to new Sanity schemas, running import scripts, and validating everything — typically adds £1,500 to £4,000 on top of the build cost depending on post volume and how many custom fields the old site accumulated over the years.

Where the money comes back

Plugin licence savings. A typical WordPress site that's been running for three or more years carries between £800 and £3,000 per year in plugin licences: SEO tools, form builders, page builders, caching plugins, security scanners, backup services, and whatever the previous agency installed and never removed. Most of those jobs are handled differently in a Next.js + Sanity setup — SEO metadata lives in code, forms go through a dedicated service like a simple API route, caching is handled by the CDN and ISR. Realistically, expect to save £600 to £2,000 per year on licences alone.

Hosting savings. Managed WordPress hosting for a site doing 50,000 to 200,000 monthly visits runs £80 to £400 per month, often more if the previous team over-provisioned to handle traffic spikes. Vercel's Pro plan plus Sanity's Growth plan together sit closer to £60 to £130 per month for the same traffic profile. That's a saving of £600 to £3,000 per year, and it scales better — a traffic spike doesn't require an emergency upgrade call with a host.

Editorial efficiency. This one is harder to put a number on but often drives the decision more than hosting costs. WordPress's Gutenberg editor carries years of accumulated complexity, and most content teams I talk to have worked around it rather than with it — duplicating pages instead of using templates, avoiding blocks that behave unpredictably, waiting for a developer every time a new content type is needed. Sanity Studio is purpose-built for structured content. Editors get document-level previews, real-time co-editing, and a schema that matches exactly what they publish — no more orphaned fields from a plugin installed in 2019. Teams I've worked with report saving two to four hours per week in editorial overhead per person. At a conservative £30 per hour, that's £3,000 to £6,000 per year for a two-person team.

Performance and SEO uplift. This is the variable that can dwarf everything else, or amount to nothing, depending on your current baseline. If your WordPress site scores in the 40s on Core Web Vitals and you're competing for commercial search terms, moving to a statically generated or edge-cached Next.js front end typically moves LCP from 4–6 seconds to under 1.5 seconds. Google's ranking signals respond to that. I've seen clients recover from a position-eight plateau to page-one positions within three months of launch — that's meaningful revenue that wouldn't show up in a simple cost comparison. If your site already scores well and ranks well, the SEO case is weaker.

Rough payback calculation

Taking the conservative end: £800 licence savings + £600 hosting savings + £3,000 editorial time savings = £4,400 per year. Against a £12,000 migration project, that's a 2.7-year payback before counting any SEO uplift. If editorial savings are at the higher end and performance improvements move the needle on organic traffic, payback falls inside eighteen months.

Against a £30,000 project, the maths requires either a larger editorial team, real SEO gains, or both.

When the migration doesn't pay back

I'll be direct about this because I turn down projects more often than founders expect.

Low-traffic informational sites — under 5,000 monthly visits, no commercial intent — have no realistic path to SEO-driven ROI, and the licence and hosting savings rarely justify a £10,000+ build.

Happy editorial teams are underrated. If your team knows Gutenberg, has built a workflow around it, and isn't complaining about publishing friction, you're not fixing a real problem. Migrating will create a training and transition cost that erases short-term savings.

No upcoming rebrand or redesign. The cleanest migrations happen when a visual refresh is already planned. Migrating content without touching the design means you're paying for a backend swap the user never sees. The ROI case is much weaker.

Sites with heavily WordPress-specific functionality — WooCommerce, membership plugins, LearnDash — carry significant rebuild cost. It's not impossible, but the project scope balloons and payback extends accordingly.

How to decide

Before agreeing to a scope or signing anything, ask for an audit. A good developer should be able to spend three to five hours reviewing your current plugin list, hosting invoice, editorial workflow pain points, and traffic data, then give you a rough payback estimate. If they can't or won't do that, they're not thinking about your business — they're thinking about billable hours.

The migration only makes sense if the numbers work or the editorial team is genuinely blocked. When both are true, it's one of the highest-ROI technical investments a content business can make.

Five questions to ask before hiring a Sanity CMS developer

Nayan Kyada — Fri, 22 May 2026 07:57:57 +0000

The questions to ask before hiring a Sanity CMS developer are not the ones most founders think to ask. It is tempting to lead with portfolio links and hourly rates, but those tell you almost nothing about whether the person can actually manage a complex content structure, keep your editors happy, or hand the project off cleanly when the engagement ends.

Here are five questions that reveal what you actually need to know.

Question 1: How do you approach schema design before writing any code?

Sanity's real power is its flexible content modelling — but that flexibility cuts both ways. A developer who jumps straight into building document types without a planning phase will create a schema that mirrors whatever the design says today, rather than one that supports how your content actually grows.

What a good answer looks like: They ask about your content governance first. Who creates content, who approves it, and how many content types do you realistically publish? They mention separating content from presentation — keeping a "page" document lean and pulling in shared components through references rather than embedding everything directly. They might talk about planning for reuse across pages or channels.

Red flag: They say they will model the schema directly from the Figma file, or they cannot explain what a reference field is versus an inline object. That approach tends to produce schemas that are hard to query, full of duplication, and painful to extend later.

Question 2: Can you show me a GROQ query you wrote and explain why you structured it that way?

GROQ is Sanity's query language. It is not difficult to learn at a surface level, but writing queries that are efficient, maintainable, and safe to expose in a production application takes real experience. This question is not a quiz — it is an invitation to hear how they think.

What a good answer looks like: They can walk through a real query from a past project, explain what the projection is doing, and describe a problem it solved — such as avoiding unnecessary data being sent to the browser, or resolving a reference in a single round trip. Bonus points if they mention GROQ projections, conditional fields, or query typing with Sanity TypeGen.

Red flag: They say they just copy queries from the Sanity documentation and adjust them. That works for a simple blog, but it is a sign they have not worked through the performance and maintainability problems that come up on any non-trivial project.

Question 3: Walk me through how a content change in Sanity gets to my live site

This is the question most clients forget to ask, and it is the one that matters most for day-to-day publishing. The answer tells you whether the developer has actually shipped a production Sanity project or just built demos.

What a good answer looks like: They describe the full pipeline: an editor publishes in Sanity Studio, a webhook fires to the hosting platform (usually Vercel), and the relevant pages are revalidated so visitors see fresh content within seconds — not hours. They understand the difference between revalidating a single page and triggering a full rebuild, and they know why the former is almost always the right choice. They should also mention that webhooks need to be secured so random requests cannot trigger rebuilds.

Red flag: They say the site will rebuild automatically, but they cannot explain how or how long it takes. A full rebuild on a large site can take five to ten minutes. If your editors publish breaking news or time-sensitive product updates, that is not acceptable, and a developer who does not flag it has probably not thought through your workflow at all.

Question 4: How do you train editors to use the CMS you build?

Sanity Studio can be configured to be genuinely pleasant for non-technical editors — or it can be a wall of fields that nobody wants to use. The developer controls most of that experience, and a good one takes it seriously.

What a good answer looks like: They mention customising the Studio layout so editors see only the document types relevant to them. They talk about adding field descriptions and validation messages written in plain language, not developer shorthand. Ideally they offer a short handoff session — recorded or live — so editors are not left guessing. Some developers also provide a brief written guide tailored to your specific setup.

Red flag: They hand over login credentials and a link to the Sanity documentation. Generic documentation does not explain your custom fields, your publishing workflow, or your specific constraints. Editors who are confused will either publish incorrectly or stop using the CMS altogether, which defeats the purpose of the investment.

Question 5: What does post-launch support look like with you?

Every production CMS project needs some level of support after go-live — a schema change for a new content type, a query that needs adjusting for a new page layout, or a webhook that silently stops firing. How a developer answers this question tells you a lot about how professional they are to work with.

What a good answer looks like: They offer a clearly scoped support period — typically 30 to 90 days — with defined response times and a description of what is included versus what would be a separate engagement. They are transparent about their availability and honest about what falls outside the original scope. They also document what they built: schema decisions, environment variables, webhook configurations, and deployment notes.

Red flag: They say to just message them on Slack if anything comes up. Informal support arrangements collapse when a developer moves to a new client, goes on holiday, or simply becomes harder to reach. You want a paper trail and a process, not a favour.

Hiring the right Sanity developer is less about finding someone who knows the tool and more about finding someone who has shipped real projects, thought through the editor experience, and can explain their decisions clearly. These five questions get you there faster than any portfolio review.

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.