Something felt slow

Our product backlog list page was sluggish. Not dramatically broken — just… off. The kind of slowness you notice when you switch from a fresh demo tenant to a real one with actual data.

So I measured it:

• 8 items: 206ms TTFB (Time To First Byte)
• 67 items: 675ms TTFB

That's a +469ms difference, or roughly 8ms per item of linear degradation. Every single backlog item added ~8ms to the response time. Not great.

The first instinct was to blame the frontend — maybe the component tree was re-rendering too aggressively. But TTFB ruled that out immediately. The browser hadn't even started rendering; the server was taking that long to respond.

So the bottleneck was somewhere between the API server and the database. Time to dig deeper.

How our preloading works

We run Go + gqlgen + GORM on Cloud Run, talking to Cloud SQL (MySQL). The GraphQL layer is designed around a simple principle:

The client requests only the fields it needs. The server preloads only what's requested.

In practice, our resolver inspects the incoming GraphQL selection set and translates it into GORM Preload() calls. If the frontend asks for tasks { assignees { user } }, the backend dutifully preloads Tasks → Assignees → User. If it only asks for tasks { backlogStatus }, we only preload Tasks → BacklogStatus.

This is the "right" design. The backend trusts the frontend to declare its data needs accurately, and responds with exactly that — no more, no less.

In theory.

What was actually happening

Here's the GraphQL query our list page was firing (simplified):

query GetProductBacklogItems($projectId: ID!) {
  productBacklogItems(projectId: $projectId) {
    edges {
      node {
        id
        name
        storyPoint
        priority
        progress
        backlogStatus { id name status }
        tasks {
          ...SubTaskFields
        }
      }
    }
  }
}

And SubTaskFields looked like this:

fragment SubTaskFields on Task {
  id
  name
  backlogStatus { id name status }
  assignees {
    user { id givenName familyName }
  }
}

See the problem? The list page was requesting tasks { ...SubTaskFields }, and SubTaskFields includes assignees { user { ... } }.

The list page doesn't display task assignees. Not a single component on that page reads task.assignees. But the query was asking for it anyway.

On the backend, this triggered a 4-level preload chain — executed once per backlog item:

For 67 items, that's 67 × 4 cascading database lookups. Every single one hitting Cloud SQL over the network. No wonder it was linear.

Why nobody caught it

This is the frustrating part: the Fragment was doing exactly what it was supposed to do — in a different context.

We have two views for backlog items:

1. List view — shows name, status, story points, progress. No task-level assignee info.
2. Detail view — shows everything, including who's assigned to each subtask.

The detail view legitimately needs assignees { user } inside SubTaskFields. That Fragment was written for the detail view, and it was correct there.

The list view just… borrowed it. Same Fragment, different context, wildly different performance characteristics.

At small scale, nobody noticed. 8 items × 4 preloads adds maybe 64ms. That's noise. But once you hit 50+ items, the linear cost becomes painfully visible.

There's another factor: local dev machines are too fast. In development, the database is either local or in a nearby Docker container — network round-trip is essentially zero. Each preload costs microseconds, so even 4 levels feel instant. In production, every preload is a network hop between Cloud Run and Cloud SQL. That per-hop latency, multiplied by 4 levels × N items, is what turned an invisible overhead into a real bottleneck.

The lesson: GraphQL Fragments are a convenience for the developer, not a contract about data needs. When you share a Fragment across views with different display requirements, you're silently opting into preloads you don't need.

The fix

Step 1: Remove the unnecessary field from the list query

The obvious move — stop asking for tasks { ...SubTaskFields } in the list query:

query GetProductBacklogItems($projectId: ID!) {
  productBacklogItems(projectId: $projectId) {
    edges {
      node {
        id
        name
        storyPoint
        priority
        progress
        backlogStatus { id name status }
        # tasks removed — list page doesn't render subtask details
      }
    }
  }
}

But there's a catch.

Step 2: The progress field still needs task data

The progress percentage on each backlog item is computed server-side from its child tasks. Specifically, it counts how many tasks are completed vs. total. To do that, the server needs to load Tasks and Tasks.BacklogStatus.

If the frontend stops requesting tasks, the backend stops preloading them, and progress silently returns 0 for everything. That's worse than slow.

Step 3: The EnhanceFields pattern

We already had an established pattern for this: field injection helpers that ensure required preloads exist regardless of what the frontend asks for. We use the same approach for project stats and team stats.

The idea is simple: before passing the requested fields to the preload layer, check whether the fields needed for server-side computation are present. If not, inject them.

func enhanceFields(fields []string) []string {
    // If the client didn't ask for "tasks" at all,
    // inject the minimum needed for progress calculation.
    if !contains(fields, "tasks") {
        fields = append(fields, "tasks", "tasks.backlogStatus")
    }
    return fields
}

In the resolver, this helper sits between the selection set parser and the preload builder:

func (r *resolver) ListItems(ctx context.Context, ...) {
    fields := enhanceFields(getRequestedFields(ctx))
    // fields is now guaranteed to include "tasks" + "tasks.backlogStatus",
    // but NOT "tasks.assignees" or "tasks.assignees.user"
    items := r.repo.FindAll(ctx, filters, fields)
    // ...
}

The key insight: the list and detail views now have asymmetric preload depths. The detail view still gets all 4 levels (the frontend asks for them). The list view gets only 2 — just enough to compute progress, without dragging in assignee data it never displays.

The result

5× faster. The ~8ms/item linear degradation effectively disappeared.

And the best part: the detail view is completely unaffected. It still requests tasks { ...SubTaskFields }, and the EnhanceFields helper is a no-op when hasTasks is already true. Zero behavioral change for the detail page.

What I'd do differently

A few takeaways from debugging this:

• TTFB is your first diagnostic. If TTFB scales linearly with item count, the problem is server-side. Don't waste time profiling React renders until you've ruled out the API.

• Fragments are a DX convenience, not a data contract. The moment you share a Fragment across views that render different sets of fields, you've created an invisible coupling between those views' performance profiles. Consider having SubTaskFieldsList and SubTaskFieldsDetail instead of one shared Fragment.

• "The server only loads what you ask for" only works if you ask correctly. GraphQL's promise of precise data fetching relies on the query author being precise. The server is faithfully doing what it's told — the problem is always in what you're telling it.

• Linear degradation hides in small datasets. 8ms/item is invisible at 8 items. It's a wall at 100. If you only test with seed data, you'll never catch this class of issue. Profile with production-scale data counts.

This article is based on a real performance fix in Lasimban, a task management SaaS built for Scrum teams. It's free to use — no credit card required.

Try Lasimban for free → lasimban.team

Have you run into similar Fragment-sharing traps in your GraphQL setup? I'd be curious to hear how other teams handle the list-vs-detail preload split.