- Inlined CSS
- Subsetted Fonts
- Static Rendering
- Edge Delivery
The Nitrosite Standard, examined from first principles.
This page is written for a technical reader: a managing partner with an engineering bent, or the person you trust with the firm's systems. The Nitrosite is not a faster template. It is a build pipeline that begins by asking what the absolute minimum is that a browser needs to render a perfect page, then ships only that.
Most of the industry layers frameworks on top of frameworks. We start from the question of what a browser actually requires and work upward. Performance, accessibility, and search readiness are not patched in afterward. They are structural properties of how the site is built and delivered. The proof points later in this report follow from the architecture, not from optimization passes.
Designed at Oxford. Made in America.
The techniques behind the Nitrosite Standard were developed through research at the University of Oxford, at the intersection of information architecture, network performance, and human-computer interaction. The starting point was a single question: what is the minimum a browser needs to render a perfect page?
Every technique below traces back to that question, and each was validated against real legal-industry workloads before it was codified. The result is an architecture that treats speed, accessibility, and search readiness as structural, not cosmetic.
- checkFirst-principles approach to web performance, not framework-on-framework defaults.
- checkValidated against real legal-industry workloads before codification.
- checkNetwork and rendering optimization treated as one continuous problem.
- checkA repeatable standard, applied identically to every page on every site.
The architecture, layer by layer.
Each layer removes a class of overhead that slows, breaks, or hides a page. Read in sequence, they explain the proof points without a single optimization pass after the fact.
Per-page inlined CSS, zero stylesheets
Most sites load one monolithic stylesheet carrying rules for every page, so visitors download tens of thousands of unused declarations on every request. We compile Tailwind per page: each HTML file is scanned on its own, only the classes it uses are extracted and tree-shaken, then minified and inlined directly into a style tag in the head. There is no external stylesheet to request and nothing render-blocking. The CSS is parse-ready on the first byte, roughly 22KB per page rather than 200KB or more.
- remove Render-blocking CSS request
- remove Unused rule download
- remove Second network round-trip
Self-hosted, subsetted fonts
Third-party font services add DNS lookups, TLS handshakes, and a separate origin to every page load. We self-host every font instead. Each file is subset to the Latin range, compressed as woff2, and served from the same origin with a content-hashed filename for immutable caching. A font-display swap rule keeps text visible during loading, so there is no flash of invisible text and no cross-origin connection on the critical path.
- add Same-origin delivery
- add Content-hashed filenames
- add No flash of invisible text
Critical resource preloading
Browsers normally discover font files late, only after parsing the CSS that references them. That creates a request chain (HTML, then CSS, then font) where each link adds latency. We place preload hints in the head so fonts enter the high-priority download queue before any CSS is parsed. The chain collapses into parallel downloads, and the fonts are ready before the first render completes.
Static-first architecture
JavaScript frameworks ship hundreds of kilobytes of runtime that must be downloaded, parsed, compiled, and executed before the page becomes interactive. That hydration cost is the single largest cause of poor mobile scores. A Nitrosite is pure HTML: no React, no hydration step, no framework runtime. The page is interactive the instant it renders, so Time to Interactive equals First Contentful Paint and Total Blocking Time is zero.
Edge deployment and caching
Every Nitrosite is published to object storage with a content delivery network in front of it, serving files from edge locations across 300 or more cities so the bytes start physically close to the visitor. Content-hashed assets (fonts, images, scripts) carry a one-year immutable cache directive; HTML carries a one-hour cache so edits propagate quickly. Returning visitors load almost the entire page from cache, and there is no origin server to slow down or fail.
- add Assets: one year, immutable
- add HTML: one hour
- add No single point of failure
Semantic HTML and accessibility
Accessibility is both a legal obligation and a ranking factor, and an automated audit tests dozens of criteria. Every page uses semantic HTML5 elements, correct ARIA attributes, skip-to-content links, a logical heading hierarchy, and color contrast that meets WCAG 2.1 AA. The language attribute, viewport meta, and logical tab order are guaranteed on every deployment rather than checked by hand.
- add WCAG 2.1 AA contrast
- add Skip links and tab order
- add Logical heading hierarchy
Structured data and on-page SEO
Every page ships with JSON-LD schema (Organization, BreadcrumbList, WebPage, and the relevant entity type) alongside canonical URLs, Open Graph and Twitter Card tags, an XML sitemap, and robots.txt. Together these give a crawler a complete, machine-readable picture of the site. This is on-page SEO as a structural property of the build; the ongoing program that ranks the site is covered separately on the SEO architecture page.
- add JSON-LD schema graph
- add Canonical and social tags
- add Sitemap and robots.txt
Progressive web app caching
Every Nitrosite registers a service worker that precaches its pages, fonts, and shared components on the first visit. After that the site works offline, and returning visitors get instant loads from the local cache. A web manifest makes the site installable on mobile devices, and a theme-color meta tag gives the browser chrome a polished, native feel.
- add HTML pages and components
- add Font files
- add Installable, offline-ready
Asset optimization
Every byte is audited. Vector graphics use SVG, raster images are crushed to their minimum size, and nothing unoptimized sits in the critical rendering path. The Material Symbols icon font is subset from megabytes down to only the icons the site actually uses, a single change that removes the overwhelming majority of its original weight. The result is a page that weighs a small fraction of a typical law firm site.
Compression at the edge
Every text-based asset (HTML, inline CSS, JavaScript, JSON, XML, and SVG) is served gzip-encoded, compressing the already-minimal content by a further two-thirds to four-fifths and cutting time on the wire. The content delivery network handles this automatically at the edge, so the origin never compresses on the fly. Fonts are already woff2, so they pass through without double-encoding overhead.
- add HTML, JS, JSON, XML, SVG
- add Handled at the edge
- add No double-encoding of fonts
The architecture is the output. The intellect decides what to build.
The pipeline above explains how a Nitrosite is fast, secure, and crawlable. It does not, on its own, decide what the site should say or which pages matter. That decision is made before any of these layers run.
Before we touch a line of markup, NitroCMS pulls and unifies real data from five sources (Google Analytics, Google Search Console, Google Ads, independent SEO and competitor intelligence, and Nexus, our first-party analytics), then hands the combined picture to our analysis engine, which produces a ranked list of recommendations. The architecture executes a plan that the evidence wrote. That is the end of guess-and-check marketing, and it is the difference from a template the industry builds first and reasons about later.
Read how the data engine works arrow_forwardNitrosite Standard against the typical build.
The figures below describe a Nitrosite against a representative WordPress or framework-based law firm site. The Nitrosite column is testable on any page of this site right now.
| Metric | WordPress or framework | Nitrosite |
|---|---|---|
| Performance score | 35 to 65 | 100 |
| Accessibility score | 60 to 80 | 100 |
| Best practices score | 70 to 85 | 100 |
| SEO score | 75 to 90 | 100 |
| Page weight (gzipped) | 3 to 8 MB | ~45 KB |
| Largest Contentful Paint | Several seconds | 0.4s |
| Total Blocking Time | 500 to 2000 ms | 0 ms |
| Cumulative Layout Shift | Variable | 0.00 |
Verify every claim on this page.
Nothing here requires our word. Open the browser tools and confirm the architecture for yourself, then run the same checks on your current site.
Run Lighthouse
Open the browser tools, choose Lighthouse, and audit this page. Then run it on your current site. The average law firm site scores 34.
View source
No external stylesheet, no framework bundle. Just clean HTML with per-page CSS inlined in the head, exactly as described above.
Check the network tab
Count the requests and the bytes. You will see a handful of resources and a total measured in kilobytes, not megabytes.
Look for an attack surface
There is no database, no server-side application, and no login endpoint. Static files served read-only leave nothing to breach.
Begin with a letter, not a lead form.
If you have read this far and want the same architecture working for your firm, write to us. Four questions. We reply within two business days, and you are welcome to bring your own engineer to the conversation.