Why our sites are unusually fast

Our sites tend to perform well because we try to remove unnecessary work before we optimize the work that remains. That is the central idea. Performance can be improved with compression, caching, image formats, bundle analysis, code splitting, and dozens of smaller techniques.

Those tools matter. They are much more effective when the site did not begin with an architecture that requires the browser to do far more work than the page needs.

We start with rendered content

Most of our public pages are documents. We render their important content on the server or generate it ahead of time. The browser receives the headline, body copy, links, structure, and metadata instead of receiving an empty shell that needs a client application to reconstruct the page.

That improves the first render and reduces the amount of client-side JavaScript required for basic comprehension. Our server-first architecture explains this in more depth.

Static generation removes repeated runtime work

Articles, documentation, service pages, location pages, and case studies often change much less frequently than they are viewed. If the content is known at build time, we can generate the final page once and serve it repeatedly. That is usually more efficient than querying a database and rebuilding the same document for every visitor.

We still use request-time rendering when a page genuinely needs current request-specific data. The point is not to force everything static. The point is not to pay runtime cost for static information.

Client-side JavaScript has to justify itself

JavaScript is one of the most expensive resources a browser receives because transfer size is only the beginning. The code also has to be parsed, compiled, executed, and sometimes hydrated against server-rendered markup. So we keep client boundaries narrow. A mobile menu can be interactive without making the entire page a client component.

A modal can manage state without forcing the service content into the browser bundle. A gallery can listen for keyboard input without making the portfolio route client-rendered. This is why our JavaScript budget is an architectural rule rather than an after-the-fact optimization.

Image handling is treated as engineering

Image-heavy sites can destroy performance even when the React code is excellent. We use modern formats, reasonable source dimensions, responsive image sizes, stable aspect ratios, and selective priority loading. One production image-heavy site explicitly configures AVIF and WebP generation, supported quality levels, device breakpoints, generated widths, and long optimized-image cache lifetimes.

Other repos use static image registries so important local images carry intrinsic dimensions through the build. The common idea is control. We do not want a 5000-pixel source file being sent to a phone because the page happened to display it at 420 pixels wide.

Fonts have loading priorities too

Several of our sites use next/font. That lets the framework integrate the font files into the build and reduces dependency on external font CSS. We can also make priority decisions. A primary interface font may be preloaded. A secondary decorative font may deliberately avoid preload.

The brand still gets the type system. The first render does not have to treat every font as equally urgent.

Third-party scripts are part of the performance budget

Analytics, advertising, chat tools, schedulers, form widgets, and embeds can add more runtime cost than our own application code. We do not pretend those scripts are external to performance simply because another company wrote them. The connectrader site itself defers analytics until user interaction or a later timeout so tracking code does not compete as aggressively with the first view.

Other projects have different business requirements, so the exact loading strategy varies. The rule is that third-party value should justify third-party cost.

We prefer browser-native behavior when it is enough

CSS handles a surprising amount of motion and interaction. Native HTML handles a surprising amount of semantics. The browser already knows how to scroll, focus a link, activate a button, lay out a grid, respect reduced motion, and respond to media queries.

Every time we can use those capabilities cleanly, we avoid shipping another layer of JavaScript. Read Why we reach for browser-native behavior before animation libraries.

Real devices influence the code

Performance is not a desktop Lighthouse screenshot. Mobile browsers have changing viewport chrome, lower CPU budgets, touch input, memory limits, and different compositing behavior. One of our responsive builds disables a reveal animation on touch-first devices because mobile viewport resizing made the effect less stable.

The content remains visible. The decorative motion gets removed. That is the kind of trade we will make every time.

Full-height sections need modern viewport handling

A large hero can look polished and still behave badly if it blindly uses 100vh on mobile. Some of our newer implementations combine traditional viewport fallbacks with svh, navigation offsets, and minimum heights so the section remains intentional while browser chrome changes.

That topic is covered in Why full-screen sections are harder than writing 100vh.

We audit the result, not only the source

Performance regressions can come from a new image, a script, a dependency, or a layout change. We use build checks, bundle analysis where useful, browser testing, and Lighthouse-style audits as tools to inspect the artifact. We do not optimize to a single number.

A page can have a strong synthetic score and still feel bad if interaction is delayed or mobile layout is unstable.

Why our advantage is structural

A heavy site can be optimized. A light site can also be optimized. The second job is easier. Our biggest performance advantage is that we often avoid the generic runtime layers, duplicated plugins, database calls, CMS requests, and browser-side rendering that many marketing sites inherit by default.

That gives us less work to optimize in the first place. The goal is not the score. The goal is a page that appears quickly, settles quickly, responds quickly, and keeps doing those things after the site has grown.