Why a Next.js site is fast

Next.js sits at the top of the stack. When the project is built, it pre-renders as many pages as possible into finished HTML so the server can hand the browser a ready document—no template engine running on every request, no database call to assemble a layout that never changes.

For pages that do need fresh data (user dashboards, search results), Next.js supports server-side rendering and React Server Components so the data-fetching happens close to the database on the host, not inside the visitor's browser.

Automatic code-splitting means every page gets only the JavaScript it needs. A visitor reading the home page does not download the bundle for the contact form or the admin routes. Smaller payloads reach the browser faster, parse faster, and consume less memory on the device.

Turbopack (the dev-mode bundler used in this project) also makes the local development loop faster: changes in Cursor appear in the browser preview in milliseconds rather than seconds, so iteration is quicker.

React introduced a virtual DOM—a lightweight in-memory description of what the UI should look like. When something changes (a user clicks a button, new data arrives), React computes the minimal set of DOM updates needed and applies only those. The rest of the page stays untouched.

In practice this means navigating between pages, opening modals, and refreshing data-driven sections all feel instant because the browser is not tearing down and rebuilding the whole document from scratch.

React 19 (used here) also supports concurrent rendering: React can work on low-priority updates in the background and interrupt them if something more urgent arrives, keeping the interface responsive under load.

Server Components, a newer React feature baked into Next.js, let the server render component trees and stream HTML to the browser progressively. Critical content shows up early; optional UI fills in behind it.

Traditional CSS frameworks ship a large stylesheet and then expect developers to override the defaults. The visitor's browser downloads hundreds of kilobytes of rules, most of which never apply to the page being viewed.

Tailwind scans the project at build time, finds every class name in use, and generates a stylesheet containing only those classes. On a typical marketing site this results in a CSS file measured in tens of kilobytes, not hundreds. Smaller stylesheets parse faster and render faster.

Because styles are declared directly on elements in the markup, the browser's cascade resolver does not have to trace through layers of parent rules to determine which styles apply. What you see in the HTML is what the browser renders.

PostCSS and autoprefixer (part of this build) further process the output to add any vendor prefixes needed for older browsers, so the production file is clean and cross-browser without extra manual work.

Most of this site's public pages are static content that does not require a database at all. When dynamic data is needed—form submissions, user accounts, stored records—PostgreSQL (Postgres) is the preferred database for this stack.

Postgres has over 35 years of active development focused on reliability and query performance. Its query planner analyzes every SQL statement and chooses an efficient execution path. Proper indexes on frequently queried columns mean the database reads only the rows it needs, not the whole table.

Critically, the database is never called directly from the visitor's browser. Queries go through Next.js API routes or Server Components running on the host. This keeps credentials off the public internet and makes it possible to cache query results at the Vercel edge—so repeated requests for the same data do not always reach the database at all.

Connection pooling (commonly via PgBouncer or a managed provider like Supabase, Neon, or PlanetScale's Postgres offering) keeps the number of simultaneous database connections manageable under traffic, preventing the bottleneck that kills many WordPress-style sites under load.

Vercel runs a global content delivery network (CDN) with dozens of edge locations worldwide. Static assets—HTML, CSS, JavaScript, images—are copied to all of them on each deploy. A visitor in Tokyo is served from a data center near them, not from a server in Virginia.

For dynamic requests (server functions, API routes), Vercel also offers edge functions that run computation at the nearest location rather than routing every request back to a single origin. Latency drops proportionally with physical distance, which is a meaningful improvement for international visitors.

Vercel's infrastructure also handles HTTP/2 and HTTP/3 automatically, which allows multiple resources to be downloaded in parallel over a single connection. Browsers can request the HTML, CSS, JavaScript, and images for a page simultaneously rather than waiting for each one in sequence.

Automatic HTTPS is included: every domain and preview URL is served over TLS with no configuration needed, which browsers also use to prioritize connection speed.