Documentation topic
Performance
Core guides
Start with the architecture
These guides carry the main argument for this topic. The full library below goes deeper into individual implementation decisions.
Why our sites are unusually fast
Why our sites tend to perform well: server-first rendering, narrow JavaScript boundaries, controlled media, restrained third parties, and less unnecessary runtime work.
Read the guideHow we decide what gets to load before the page becomes useful
A practical look at the critical rendering path: which fonts, images, scripts, and interface behaviors deserve early bandwidth and which ones should wait.
Read the guideOur JavaScript budget
JavaScript is powerful, but it is also one of the most expensive resources a browser can receive. It has to be downloaded, parsed, compiled, and executed.
Read the guideCore Web Vitals and what we actually optimize
Core Web Vitals measure parts of the real user experience that are easy to damage with careless implementation.
Read the guideWhy page-builder sites often get heavy over time
Why page-builder sites often accumulate runtime weight through generic layout systems, plugins, animations, and third-party dependencies over time.
Read the guide14 guides
All Performance documentation
Why our sites tend to perform well: server-first rendering, narrow JavaScript boundaries, controlled media, restrained third parties, and less unnecessary runtime work.
Core Web Vitals measure parts of the real user experience that are easy to damage with careless implementation.
JavaScript is powerful, but it is also one of the most expensive resources a browser can receive. It has to be downloaded, parsed, compiled, and executed.
Images often account for the largest share of transferred bytes on a marketing site, so image handling deserves its own standard.
Typography is part of the brand, but fonts can easily become a render-blocking dependency.
How analytics, advertising tags, chat tools, schedulers, and embeds affect the same network and browser budget as the code we write ourselves.
Why page-builder sites often accumulate runtime weight through generic layout systems, plugins, animations, and third-party dependencies over time.
A high Lighthouse score is useful evidence, but the real goal is a site that renders quickly, stays stable, works across devices, and does not hide real problems behind a single number.
A practical look at the critical rendering path: which fonts, images, scripts, and interface behaviors deserve early bandwidth and which ones should wait.
The first large image often controls how fast a page feels, so hero media gets different loading, sizing, and compression decisions from ordinary below-the-fold imagery.
Most business websites need subtle movement, not a runtime animation system controlling the entire page, so we prefer CSS and browser-native behavior unless a feature genuinely needs more.
Why we prefer browser and CSS capabilities for ordinary motion and interaction, and reserve animation libraries for behavior that actually needs them.
Why full-screen mobile layouts need modern viewport units, header offsets, minimum heights, and real device testing instead of a single 100vh rule.
Why JavaScript costs more than download size on mobile devices, and how parsing, execution, hydration, third-party code, and long tasks affect responsiveness.
From explanation to proof
Where this connects to the work
The performance library explains why our technical scores tend to be unusually strong without treating the score itself as the product.