Next.js development, proven on our own website

Next.js earns its place when pages have to be good before anyone signs in. It renders React on the server, so search engines and link previews see complete HTML, the first paint does not wait for a JavaScript bundle, and each route can choose its own strategy: built once at deploy, regenerated when content changes, or rendered on every request when it depends on who is asking.

It is not the answer to everything. An internal dashboard or a back-office tool used only by signed-in staff gains little from server rendering, and a React application on a Vite build is simpler to run. A site that is almost entirely static content with little interactivity can be lighter still on a static-site generator. And a portal already running on Liferay DXP may be better served by React inside the portal than by a new front end beside it.

The decision comes down to who the first visitor is, where the content lives and who maintains the code afterwards — and we write the recommendation down with its reasons before the build starts.

• Public sites that depend on search, shared links or paid traffic
• A headless CMS or ERP that should keep owning the content
• Products with public pages and a signed-in area in one codebase
• Teams that want React skills to carry over to the server

atsglobal.in runs on Next.js 16 with the App Router, React 19, TypeScript and Tailwind CSS. Pages are server components; client-side code is limited to the parts that are actually interactive, such as menus, carousels and the chat assistant.

Content does not live in the codebase. The blog and every case study are authored in Frappe — the same platform that runs our own HR and accounts — and read over its REST API. Each fetch is cached under a tag for an hour; when an editor saves a post or a case study, a Frappe webhook calls a secret-protected revalidation endpoint, the tag is purged, and the listing, the detail page, the sitemap, the RSS feed and the related-content strips on service pages all re-render on their next request. If Frappe is unreachable, the case studies fall back to a committed copy of the content instead of failing.

It is deployed as a standalone Node.js server in a Docker image — a multi-stage build on Node 22, running as a non-root user — on a VPS behind nginx with HTTP/2. There is no platform lock-in: the same image would run on AWS, Azure or any container host.

• Next.js 16 App Router, React 19 server components, TypeScript, Tailwind CSS
• Frappe as the CMS for the blog and case studies, read over REST
• Tag-based caching, purged by a signed Frappe webhook on publish
• A committed case-study seed as the fallback for builds and outages
• Standalone Docker image behind nginx with HTTP/2 on our own server

At launch, Lighthouse's mobile test scored our home page 58, with a simulated Largest Contentful Paint of 9.4 seconds. The page was not slow for real visitors, but the simulation charged every byte requested before first paint to the hero text — and the same pattern holds back real users on slow connections.

Four changes took it to 94 and the LCP to 2.8 seconds, with desktop at 100: HTTP/2 on the server; web fonts subset to the characters the site actually uses, cutting them from about 460 KB to 130 KB; analytics loaded when the browser is idle instead of in the document head, with page views still recorded; and carousel images given real sizes and no longer preloaded. None of it required a redesign. We run the same audit on client sites, and set budgets in CI so the score does not quietly drift back.

Every page on this site gets its canonical URL, title and description from Next.js's metadata API, and its structured data — Service, FAQPage and BreadcrumbList on service pages, Article on blog posts — from the same data that renders the visible page, so the two cannot disagree. The sitemap, the RSS feed and the Open Graph image for each blog post are generated from the content in Frappe, and new or changed URLs are submitted to search engines through IndexNow.

After we replaced the previous site, the 24 old URLs that Google still had indexed were redirected with permanent 301s to their closest new page, and case studies we retired were redirected rather than left to return 404s. The redirect list lives in the Next.js config, versioned with the code.

Organisations on Liferay DXP often want a public site that is faster and easier to evolve than the portal, without moving content, workflow and permissions out of Liferay. In a headless setup, Liferay keeps authoring, approval workflow, translation and personalisation rules, and Next.js renders the public pages from its headless delivery APIs or GraphQL — statically where content is stable, on demand where it changes, with Liferay's publish events triggering revalidation the same way Frappe does on our site.

We have built the Liferay side of this for clients: for CIGNEX Datamatics, an API-first Liferay content platform delivering to three new digital channels in 12 language variants, with automated workflows that cut publishing time by 65 %. How the APIs, authentication and caching are designed is covered on our Liferay headless integration page.

ERPNext and Frappe ship with a built-in website and portal, which is enough for many internal and partner-facing needs. When the website has to rank, carry a brand, or combine ERP data with marketing content, a Next.js front end on Frappe's REST API is the pattern we use ourselves: product and service catalogues, customer portals showing orders and invoices, enquiry and registration forms that create records in the ERP, and content authored in the Frappe desk.

The rules are the ones our own site follows. API keys stay on the server and are never sent to the browser; customers sign in against Frappe's users and permissions rather than a second user store; reads are cached and purged by webhook; and writes go through whitelisted methods with server-side validation, so the ERP remains the single source of truth. The Frappe apps and doctypes behind such a front end are built by our custom Frappe app team.

Vercel is the easiest place to run Next.js and a sensible default for many teams. When data residency, cost at scale or an existing estate argues otherwise, Next.js runs as a standalone Node server in a container — as this site does — on AWS, Azure, Google Cloud or your own servers, behind nginx or a CDN. We set up the pipeline either way, with preview deployments for content and code changes.

Older Next.js sites on the Pages Router keep working, and both routers can live in one application, so we move them to the App Router route by route rather than in a single rewrite. Projects start with a short, fixed-fee discovery — pages and templates, content sources, rendering strategy per route, integrations, languages, and the URLs and rankings that must survive — and end in an architecture and a fixed price for the first release.