Zhenyang Tang

Case Study

← Back to selected work

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

Overview

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.

The key product requirement was to keep the recent blocks page useful for scanning, rather than reducing the number of blocks per request.

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 issue was not only page rendering. The API contract did not match the UI consumption pattern for the high-frequency recent-block list.

  • Recent-block rows only needed summary data such as block height, timestamp, and transaction count
  • The full block response included richer block data and transaction details
  • The list path was fetching complete block information for every row
  • The frontend had to parse and hold data the list UI did not display
  • The product needed better performance without removing complete block data from detail pages or richer consumers

List / Detail API Split

List / Detail API Split Response shape matched to UI path

Before: list path fetched detail data

Recent Blocks ListScanning surface
Full Block APIComplete block path
Full block objectsIncludes transaction details
3–5 MBList response

After: list path uses compact summary data

Recent Blocks ListScanning surface
Summary Blocks APIList-ready path
Summary fieldsBlock height · timestamp · transaction count
5–10 KBList response

Preserved detail path

Block Detail PageInspection surface
Full Block APIComplete block path
Complete blockTransaction details 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.

Own the full stack path

Because I owned the frontend, backend, and database implementation, I could optimize the entire path: database query shape, API response shape, and frontend rendering model.

Keep scanability without reducing product value

I considered returning fewer blocks per request, but that would make the page less useful. The better fix was to preserve the list experience while reducing the payload for each row.

Impact

  • Reduced recent-block list responses from roughly 3–5 MB to around 5–10 KB
  • Improved recent-block page performance and scanability
  • Removed unnecessary transaction details from the list path
  • Kept full block data available for detail pages and richer consumers
  • Made list payload size independent from the number of transactions inside each block
  • Created a reusable list/detail API pattern for future explorer surfaces
  • Demonstrated full-stack ownership across frontend, API design, and database-backed data modeling

Trade-offs

  • A separate summary endpoint adds another API surface to maintain
  • Summary fields must stay aligned with what the list UI actually displays
  • Reusing the full block endpoint was simpler initially, but became inefficient as transaction activity grew
  • Returning fewer blocks would reduce page usefulness, while the summary endpoint solved the actual root cause
  • 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.