Slice the Payload: How GROQ and Preview Mode Cut Costs in Sanity‑Powered Sites

Why the Payload Matters

When a static site pulls data from a headless CMS, the first thing that can kill performance is over‑fetching. A typical fetch might return an entire document – dozens of fields, images, and nested objects – even though the page only needs a headline, a slug, and the author’s name. The extra data inflates the bundle size, slows the build, and can push you over API rate limits.

Enter GROQ: A Precise Query Language

Sanity’s Graph‑Relational Object Queries (GROQ) let you describe exactly what you want. Think of it as a lightweight, JSON‑friendly version of GraphQL that can express nested relationships and filters in one line.

Typical query for a list of blog posts:

*[ _type == "post" && publishedAt < now() ]{
  title,
  slug,
  author->{name},
  mainImage{asset->{url}}
} | order(publishedAt desc)

Breakdown:

• *[ _type == "post" && publishedAt < now() ] – filter only published posts.
• Curly braces specify the exact fields to return.
• Nested author->{name} pulls the author’s name from the referenced author document.
• Image URL is resolved through asset->{url} to avoid returning the whole asset object.

Running the Query

From the command line, you can test the query with the Sanity CLI:

sanity dataset preview-contents --query "*[ _type == \"post\" && publishedAt < now() ]{title, slug, author->{name}, mainImage{asset->{url}}} | order(publishedAt desc)"

Replace preview-contents with your dataset name. You’ll need a user token with read access. The CLI prints a JSON array of the requested fields.

Real‑Time Preview: Stream the Changes

Sanity’s Studio can push live edits to a front‑end via a preview channel. The client library listens for preview events and re‑fetches the updated document using a lightweight query.

Next.js example:

import { usePreviewSubscription } from "./lib/sanity";

export default function Post({ post }) {
  const { data } = usePreviewSubscription(`*[_id == $id]{title, body}`, {
    params: { id: post._id },
    initialData: post,
  });

  return {data.title};
}

When a content editor updates a post, the Studio emits a preview event. Your site receives it, runs the same GROQ query, and re‑renders the component instantly.

Trade‑Offs to Keep in Mind

• Learning Curve: GROQ syntax is concise but unfamiliar to those used to GraphQL or SQL. A quick cheat‑sheet or the official docs can help.
• Rate Limits: The Sanity API allows 100 000 requests per month for the free tier. Frequent preview requests from many editors can quickly consume this quota. Consider throttling or batching preview updates if you have a large team.
• Complexity vs. Simplicity: For very simple data models, a raw REST call might be easier to understand. GROQ shines when you have nested references or need to filter on computed fields.

Actionable Checklist

1. Define the minimal field set you need for each page type.
2. Write a GROQ query that returns exactly those fields.
3. Test the query with the Sanity CLI to verify payload size.
4. Enable preview mode in Studio and wire a front‑end preview subscription.
5. Monitor API usage and adjust query frequency if you hit rate limits.

By tightening the data you fetch and leveraging Sanity’s live preview channel, you’ll see faster builds, smaller bundles, and a smoother editorial workflow.