Rendering Configurations

1. compress

The compress configuration option in Next.js controls whether Gzip compression is applied to rendered pages and static assets when using 'next start' or a custom server.

By default, Next.js enables Gzip compression for all server responses to improve performance by reducing the size of HTML, JavaScript, CSS, and JSON payloads. This results in faster page loads, lower bandwidth usage, improved Core Web Vitals (especially LCP and FCP).

When compression is enabled (compress: true), Next.js will:

Automatically compress HTML and static assets (CSS, JS, JSON, etc.) using Gzip
Set the HTTP Content-Encoding: gzip header for responses
Respect the browser's Accept-Encoding header

If you're deploying your app with 'next start', compression is handled out-of-the-box by the internal server.

// next.config.js
// To disable compression in your app:
module.exports = {
  compress: false,
}

You should only disable Next.js's built-in compression if you are offloading compression to your server or CDN, such as:

NGINX with Brotli/Gzip
Cloudflare, AWS CloudFront, or other edge/CDN providers with built-in compression

brotli on;
brotli_types text/plain text/css application/json application/javascript text/xml application/xml application/xml+rss text/javascript;

To verify compression, use your browser's Developer Tools (Network tab) or curl to inspect headers:
From Browser: Accept-Encoding: Lists what the browser accepts (e.g. gzip, br) Content-Encoding: Shows what was applied by the server (e.g. gzip)From Terminal: curl -H "Accept-Encoding: gzip, br" -I https://yourdomain.com

⚠️ Best Practices

Using 'next start' only ❌ No - keep compression enabled
Using custom server with no compression ❌ No - keep compression enabled
Using NGINX or CDN for compression ✅ Yes - disable compression in Next.js
Using Brotli instead of Gzip ✅ Yes - let your server handle it

2. ppr

Partial Prerendering (PPR) enables you to combine static and dynamic components together in the same route. This can improve performance and developer experience by allowing hybrid rendering.

In Next.js 15, you can incrementally adopt Partial Prerendering by setting ppr to 'incremental' in next.config.js and using the experimental_ppr route export:

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    ppr: 'incremental',
  },
}

export default nextConfig

Then in a route file like app/page.tsx:

import { Suspense } from "react"
import { StaticComponent, DynamicComponent, Fallback } from "@/app/ui"

export const experimental_ppr = true

export default function Page() {
  return (
    <>
      <StaticComponent />
      <Suspense fallback=<Fallback />>
        <DynamicComponent />
      </Suspense>
    </>
  );
}

Good to know:

Routes without experimental_ppr will not use PPR by default.
Once enabled at a segment, it applies to all nested layouts and pages.
To opt out in child segments, explicitly set experimental_ppr = false.

Example: For a marketing page that loads static banners and a dynamic pricing widget, PPR ensures banners load immediately while the pricing widget fetches in parallel without blocking render.

3. serverActions

Server Actions in Next.js provide a convenient way to mutate data securely on the server. These can be configured for tighter security and resource limits.

To allow certain domains to call Server Actions (useful for proxies):

// next.config.js
module.exports = {
  experimental: {
    serverActions: {
      allowedOrigins: ['my-proxy.com', '*.my-proxy.com'],
    },
  },
}

This ensures requests from these origins are allowed to access actions, preventing CSRF attacks by default.

To limit request body size:

// next.config.js
module.exports = {
  experimental: {
    serverActions: {
      bodySizeLimit: '2mb',
    },
  },
}

By default, the size limit is 1MB. This prevents abuse via large payloads. Common values: '500kb', '2mb', etc.

To enable Server Actions in versions before Next.js 14:

// next.config.js
module.exports = {
  experimental: {
    serverActions: true,
  },
}

Example: For a form that uploads profile photos or bio updates, you may want to increase bodySizeLimit and allow trusted proxy servers to access actions securely.

4. staticGeneration

The staticGeneration options help fine-tune how Static Generation is performed for performance and reliability at scale.

// next.config.ts
import type { NextConfig } from 'next'

const nextConfig: NextConfig = {
  experimental: {
    staticGenerationRetryCount: 1,
    staticGenerationMaxConcurrency: 8,
    staticGenerationMinPagesPerWorker: 25,
  },
}

export default nextConfig

staticGenerationRetryCount: Number of times a failed static generation is retried.
staticGenerationMaxConcurrency: Max pages handled per worker thread.
staticGenerationMinPagesPerWorker: Minimum number of pages to bundle before spawning a new worker.

Example: A large news website with thousands of static articles can benefit from tuning these settings to reduce build time and improve reliability by retrying failed generations due to API rate limits.

5. webVitalsAttribution

Enabling webVitalsAttribution provides additional insight into what contributes to Web Vitals such as LCP, FID, and CLS.

// next.config.js
module.exports = {
  experimental: {
    webVitalsAttribution: ['CLS', 'LCP'],
  },
}

When enabled, you can access attribution data in custom reportWebVitals implementations to understand:

Which elements caused Largest Contentful Paint (LCP)
What inputs caused long First Input Delay (FID)
What layout shifts contributed to Cumulative Layout Shift (CLS)

Example: If your page has a slow image causing LCP, enabling attribution will show which image is responsible. You can then apply optimizations like priority loading or use next/image with better sizing.

MENU