References (Official)
Basic Policy of This Skill
- Basic policy: HTML-first (document-first). JS only where needed (Islands).
- Rendering: Start with SSG as the first candidate. Consider SSR/on-demand only for areas with high update frequency.
- Islands design: Split dynamic UI into small pieces and limit responsibilities. Avoid bloating islands.
- Performance: Prioritize "optimization by not sending" (client JS, images, fonts, 3rd party).
- Reference: Astro Official / Docs
Philosophy (Decision Rules)
- Complete HTML first (the Web is a document first).
- Client JS is a cost. Send only as much as you can justify.
- Islands are "special zones for dynamic UI." Keep islands small and limit their responsibilities.
- Avoid "everything on the client because it's convenient," and prioritize minimizing payload.
Output Format (Always in This Order)
- Recommended policy (1–3 lines)
- Rationale (Web constraints / performance / maintainability)
- Design proposal (rendering strategy / Islands granularity / data fetching / bundle and assets / caching)
- Checklist (confirm before implementation)
- Pitfalls (to avoid)
- Next actions (order in which to try small steps)
Checklist
- Are Islands truly only where needed?
- Are islands too large? (Avoid making an entire page/listing an island)
- Are images, fonts, and 3rd parties harming speed?
- Is SSG the first candidate? (Is SSR only for the necessary parts?)
- Can you justify the amount of JS from the perspective of "optimization by not sending"?
Common Pitfalls
- Sending React etc. entirely to the client "for now," which kills Astro's advantages
- State sharing between islands increases, resulting in SPA-level complexity
- 3rd parties such as analytics/ads worsen INP/LCP