Server-render, because half your readers do not run JavaScript
This used to be an SEO nicety. It is now a distribution question. GPTBot, ClaudeBot, PerplexityBot and CCBot largely do not execute JavaScript, so a client-rendered application ships them an empty shell — invisible to every major AI assistant regardless of how good the content is.
We build server-rendered by default and treat "is the content in the raw HTML response?" as a release check, not an assumption. It is one of the few technical decisions with a direct, measurable effect on whether an AI system can cite you at all.
Accessibility is a procurement requirement
For government and enterprise buyers, WCAG conformance is frequently a hard procurement gate rather than a preference. Retrofitting it is substantially more expensive than building to it — semantic structure, keyboard operability, focus management and contrast are architectural properties of a component library, not a CSS pass at the end.
It also correlates closely with the semantic HTML quality that determines how well search engines and LLMs chunk and understand a page, so the work pays twice.
Performance where users actually are
Core Web Vitals are measured on real devices on real networks. A platform tuned on a fast connection and a modern laptop will disappoint a user on a mid-range Android phone on a congested mobile network — which, for most of the markets our clients serve, is the median user rather than the edge case.
The work is mostly unglamorous: bounded image dimensions to prevent layout shift, self-hosted critical assets rather than third-party requests on the critical path, deferred non-essential JavaScript, and a real budget on the largest contentful paint.
Core Web Vitals are a measurement problem before they are a code problem
Most teams optimise against a lab score produced on a fast machine over a fast connection, then find the field data disagrees. The two measure different things: the lab number is a synthetic run, while ranking-relevant data comes from real users on real devices and networks.
We instrument field measurement first, because it is the only thing that tells you which of the three metrics is actually failing and for whom. Largest Contentful Paint problems are usually an image or font loading decision. Interaction to Next Paint problems are usually long tasks blocking the main thread, frequently from third-party scripts nobody has audited. Cumulative Layout Shift is nearly always unreserved space for an image, an ad slot, or a late-loading font.
Fixing the wrong one is common and expensive. The diagnosis is cheap by comparison.
Third-party scripts are the usual cause of poor performance
A site that scores well on its own code can still be slow because of tag managers, chat widgets, analytics and marketing pixels — each adding a DNS lookup, a TLS handshake and main-thread work, and each typically added by someone outside engineering with no performance review.
The practical discipline is a budget: every third-party script has a named owner and a stated business justification, and anything failing both is removed. Where a script has to stay, it is loaded so that it cannot block first paint, and self-hosted where licensing permits so the request stays same-origin.
This also has a privacy dimension that matters in regulated sectors. Every third-party request discloses your visitor's IP address and user agent to that provider, which is a disclosure your privacy policy has to be able to describe accurately.
Rendering strategy chosen per route, not per project
The choice between static generation, server rendering and client rendering is usually made once for a whole application and then defended everywhere, which produces a site that is either needlessly dynamic or awkwardly stale.
Content that changes rarely should be static and served from the edge. Content personalised per request has to be server-rendered. An interactive tool where only the user sees the result can be client-rendered without cost to search visibility. Deciding this per route is more thought up front and materially better on every axis afterwards.
What is included
- Server-rendered web applications (Next.js, .NET, Java)
- Customer portals and self-service platforms
- Admin consoles and internal tooling
- Design system and component library development
- WCAG 2.2 accessibility engineering and audit
- Core Web Vitals optimisation
- Technical SEO and structured data implementation
- Progressive web applications
- API design and documentation
Technologies and standards
Related case studies
- National Identity Verification Portal with NADRA Integration — Citizen identity verification against NADRA APIs with biometric authentication and PKI signing, built server-rendered and to accessibility requirements.
- Federal Tax Filing Portal Built on FBR API Integration — A filing portal designed around the only traffic pattern that matters in tax: everyone arriving in the final forty-eight hours.