home / skills / harborgrid-justin / lexiflow-premium / zero-bundle-size-rsc

zero-bundle-size-rsc skill

safe

/frontend/.github-skills/zero-bundle-size-rsc

This skill minimizes client bundles by leveraging Server Components and streaming, reducing initial JS and enabling zero client-side for static subtrees.

This is most likely a fork of the .github-skills skill from harborgrid-justin

npx playbooks add skill harborgrid-justin/lexiflow-premium --skill zero-bundle-size-rsc

Review the files below or copy the command above to add this skill to your agents.

Files (1)

SKILL.md

890 B

---
name: zero-bundle-size-rsc
description: Minimizing client bundles through aggressive use of Server Components and streaming protocols.
---

# Zero-Bundle-Size React Server Components

## Summary
Minimizing client bundles through aggressive use of Server Components and streaming protocols.

## Key Capabilities
- Partition application graphs into Server/Client subtrees.
- Eliminate data-fetching libraries from client bundles.
- Serialize complex data structures across the network boundary.

## PhD-Level Challenges
- Formalize the serialization constraints of Server Components.
- Analyze the bandwidth vs. CPU trade-off of RSC payloads.
- Implement a dynamic import strategy for polymorphic server components.

## Acceptance Criteria
- Show a reduction in initial JS execute time.
- Demonstrate zero client-side JS for static subtrees.
- Provide a report on payload size reduction.

Overview

This skill helps minimize client bundle sizes by maximizing the use of React Server Components and streaming protocols. It focuses on partitioning application graphs, removing client-side data-fetching dependencies, and serializing server-only state to the client boundary. The result is faster initial load and measurable reductions in client JS execution and payload size.

How this skill works

The skill analyzes component graphs and splits them into Server and Client subtrees, converting eligible components into server-rendered Server Components. It replaces client-side data fetching with server-side data resolution and serializes complex structures across the server/client boundary using an efficient binary/text protocol. Streaming rendering is used to progressively hydrate the UI while keeping static subtrees free of client JS.

When to use it

When initial JS execution time is a critical metric
For pages with large data requirements that can be resolved server-side
When aiming to remove data-fetching libraries from client bundles
For apps that need predictable, minimal client runtime for static or semi-static UI
When you want to measure and prove payload and execution time reductions

Best practices

Audit component graph to identify pure render-only components to convert to Server Components
Keep client components minimal and focused on interactivity only
Serialize only the necessary state and prefer lightweight formats to reduce bandwidth
Use streaming to ship interactive parts progressively and avoid blocking render
Benchmark before and after: measure executed JS time, payload sizes, and perceived load

Example use cases

Legal document viewer where rendering and data assembly run entirely on the server, leaving viewer UI with zero client JS for static pages
Dashboards that stream interactive widgets while keeping the main report static and server-rendered
Forms that validate server-side and only load client JS for final interactive controls
A landing page that delivers fully rendered HTML with no client bundle for static content, enabling faster SEO and lower TTI

FAQ

Will this remove all client-side JavaScript?

Not always. Static subtrees can be zero-JS, but interactive areas still need thin client components. The goal is to minimize, not necessarily eliminate, client JS where interactivity is required.

How do you measure improvements?

Track initial JS execute time, total payload size (JS + serialized RSC payloads), and time-to-interactive. Generate before/after reports showing reductions in payload and execution time.