A best-practice list is usually a set of suggestions with no enforcement behind it. A standard is different: it has a number attached, and a project either meets it or it doesn’t. Here’s the list we check before something ships, with the reasoning behind each item.
Speed
We hold pages to Core Web Vitals: LCP under 2.5 seconds (how long the biggest visible element takes to appear), INP under 200 milliseconds (how fast the page responds after a tap or click), CLS close to zero (how much the layout shifts while loading). Measured on a mid-range phone on a regular connection.
- Images. Full-resolution photos are the most common cause of a slow page. We convert to AVIF or WebP, which cut file size substantially with no visible quality loss, and set explicit width and height on every image so the browser reserves the space before it loads.
- Code. On a page meant to be read, like a landing page or blog post, we hold to under 100KB of compressed JavaScript. JavaScript is the one asset type a browser has to both download and execute, which is what makes a page feel laggy on interaction. Content pages often ship close to none.
- Fonts. Two font styles maximum, self-hosted rather than pulled from a third-party service, since an external font host adds its own request and its own point of failure.
- Third-party scripts. Analytics, chat widgets, tag managers, and ad pixels accumulate over time because each gets added by a different person for a different reason. Every script needs someone who can state its load-time cost and the business question it answers. If nobody can, it comes out.
These numbers get agreed on before development starts.
Reliability
- We default to pages that arrive already built, generated ahead of time or assembled server-side, rather than assembled in the visitor’s browser after the page loads.
- WordPress sites accumulate plugins over time. Each one is a maintenance obligation and a potential vulnerability. Part of any handover is subtraction: which of these does the site still actually need.
- Deploys need to be reversible in one step. If undoing a bad change means restoring a backup, that’s a delay before the real fix, not a rollback.
Accessibility
The European Accessibility Act has applied real legal weight to sites serving EU customers since June 2025. We build to WCAG 2.2 AA, the standard most regulations reference.
- Buttons and links are marked up as buttons and links in the underlying code, not just styled to look like them, so a screen reader can identify them correctly.
- The whole site is operable by keyboard alone, no mouse. This test catches more real barriers than automated scanners do.
- Text contrast meets a specific, testable ratio, and error messages state what went wrong and how to fix it.
Overlay widgets that promise instant compliance don’t fix the underlying markup, and they’ve become a pattern regulators specifically flag now.
Security
Everything served over HTTPS, secrets kept outside the codebase rather than in plain code, every form validated server-side (client-side validation can be bypassed, so it’s a courtesy, not a safeguard), and each integration scoped to only the access it needs. None of this requires a dedicated specialist, just a habit built into the project from the start.
Being findable by search engines and by AI
A growing share of purchase research now happens inside an AI assistant rather than a search engine, and most of the crawlers behind these assistants don’t execute JavaScript. A page assembled client-side can be entirely blank to them.
- Rendering. Pages that arrive already built, generated ahead of time or assembled server-side, are readable by both search engines and AI crawlers. A page assembled only in the browser is invisible to the crawlers that can’t execute JavaScript, this is a second reason for it, beyond speed.
- Structure. Real headings in order, one clear topic per page, and structured data (schema markup, a standardized way of labeling facts like a price or date so a machine can read them directly) let both a search engine and an AI assistant extract facts correctly.
- URLs. A changed address needs a permanent redirect, tracked as an engineering artifact rather than left to a plugin default. Careless URL handling during a rebuild is a common way a site loses years of earned search ranking in one afternoon.
Maintainability
- Reusable components instead of one-off page templates, so a brand update is one edit instead of a pass through every page.
- Content modeled as fields the client’s own team can edit, rather than frozen into a layout only a developer can touch. If a marketing person can’t publish a page or fix a typo without a ticket, that’s a gap in how the site was built.
- Decisions recorded briefly at the time they’re made: why this platform, why this number. Cheap to write while it’s fresh, expensive to reconstruct later.
The honest part
What separates a team that holds these standards from one that just knows about them is enforcement: numbers checked automatically on every change, not agreed on once and never revisited. If you’re evaluating a dev partner, including us, ask for the specifics: the actual performance number on their last few sites, the redirect plan, the accessibility check behind the claim.