Performance budgets are most useful when they are specific to what the page is trying to do. A service landing page that receives paid traffic and needs to convert visitors within seconds has different performance requirements from a blog article that serves as discovery content. Treating them the same — either with a single site-wide budget that is too strict for content pages or too lenient for conversion pages — produces suboptimal outcomes in both directions.
Route-level budgets solve this by setting performance thresholds that reflect the commercial purpose of each page category.
Why route type determines the right budget
Different page types have different relationships to revenue:
Service and conversion pages are where visitors arrive with purchase or contact intent — often from paid ads. Every 100ms improvement in LCP on a service page has a measurable effect on conversion rate. These pages should receive the strictest performance budget.
Blog and content pages serve awareness and discovery purposes. Visitors often arrive from organic search with informational intent. They are less likely to convert immediately, and the primary performance metric that matters is how quickly the text content is readable — not necessarily the overall page load.
Case study and portfolio pages sit between service and blog — they build trust and are often visited before a buying decision. They should be polished and fast, but the expectations are slightly relaxed compared to a paid landing page.
Utility pages (privacy policy, terms, FAQ) carry almost no conversion weight and can tolerate higher load times without meaningful business impact.
Route-level budgets for Next.js marketing sites
Service and conversion pages
- LCP: under 1.8 seconds on mobile (Google's Good threshold is 2.5s — aim for 30% below it)
- CLS: under 0.05 (stricter than Google's 0.1 threshold because layout shift on a service page erodes trust)
- INP: under 150ms (contact forms, booking buttons, and quote tools must be immediately responsive)
- Total page weight: under 1.2MB
- JavaScript (compressed): under 150KB excluding Next.js framework
These are production targets, not lighthouse-only targets. Measure with the Chrome User Experience Report field data for pages that have sufficient traffic volume.
Blog and content pages
- LCP: under 2.5 seconds on mobile (Google's Good threshold)
- CLS: under 0.1
- INP: under 200ms
- Total page weight: under 1.5MB
- JavaScript (compressed): under 200KB excluding framework
The primary performance goal for blog pages is that the text content is readable quickly — the LCP element is often a header image or hero, so optimising that image for fast load delivers most of the benefit.
Case study and portfolio pages
- LCP: under 2.5 seconds on mobile
- CLS: under 0.1 (case study pages often include before/after images that can shift layout — explicit dimensions on all images are mandatory)
- INP: under 200ms
- Total page weight: under 2MB (case studies with detailed visual documentation may require slightly more)
Utility and information pages
- LCP: under 3 seconds
- CLS: under 0.1
- Total page weight: no strict budget (these pages rarely contain heavy media)
Applying the budget in Next.js
In a Next.js App Router project, the route structure maps naturally to a budget framework. Components and layouts are scoped per route segment, which makes it practical to enforce different budgets per route type.
Image handling: use next/image with explicit width and height on all images. For service page hero images, use priority to preload the LCP image. For blog page images, use loading="lazy" on all below-fold images.
Script management: use Next.js <Script> with strategy="afterInteractive" for third-party scripts on service pages. Defer analytics, chat widgets, and ad scripts until after the page is interactive. This strategy has the most impact on INP for pages with complex JS.
Font loading: use next/font to preload fonts without render-blocking behaviour. Limit font families to one or two and preload only the weights in active use.
Route-specific component audits: conduct a component-level audit for service pages specifically. Identify components that include heavy dependencies (charting libraries, rich text editors, date pickers) and verify they are not bundled into the service page routes where they are not needed.
Monitoring against the budget
Define the monitoring strategy alongside the budget:
- Lighthouse CI in the build pipeline: blocks deployments that would degrade a service page below the service-page budget threshold
- Google Search Console Core Web Vitals report: weekly review of field data grouped by URL prefix to identify route-level regressions
- Real User Monitoring (RUM): for high-traffic service pages, consider dedicated RUM instrumentation to track field data beyond what the CrUX report captures
"Once the route budget was in writing, the team stopped adding heavy homepage modules and kept the service pages fast."