Self-hosting with Node.js in NextJS - Performance & Optimization

Performance: Self-hosting with Node.js

MEDIUM IMPACT

This affects the server response time and initial page load speed by controlling how the Next.js app is served and assets are delivered.

Serving a Next.js app with Node.js for production

NextJS

import { createServer } from 'http';
import { parse } from 'url';
import next from 'next';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  createServer((req, res) => {
    const parsedUrl = parse(req.url, true);
    handle(req, res, parsedUrl);
  }).listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
});

Running Next.js in production mode enables server-side optimizations and smaller bundles, improving response time and LCP.

📈 Performance GainReduces server response time by 30-50%; smaller JS bundles speed up initial paint.

Serving a Next.js app with Node.js for production

NextJS

const express = require('express');
const next = require('next');

const app = next({ dev: true });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  const server = express();
  server.all('*', (req, res) => {
    return handle(req, res);
  });
  server.listen(3000, () => {
    console.log('> Ready on http://localhost:3000');
  });
});

Running Next.js in development mode disables optimizations and causes slower server response and larger bundles.

📉 Performance CostBlocks rendering for 200-500ms longer on initial load; larger JS bundles increase LCP.

Performance Comparison

Pattern	Server Response	Bundle Size	LCP Impact	Verdict
Dev mode self-hosting	Slow (200-500ms delay)	Large (unminified bundles)	High delay	[X] Bad
Prod mode self-hosting	Fast (50-100ms delay)	Small (minified bundles)	Low delay	[OK] Good

Rendering Pipeline

Self-hosting with Node.js affects the server response phase of the rendering pipeline, which impacts when the browser can start parsing and rendering content.

→Server Response

→Critical Rendering Path

→Resource Loading

⚠️ BottleneckServer Response time delays the start of browser rendering.

Core Web Vital Affected

LCP

This affects the server response time and initial page load speed by controlling how the Next.js app is served and assets are delivered.

Optimization Tips

1Always run Next.js in production mode for self-hosting to enable optimizations.

2Monitor server response time (TTFB) to ensure fast initial content delivery.

3Serve minified and cached assets to reduce bundle size and improve LCP.

Performance Quiz - 3 Questions

What is the main performance benefit of running Next.js in production mode when self-hosting with Node.js?

A Faster server response and smaller JS bundles

B More detailed error messages

C Automatic code splitting disabled

D Longer server startup time

DevTools: Network

How to check: Open DevTools, go to Network tab, reload the page, and check the Time to First Byte (TTFB) and size of JS bundles.

What to look for: Lower TTFB and smaller JS files indicate better self-hosting performance.

Practice

1. What does self-hosting a Next.js app with Node.js mean?

easy

A. Running Next.js only in the browser without Node.js

B. Using a third-party service to host your Next.js app

C. Building the app without a server

D. Running your Next.js app on your own server using Node.js

Solution

1. Step 1: Understand self-hosting concept

   Self-hosting means you run the app on your own server, not a third-party service.

2. Step 2: Connect self-hosting with Node.js

   Next.js apps use Node.js to serve the app on your server, giving you control.

3. Final Answer:

   Running your Next.js app on your own server using Node.js -> Option D

4. Quick Check:

   Self-hosting = Running on own server [OK]

Hint: Self-hosting means running on your own server [OK]

Common Mistakes:

• Confusing self-hosting with using cloud services
• Thinking Next.js runs only in the browser
• Believing no server is needed for Next.js

2. Which command correctly starts a Next.js app in production mode with Node.js?

easy

A. next start

B. node next

C. next dev

D. npm run build

Solution

1. Step 1: Identify production start command

   After building, next start runs the app in production mode with Node.js.

2. Step 2: Check other commands

   next dev is for development, npm run build builds but doesn't start, node next is invalid.

3. Final Answer:

   next start -> Option A

4. Quick Check:

   Production start = next start [OK]

Hint: Use 'next start' to run production server [OK]

Common Mistakes:

• Using 'next dev' for production
• Trying to run 'node next' directly
• Confusing build and start commands

3. Given this Node.js server code for Next.js, what will happen when you run it?

import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  http.createServer((req, res) => {
    handle(req, res);
  }).listen(3000, () => {
    console.log('Server running on http://localhost:3000');
  });
});

