This 3-part guide helps you maximize the potential of the Hygraph API. In the last part of this guide, we walked through how Hygraph serves your content and how to work with rate limits. Today, we will look at how to optimize query performance and schema design.
#Optimizing query performance
Well-designed queries are the foundation of a responsive application. Here are some useful tools to help you optimize your queries.
Query optimization strategies
1. Use appropriate fetch sizes
Match your first parameter to actual needs:
# ❌ Over-fetching for a single resultquery {pages(where: { slug: "about" }, first: 1000) {title}}# ✅ Right-sized for the use casequery {pages(where: { slug: "about" }, first: 1) {title}}
2. Fetch only required fields
Select only the fields your UI actually uses:
# ❌ Fetching everythingquery {post(where: { id: "..." }) {idtitlebodyauthorcommentsmetadataseoDatarelatedPosts}}# ✅ Fetching what's needed for the card componentquery {post(where: { id: "..." }) {idtitle}}
3. Implement pagination
For collections, use cursor-based pagination to fetch data in manageable chunks:
query GetPaginatedPosts($first: Int, $after: String) {postsConnection(first: $first, after: $after) {edges {node {idtitleslug}cursor}pageInfo {hasNextPageendCursor}}}
4. Optimize union queries
Modular content blocks using unions can become expensive. A two-step approach reduces complexity:
Step 1: Fetch block types and IDs
query {page(where: { id: "..." }) {titleblocks {__typename... on Node {id}}}}
Step 2: Batch-fetch blocks by type
query BlockContent {heroes: heros(where: { id_in: ["id1"] }) {titlectaLink}grids: grids(where: { id_in: ["id2", "id3"] }) {titlesubtitle { markdown }}}
This pattern converts one expensive union query into multiple simpler, more cacheable queries.
#Schema design for performance
Many optimization opportunities exist at the schema level. Thoughtful content modeling pays dividends in query performance and cache efficiency.
Performance-oriented principles
1) Separate editorial and delivery concerns
Design models that serve clear purposes rather than trying to handle every use case:
| Instead of... | Consider... |
|---|---|
One Page model with 50+ fields | Separate LandingPage, ArticlePage, ProductPage models |
| Deep bi-directional references everywhere | Selective references based on query patterns |
| Large unions with many component types | Curated unions per use case |
2) Prefer flat structures on high-traffic paths
Homepage and navigation queries are executed frequently. Keep these data structures shallow and purpose-built.
3) Limit reference depth
Each level of nested references multiplies query complexity. For frequently-accessed content, consider denormalizing data that would otherwise require deep traversal.
4) Standardize asset usage with wrapper components
Rather than referencing assets directly across many models, use a consistent component pattern:
ImageBlock (Component)├── asset (Asset reference)├── altText├── caption└── attribution
This simplifies asset queries and enables consistent optimization across your schema.
#Quick reference: Diagnostic checklist
Slow Queries?
| Check | Action |
|---|---|
| Fetch size appropriate? | Match first to actual needs |
| Deep nesting? | Consider query splitting |
| Large unions? | Use two-step pattern |
#What’s next
Optimizing queries and schema design is only part of the performance story. We hope that this guide has been helpful for you. In the final part of this guide, we’ll focus on managing asset traffic. If you have any questions about mastering the Hygraph API, you can reach out to us at support@hygraph.com.
Blog Authors