Back to list
h2b-dev-studio

sdd-design-perf

by h2b-dev-studio

웹 기술을 탐색하고 실험하기 위한 개인 공간입니다.

0🍴 0📅 Jan 20, 2026

SKILL.md


name: sdd-design-perf description: | Design bundle strategy, lazy loading, and render optimization. Use when: sdd-design assigns Performance Strategy section. Triggers: "performance design", "bundle size", "lazy loading", "optimization"

SDD Design Perf

Write the Performance Strategy section of a design document.

Scope

Responsible ForNot Responsible For
Bundle budgetComponent structure (→ frontend)
Library selection (size)Library API fit (→ frontend)
Code splitting strategyState management (→ frontend)
Lazy loadingVisual loading states (→ uiux)
Render optimizationInteraction design (→ uiux)
Caching strategySecurity headers (→ security)

Cross-Cutting Roles

Note: Cross-cutting concerns are an extension to docs/sdd-guidelines.md for specialist coordination. See sdd-design for full mapping.

Perf is:

  • Primary owner: (none in typical frontend projects)
  • Reviewer for: Loading states (owned by uiux), Code display (owned by frontend)

Instructions

Step 1: Read Context

  1. Design skeleton (from sdd-design)
  2. All REQs in your section's @derives
  3. Foundation anchors (especially CONSTRAINT-* for size limits)
  4. Frontend section (for library candidates)

Step 2: Identify Performance Requirements

Extract from REQs:

REQPerformance Implication

Look for:

  • Explicit size/speed constraints
  • "Fast", "instant", "responsive" language
  • Large data sets, many items
  • Mobile/low-power device mentions

Step 3: Define Bundle Budget

Based on REQ constraints:

CategoryBudget@derives
Initial JS{X}KBREQ/CONSTRAINT
Lazy chunks{X}KBREQ/CONSTRAINT
CSS{X}KBREQ/CONSTRAINT
Total{X}KBREQ/CONSTRAINT

If no explicit constraint: Use sensible defaults based on project type.

Document with @derives linking to REQ or CONSTRAINT.

Step 4: Select Libraries

Review frontend's candidates against budget:

PurposeCandidatesSize (gzip)Selection@derives
CONSTRAINT-XXX

Selection criteria:

  • Fits within budget
  • Tree-shakable preferred
  • No unnecessary features

Step 5: Design Code Splitting

Based on user flow from REQs:

ChunkContentsLoad TriggerSize
mainCore UIImmediate

Principles:

  • Critical path in main bundle
  • Features on-demand
  • Route-based splitting when applicable

Step 6: Design Lazy Loading

For heavy resources:

ResourceStrategyTrigger@derives
REQ-XXX

Strategies:

  • Route-based: React.lazy()
  • Scroll-based: Intersection Observer
  • User-action: On click/expand

Step 7: Identify Render Optimizations

For REQs with "real-time" or "immediate" language:

OptimizationWhereTechnique@derives
REQ-XXX

Common techniques:

  • React.memo for pure components
  • useMemo / useCallback for expensive computations
  • Virtualization for long lists

Step 8: Define Caching Strategy

ResourceCacheTTL
Static assetsImmutable

Step 9: Define Metrics

MetricTargetMeasurement
LCP<{X}sLighthouse
FID<{X}msLighthouse
CLS<{X}Lighthouse
Bundle size<{X}KBBuild output

Step 10: Write Section

## Performance Strategy

@derives: {REQ-IDs}

### Bundle Budget
### Library Selection
### Code Splitting
### Lazy Loading
### Render Optimization
### Caching Strategy
### Performance Metrics

**Status:** draft

Step 11: Add Decisions

For library selections and trade-offs:

| ID | Decision | Rationale | Owner |
|----|----------|-----------|-------|
| DEC-00x | {what} | {why — connect to budget/REQ} | perf |

Step 12: Handoff

Per docs/sdd-guidelines.md §4.3 and §10.6.

1. Update Section Status

**Status:** verified

2. Update State File

# .sdd/state.yaml
documents:
  design:
    sections:
      perf: verified

3. Create Handoff Record

# .sdd/handoffs/{timestamp}-perf.yaml
from: sdd-design-perf
to: sdd-design
timestamp: {ISO-8601}

completed:
  - design.perf: verified

in_progress: []

blocked: []

gaps: []

next_steps:
  - sdd-design-frontend: Use selected libraries
  - sdd-design-uiux: Review — loading states align with lazy loading

4. Cross-Cutting Status

ConcernPrimaryReviewerStatus
Loading statesuiuxperfapproved or needs-revision
Code displayfrontendperfapproved or needs-revision

@derives Judgment

A performance decision @derives from a REQ when:

CriterionExample
Satisfies REQ's size constraintLibrary selection → CONSTRAINT-LIGHTWEIGHT
Enables REQ's speed requirementLazy loading → REQ's "instant load"
Addresses REQ's scaleVirtualization → REQ's "1000+ items"

NOT @derives:

  • Generic optimizations not tied to REQ
  • Premature optimization without constraint

Verification

  • Bundle budget defined and justified
  • Library selections within budget
  • Code splitting covers all lazy-loadable features
  • Lazy loading for heavy resources
  • Render optimizations for "real-time" REQs
  • Decisions logged with rationale
  • Cross-cutting reviews completed

References

FileContent
reference/bundle-analysis.mdHow to analyze and optimize bundles
reference/library-sizing.mdCommon library sizes for comparison

Examples

FileContent
examples/react-sample.mdComplete example for react-sample package

Score

Total Score

50/100

Based on repository quality metrics

SKILL.md

SKILL.mdファイルが含まれている

+20
LICENSE

ライセンスが設定されている

0/10
説明文

100文字以上の説明がある

0/10
人気

GitHub Stars 100以上

0/15
最近の活動

3ヶ月以内に更新がある

0/10
フォーク

10回以上フォークされている

0/5
Issue管理

オープンIssueが50未満

+5
言語

プログラミング言語が設定されている

+5
タグ

1つ以上のタグが設定されている

0/5

Reviews

💬

Reviews coming soon