Updated October 9, 2026.
When someone opens your website, their browser requests content, downloads the resources it needs, and turns them into a page. Understanding that process helps you ask better questions about editing, performance, hosting, and maintenance.
This guide explains the moving parts. It is a foundation for discussing a project with a developer, rather than a tutorial for building an entire site.
From a web address to a page
The browser is the client. It requests a page from a server, which may send an existing file or generate a response. DNS helps resolve the domain name to the address needed to connect. HTTP defines the request and response; HTTPS protects that exchange in transit.
Once the response arrives, the browser processes the HTML and retrieves resources such as stylesheets, images, and scripts. Some resources can come from a cache instead of being downloaded again. This is a simplified sequence: browsers overlap work, and later requests may reuse connections. MDN explains the client, server, DNS, and HTTP relationship.
For a business owner, domain registration, DNS, and hosting are related responsibilities. Keep track of who controls each account and who will renew it. When connecting a domain, follow the host’s specific instructions; there is no single DNS record or fixed waiting period that fits every setup.
HTML, CSS, and JavaScript
HTML describes the content and structure. Headings, paragraphs, links, images, and form controls give the page meaning.
CSS controls presentation. It defines layout, spacing, type, colors, and how the page adapts to different screens.
JavaScript adds programmable behavior. It can update a price calculator, fetch data, or operate an interactive map. A useful website does not need JavaScript for every feature: ordinary links and basic form submission can work through HTML.
The three commonly work together, but a page can be useful without all three. Avoid judging a proposal by how much JavaScript it includes. Ask whether the site’s content and interactions work for the people who need them.
When is the page generated?
“Static,” “server-rendered,” and “client-rendered” describe different parts of delivery. They are not a ranking from basic to advanced.
| Approach | What happens | A useful question |
|---|---|---|
| Build-time generation | HTML is prepared when the site is built and served later | What triggers publication after an edit? |
| Request-time rendering | A server generates a response when a request arrives, unless a suitable cached response is used | Which content needs fresh or personalized data? |
| Client-side rendering | JavaScript creates or updates content in the browser | What can a visitor see and use while the script loads? |
One site can combine these approaches. Astro, for example, pre-renders routes by default and supports server rendering for routes that need it. A pre-rendered service page and a personalized account page can therefore have different delivery requirements. Astro’s rendering documentation explains this distinction.
React is not synonymous with client-only rendering. Its server APIs can produce HTML on the server. The framework name alone does not tell you when a page is generated, how much JavaScript visitors receive, or how quickly it works.
Static delivery does not mean uneditable content
A site can store content in a content management system (CMS), generate pages after an editor publishes a change, and deliver those pages as files. It can also call services for forms, bookings, or other features. Discuss the complete workflow, including build time and who maintains integrations.
Request-time rendering is useful when responses depend on current data or a signed-in user. It brings responsibilities for the application and its data. Static delivery can reduce request-time processing, but accounts, dependencies, deployment access, and connected services still need care.
We recommend starting with requirements: who edits, how quickly changes must appear, what data is private, and which interactions customers need. Those questions are more useful than choosing a platform solely because it is described as “static” or “dynamic.”
What caching changes
A cache stores a response for reuse. A browser cache serves that browser; a shared cache can serve multiple visitors. Reusing suitable responses can reduce repeated downloads or server work, but freshness rules determine when a saved copy can be reused or must be checked.
Personalized content needs particular care: a shared cache must not serve one customer’s private response to another. MDN’s HTTP caching guide explains private and shared caches and the response controls used to distinguish them.
Consider a public project page. A cached copy may answer a later visit without regenerating the page. After an edit, the publishing process needs a way to replace or refresh that copy. A new visitor does not automatically have the previous visitor’s images in their own browser cache.
Ask your developer how updates become visible and how signed-in or private pages are handled. “We use caching” is incomplete without those answers.
How to talk about speed
There is no universal 200-millisecond page-load target. Loading, responsiveness, and visual stability are different measurements. Google’s Core Web Vitals use these good-experience thresholds:
- Largest Contentful Paint (LCP): 2.5 seconds or less.
- Interaction to Next Paint (INP): 200 milliseconds or less.
- Cumulative Layout Shift (CLS): 0.1 or less.
Assess these at the 75th percentile of visits, separating mobile and desktop. They are not a promise that every visit will finish loading within those limits. Google’s Web Vitals guidance defines the metrics and thresholds.
For a proposal, ask what will be tested, under which conditions, and how large images or outside services will affect the result. A framework label does not replace measurement.
What frameworks and a CMS do
A framework supplies conventions and reusable tools for development. A CMS gives editors a way to manage content. They can work together, and neither automatically guarantees an accessible, secure, or fast website.
WordPress is one CMS option; React is a user-interface library; Astro is a web framework. Comparing their names as if they were interchangeable products hides decisions about hosting, editing, integrations, and ownership.
When reviewing a website development proposal, ask how these choices support your editing and maintenance needs. Existing WordPress users can use the same questions when discussing their sites with their provider.
Questions to bring to a website project
- Which pages can be prepared in advance, and which need live data?
- Who can edit content, and what happens after they click publish?
- Who owns the domain, hosting, source files, and third-party accounts?
- What happens if a form, booking system, or other integration fails?
- How will performance, accessibility, and key interactions be checked?
- What maintenance and ongoing costs are included?
Write down those answers before comparing proposals. They make the technology choices easier to connect to the work your business actually needs.