Case Study

Explorer Payload Optimization

Separating recent-block summary data from full block responses to improve list-view performance while preserving complete block data for detail pages and richer consumers.

Summary

Role

Full-stack implementation

Scope

Recent blocks list, block detail API, backend endpoint design, database query path, frontend list rendering

Focus

Payload size, API/UI contract alignment, list/detail data boundaries

Outcome

Reduced list responses from roughly 3–5 MB to 5–10 KB

TL;DR

I split the explorer list and detail data paths, reducing recent-block responses from roughly 3–5 MB to 5–10 KB while preserving full detail views.

Context

The blockchain explorer needed to support a fast, scannable recent blocks list while block detail pages and richer consumers still required complete block data.

Each recent-block row only needed summary data such as block height, timestamp, and transaction count. The full block endpoint remained necessary for complete block information, including richer block data and transaction details, but that payload should not have been fetched for every row in the list view.

Problem

The recent-block list was using a full-detail response even though the UI only needed height, timestamp, and transaction count.

List / Detail API Split

List / Detail API Split Response shape matched to UI path

Payload reduction

Before 3-5 MB

Full block objects on the list path

After 5-10 KB

Compact summary rows for scanning

List path

Recent blocks listScanning surface

Summary endpointList-ready contract

Summary fieldsBlock height · timestamp · transaction count

5–10 KBList response

Detail path

Block detail pageInspection surface

Full endpointDetail contract

Complete block dataTransactions remain available

The optimization came from matching the response shape to the UI consumption pattern: compact summaries for scanning, complete block data for detail views.

Ownership

This was a full-stack project. I implemented the frontend changes, backend API changes, and related database work myself.

I identified the mismatch between the recent-block list UI and the full block response shape, split the list and detail consumption paths, and aligned the frontend around a lightweight summary response backed by a more appropriate database query path.

Approach

Inspect the real bottleneck

About a week after launching the blockchain explorer, the recent blocks page became noticeably slow. I inspected the network responses and found that the list page was fetching full block objects, including transaction details, even though the UI only needed compact row data.

Split list and detail contracts

I implemented a lightweight summary endpoint for recent-block list views and kept the full block endpoint for detail pages and consumers that needed complete block data.

Preserve full detail path

Kept the complete block endpoint available for detail pages and richer consumers while the list moved to compact summary data.

Impact

Before

3-5 MB

After

5-10 KB

Boundary

List / detail split

Compatibility

Full detail preserved

Follow-through

Improved recent-block page performance and scanability

Kept full block data available for detail pages and richer consumers

Made list payload size independent from the number of transactions inside each block

Trade-offs

A separate summary endpoint adds another API surface to maintain
Summary fields must stay aligned with what the list UI actually displays
Keeping both summary and full block contracts preserved compatibility while improving the high-frequency list path

Closing

The main lesson was that frontend performance is often a contract problem, not just a rendering problem — and when you own the full stack, you can fix the contract at the right layer.