Nuxt 4 Architecture for a Tool Site

SonicToolLab uses Nuxt 4 for server rendering, file-based routing, server APIs, and a shared Vue component architecture. This article focuses on the Nuxt 4 changes we can verify in this repository rather than making universal performance claims.

1. The New Directory Structure

One of the first things you'll notice in Nuxt 4 is the refined folder structure. The move towards an app/ directory (which is where our pages/, components/, and assets/ now live) parallels modern trends in frameworks like Next.js, providing a cleaner separation between logic and configuration.

• Separated contexts: UI code lives under app/, while server/, public/, configuration, and shared infrastructure remain at the project root.
• Auto-imports: Components and composables follow Nuxt conventions, reducing repeated imports while preserving separate client and server contexts.

2. Performance & The Core Engine

Nuxt 4 reorganizes data fetching, module ordering, TypeScript project contexts, and application directories. Actual loading performance still depends on page code, third-party libraries, caching, and deployment configuration.

• Route splitting: Tool pages are separate routes, allowing browser-only libraries to be loaded where they are needed.
• Context-specific types: Nuxt generates separate app, server, shared, and build-time TypeScript configurations.

3. Nitro Server Integration

Nuxt uses Nitro as its server engine and produces a deployable .output directory. In this project, Nitro discovers handlers under server/api/ and middleware under server/middleware/. Longer AI jobs use explicit queue and webhook handlers; this repository does not currently use Nitro's Task API.

4. Prerendering for Search, APIs for Runtime Work

Public articles and reviewed tool pages are prerendered so generated HTML already contains titles, descriptions, canonical links, language alternates, guidance, and the correct advertising decision. Nitro still emits runtime handlers for server/api/ on Cloudflare Pages. This makes a page readable before hydration while IP lookup, billing, and AI requests remain server controlled.

Search readiness is verified against output, not inferred from Vue source. The build checks HTML, robots.txt, response headers, sitemap membership, redirects, real 404 output, and per-route ad eligibility. Production health checks repeat the important assertions after release.

5. Isolating Browser-Heavy Tools

Canvas, file APIs, Web Workers, PDF rendering, OCR models, and downloads require browser-only boundaries, while their explanatory text can remain server rendered. The OCR tool, for example, can describe formats and privacy limits in initial HTML, then initialize recognition after a file is selected.

6. What Nuxt 4 Solves—and What It Does Not

Nuxt 4 gives this project clear app/server boundaries, route-based output, and a deployable Nitro target. It does not automatically make content useful, protect an API, produce correct redirects, or keep browser libraries small. Those outcomes come from explicit route policy, input validation, build assertions, and production checks.