medium

A. Throws an error because 'next' cannot be imported this way

B. Starts a Next.js server on port 3000 serving production build

C. Starts a development server with hot reload

D. Server runs but does not handle Next.js requests

Solution

1. Step 1: Analyze server setup

   The code imports Next.js, sets dev to false (production), prepares app, then creates an HTTP server that uses Next.js request handler.

2. Step 2: Understand server behavior

   The server listens on port 3000 and serves the production Next.js app correctly.

3. Final Answer:

   Starts a Next.js server on port 3000 serving production build -> Option B

4. Quick Check:

   Node.js server with Next.js handler = production server [OK]

Hint: dev: false means production server starts [OK]

Common Mistakes:

• Thinking import syntax is invalid in Node.js
• Assuming dev: false means development mode
• Believing server does not handle Next.js requests

4. You wrote this code to self-host your Next.js app but get no confirmation message:

import next from 'next';
import http from 'http';

const app = next({ dev: true });
const handle = app.getRequestHandler();

app.prepare().then(() => {
  http.createServer((req, res) => {
    handle(req, res);
  }).listen(3000);
});

What is the likely cause of the issue?

medium

A. You must build the app before running with dev: true

B. Using dev: true disables the HTTP server

C. You forgot to add a callback to listen()

D. You cannot use 'http' module with Next.js

Solution

1. Step 1: Check listen() usage

   The listen method works without a callback, but missing callback means no confirmation message that the server started.

2. Step 2: Rule out other options

   dev: true enables development mode (no build needed), doesn't disable HTTP server, and http module is compatible with Next.js custom servers.

3. Step 3: Confirm the issue

   You forgot to add a callback to listen() identifies the missing callback, which prevents the confirmation log like 'Server running...' seen in working examples.

4. Final Answer:

   You forgot to add a callback to listen() -> Option C

5. Quick Check:

   Missing listen callback = no start confirmation [OK]

Hint: Add listen callback to confirm server start [OK]

Common Mistakes:

• Thinking dev: true disables server
• Believing http module is incompatible
• Assuming build is required for dev mode

5. You want to self-host a Next.js app with Node.js and add a custom API route that logs requests before handling them. Which code snippet correctly adds this feature?

hard

A. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
console.log(`Request URL: ${req.url}`);
handle(req, res);
}).listen(3000, () => {
console.log('Server running on http://localhost:3000');
});
});

B. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
handle(req, res);
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

C. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
res.writeHead(200);
res.end('Logged request');
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

D. import next from 'next';
import http from 'http';

const app = next({ dev: false });
const handle = app.getRequestHandler();

app.prepare().then(() => {
http.createServer((req, res) => {
console.log(`Request URL: ${req.url}`);
}).listen(3000);
});

Solution

1. Step 1: Identify correct request logging order

   Logging the request URL before calling handle(req, res) ensures the log happens before Next.js processes the request.

2. Step 2: Check response handling

   import next from 'next';
   import http from 'http';
   
   const app = next({ dev: false });
   const handle = app.getRequestHandler();
   
   app.prepare().then(() => {
     http.createServer((req, res) => {
       console.log(`Request URL: ${req.url}`);
       handle(req, res);
     }).listen(3000, () => {
       console.log('Server running on http://localhost:3000');
     });
   });

   calls handle after logging, letting Next.js handle the response properly. Other options either log after response or do not call handle.

3. Step 3: Confirm server start callback

   import next from 'next';
   import http from 'http';
   
   const app = next({ dev: false });
   const handle = app.getRequestHandler();
   
   app.prepare().then(() => {
     http.createServer((req, res) => {
       console.log(`Request URL: ${req.url}`);
       handle(req, res);
     }).listen(3000, () => {
       console.log('Server running on http://localhost:3000');
     });
   });

   includes a listen callback to confirm server is running, which is good practice.

4. Final Answer:

   Code snippet with console.log before handle(req, res) -> Option A

5. Quick Check:

   Log before handle() for correct request processing [OK]

Hint: Log requests before calling handle() to capture all requests [OK]

Common Mistakes:

• Logging after response ends, missing some requests
• Not calling handle(), breaking Next.js routing
• Omitting server start confirmation callback