My API Responded in 4 ms, but Navigation Still Felt Slow

I was debugging an internal project management application built with SvelteKit and a Rust API.

Locally, navigation felt almost instant.

On the VPS, opening the Tickets, Timeline, and OpenSpec docs pages felt noticeably slower. Clicking a ticket also took too long before the preview panel became useful.

My first assumption was infrastructure:

• Maybe the VPS was underpowered.
• Maybe PostgreSQL queries were slow.
• Maybe the reverse proxy added latency.
• Maybe SvelteKit SSR was taking too long.

The measurements pointed somewhere else.

The Baseline

I started with the feature list endpoint used by both Tickets and Timeline.

For a project with 52 tickets:

Metric	Result
API response time	~4 ms
Response size	353,956 bytes
Number of tickets	52

The API was not slow.

But it was returning around 354 KB for a list of only 52 items.

The SvelteKit route payload showed the same pattern:

Route	Data payload
Tickets	349,857 bytes
Timeline	354,731 bytes

This explained why local testing was misleading.

On localhost, transferring and parsing a few hundred kilobytes is easy to miss. Once the app runs behind a VPS, reverse proxy, TLS, and a real network connection, the payload becomes much more visible.

What Was Inside the Payload?

I broke down the feature response by field.

The descriptions alone accounted for:

296,177 bytes

That was more than 80% of the complete response.

The list endpoint was returning something similar to this for every ticket:

interface FeatureListItem {
  id: string;
  title: string;
  status: string;
  priority: string;
  storyPoints: number | null;
  dueDate: string | null;

  description: string | null;
  checkoutCommand: string | null;
  openSpecCommand: string | null;
}

The problem was not that these fields were useless.

They were useful on the ticket detail panel.

They were not useful when rendering the initial list.

Timeline was even more wasteful. It used ticket status, dates, dependencies, and assignees, but still downloaded every full Markdown description.

The Data Was Not a Toy List

This mattered because these pages were not rendering a simple table of titles.

In the production project I debugged, the Tickets data looked roughly like this:

Shape	Count
Tickets	52
Completed tickets	52
Tickets with assignees	50
Tickets linked to OpenSpec docs	25
Scheduled tickets	41
Milestones	4
Dependency edges	28
Markdown description text	~299 KB
Largest single ticket description	~19 KB

So the ticket page was not only listing cards. It also had enough metadata to support filtering, preview panels, assignee display, milestones, dependencies, story points, and linked documentation.

The Timeline page reused the same ticket graph, but viewed it differently:

Shape	Count
Scheduled items	41
Items with due dates	41
Items with start dates	35
Assignee lanes	6
Milestones	4
Dependency edges	28

Timeline needed dates, assignees, milestones, dependencies, and enough metadata for hover states and exports.

It did not need 299 KB of Markdown ticket descriptions.

OpenSpec docs had a different problem. The list endpoint was carrying document bodies and their task graph:

Shape	Count / Size
Specs	26
Proposal content	~70 KB
Design content	~164 KB
Tasks markdown content	~97 KB
Spec files JSON	~158 KB
Linked task rows	576
Largest spec content bundle	~36 KB

That data is legitimate on a detail screen.

It is too much for opening the OpenSpec docs menu.

The issue was not that the application had complex data. The issue was that the first navigation step paid the cost of data that belonged to later interactions.

Why SvelteKit Made It Visible

The page loader was straightforward:

const features = await api.getFeatures(projectId);

return {
  features
};

Because features contained the full ticket objects, SvelteKit serialized the complete array into its route data response.

It did not matter that Timeline never rendered description.

The loader returned it, so it crossed the network.

This was the important distinction:

UI usage does not determine the payload. The loader return shape does.

The database query could finish in a few milliseconds while the browser still had to download, parse, deserialize, and hydrate hundreds of kilobytes.

The Root Cause

The feature list endpoint had slowly become a detail endpoint.

It started as a convenient shared API. Over time, more fields were added because different pages needed them.

Eventually, every list consumer received the union of all possible requirements.

That made the endpoint easy to reuse, but expensive to consume.

The same pattern also existed in the OpenSpec docs page. Its list request was carrying full document content even though the initial screen only needed document metadata.

The Fix

I separated summary data from detail data.

The list contract became:

interface FeatureListItem {
  id: string;
  title: string;
  status: string;
  priority: string;
  featureType: string;
  milestone: string | null;
  startDate: string | null;
  dueDate: string | null;
  storyPoints: number | null;
  dependencies: string[];
  labels: string[];
  assignee: CompactUser | null;
}

The detail contract extended it:

interface FeatureDetailItem extends FeatureListItem {
  description: string | null;
  checkoutCommand: string | null;
  openSpecCommand: string | null;
}

The API was split into two responsibilities:

GET /projects/:projectId/features
GET /projects/:projectId/features/:featureId

The first endpoint returns summaries.

The second returns one complete ticket.

The database query for the list endpoint also stopped selecting the description and stopped joining data needed only to generate implementation commands.

Loading the Preview Without Blocking the List

The Tickets page still needed to open a preview panel when a card was selected.

Instead of delaying the entire page, the interaction became:

1. Render the ticket list from summary data.
2. Open the preview shell immediately using the selected summary.
3. Fetch the complete ticket in the background.
4. Cache the detail response by ticket ID.
5. Render the Markdown description when it arrives.

In simplified form:

const featureDetails: Record<string, FeatureDetailItem> = {};

async function loadFeatureDetail(featureId: string) {
  if (featureDetails[featureId]) {
    return featureDetails[featureId];
  }

  const response = await fetch(
    `/projects/${projectId}/features/${featureId}/detail`
  );

  const feature = await response.json();
  featureDetails[featureId] = feature;

  return feature;
}

Direct navigation to a selected ticket still loads the summary list and the selected detail concurrently on the server.

So the optimization did not remove functionality. It changed when the expensive data was requested.

The Result

After separating list and detail payloads:

Response	Before	After	Reduction
Feature list API	353,956 B	36,911 B	89.6%
Tickets route data	349,857 B	30,192 B	91.4%
Timeline route data	354,731 B	34,967 B	90.1%

A selected ticket detail was around:

20,658 bytes

But that payload is now requested only when the user selects the ticket.

The OpenSpec docs page had the same optimization applied:

Response	Before	After	Reduction
OpenSpec docs API	681,558 B	7,257 B	98.9%
OpenSpec docs page data	704,385 B	39,516 B	94.4%

The database was fast before and remained fast afterward.

The meaningful improvement came from sending less data through the complete request path.

What Would Not Have Fixed It

A loading indicator could make the delay less confusing, but it would not remove the delay.

Optimizing the PostgreSQL query would also have targeted the wrong layer. The API already responded in a few milliseconds.

Code splitting the frontend bundle would not remove data returned by +page.server.ts.

The bottleneck was the contract between the list page and the API.

Takeaways

The main lesson was simple:

A fast query does not automatically produce a fast page.

For list-heavy applications:

1. Measure response size, not only response time.
2. Treat list and detail payloads as different contracts.
3. Do not return large text fields unless the current view needs them.
4. Check what the SSR loader serializes into route data.
5. Measure shared endpoints from every consumer's perspective.
6. Lazy-load detail data, but render the interaction shell immediately.
7. Cache detail responses when users may reopen the same item.
8. Do not use a spinner as a substitute for removing unnecessary work.

In this case, the VPS was not the real problem.

It only exposed a payload problem that localhost had been hiding.