Vault 📚

02_static_dynamic_content

7 min read

Static and Dynamic Content

Web servers deliver two main types of content: static and dynamic. Static content usually consists of files (HTML, CSS, images, JavaScript) that rarely change and can be served directly from the file system or a cache. Dynamic content is generated on the fly by server-side logic (such as PHP, Node.js, or Python) or by client-side scripts interacting with APIs. Understanding these distinctions helps optimize performance, caching strategies, and user experience.

Static Content

Static content is pre-generated and served “as is” from the server without needing to run additional processing or database queries. Since the files do not change often, the server can simply read them from disk (or memory cache) and send them to clients.

Examples of Static Content

  1. HTML Files: Basic web pages with fixed layout and text.
  2. Images and Videos: Media assets such as JPEG, PNG, MP4.
  3. CSS Stylesheets: Styling instructions for webpages.
  4. JavaScript Files: Client-side scripts that do not change (though they might produce dynamic behavior in the browser).

How Static Serving Works

A simplified ASCII diagram illustrates the process of delivering static resources:

Client (Browser)          Web Server (Static)
      |                         |
      | 1. HTTP GET /image.png  |
      |------------------------->|
      |                         |
      |    2. Lookup file on disk 
      |       or in memory cache
      |                         |
      | 3. Serve file as response
      |<-------------------------|
      |                         |
      |   (Browser displays image)

Pros of Static Content

  1. High Performance: No server-side processing beyond file I/O, so requests are usually fast.
  2. Cache Friendly: Files can be cached by CDNs, browsers, and proxies, reducing repeated fetches.
  3. Scalable: Serving static files can handle massive traffic with minimal overhead when combined with caching or CDNs.
  4. Security: Static files do not directly expose server-side code or database connections.

Cons of Static Content

  1. Lacks Real-Time Updates: Requires manual or automated build steps to modify content.
  2. Limited Personalization: Cannot easily tailor content based on user inputs or database queries.

Simple Example with Nginx

Here is a minimal Nginx configuration snippet to serve static files from /var/www/html:

server {
    listen 80;
    server_name example.com;
 
    root /var/www/html;
    index index.html;
 
    location / {
        try_files $uri $uri/ =404;
    }
}

Explanation:

  • The server listens on port 80 for HTTP requests.
  • Files in /var/www/html are served directly.
  • If a file isn’t found, a 404 error is returned.

Dynamic Content

Dynamic content is generated at request time. Server-side scripts or programs build responses by interacting with databases, performing logic, and customizing output per user or context. Alternatively, content can also be dynamically rendered on the client side using JavaScript that calls backend APIs.

Server-Side Dynamic Content

This approach involves frameworks like Express (Node.js), Django (Python), Ruby on Rails, PHP, or Java-based applications. A typical request flow might look like:

Client (Browser)        Application Server
      |                         |
      | 1. HTTP GET /profile    |
      |------------------------->|
      |                         |
      |   2. Run server-side code:
      |      - Validate session
      |      - Query database for user data
      |      - Render template with user info
      |                         |
      | 3. Return generated HTML
      |<-------------------------|
      |                         |
      |  (Browser displays personalized page)

The server might fetch user data from a database, apply business rules, then generate an HTML page on the fly.

Client-Side Dynamic Content

In this scenario, the server often delivers a mostly static HTML/JavaScript app. Once loaded, client-side JavaScript calls an API (e.g., a REST or GraphQL endpoint) to retrieve or submit data. The browser updates the DOM dynamically without reloading the entire page.

  1. Initial load: Serve an HTML/JS bundle.
  2. API calls: The JavaScript code fetches data from endpoints.
  3. DOM updates: The application dynamically changes the page content in response to user input or new data.

Pros of Dynamic Content

  1. Personalization: Content can adapt to user sessions, preferences, or real-time data.
  2. Database-Driven: Frameworks easily fetch from databases and create fresh views.
  3. Rich Interactivity: Client-side applications can present dynamic UIs without full page reloads.

Cons of Dynamic Content

  1. Higher Server Load: Generating pages or serving data from DB queries adds overhead.
  2. Caching Complexity: Output can vary per request, making it harder to cache effectively.
  3. Security Concerns: Server-side code can have vulnerabilities (SQL injection, cross-site scripting) if not written properly.

Simple Server-Side Example (Node.js/Express)

const express = require('express');
const app = express();
const PORT = 3000;
 
app.get('/hello/:name', (req, res) => {
  const userName = req.params.name;
  // Dynamic response
  res.send(`<h1>Hello, ${userName}!</h1>`);
});
 
app.listen(PORT, () => {
  console.log(`Server running on http://localhost:${PORT}`);
});

Explanation:

  • The route /hello/:name captures a parameter in the URL.
  • The server renders a custom greeting with the user-supplied name.
  • Each request is processed at runtime.

Hybrid Approaches and Caching

Real-world applications often serve a mix of static and dynamic content. For instance, static files (images, CSS) might be on a CDN, while dynamic requests go to application servers.

Edge-Side Includes and Partial Templating

  • Some sites generate partial dynamic components while the rest of the page remains static.
  • CDNs can handle static portions while dynamically fetching content fragments from an origin server.

Server-Side Caching Layers

For dynamic pages that don’t change frequently, caching can be applied at various layers:

Client                CDN/Reverse Proxy               Application Server
   |                         |                                |
   | 1. Request /blog        |                                |
   |------------------------->| 2. Cache check                 |
   |                         |-> if found, serve from cache    |
   |                         |-> else forward to origin        |
   |<-------------------------|                                |
   | (cached or newly fetched content)                         |

When the server knows a page rarely changes, it can store the generated output. The next request might be served directly from cache, accelerating performance.

Performance Considerations

Response Times and Throughput

A formula for concurrency can illustrate the difference in server load for static vs dynamic:

Max_Connections = (Available_Threads or Workers) / Average_Request_Time
  • For static files, Average_Request_Time is minimal (reading from file system or memory).
  • For dynamic requests, generating content can increase Average_Request_Time, thus lowering Max_Connections.

Scalability

Static servers are easily scaled horizontally with CDNs or multiple mirrored instances. Dynamic servers often require logic replication, database scaling, or load-balancing across multiple application nodes.

Bandwidth Usage

Large static files can be served via CDN to reduce load on the origin server. Dynamic requests frequently have smaller payloads (JSON, HTML fragments), but the server’s CPU and database resources handle the heavier processing.

Example Deployment Scenarios

Fully Static Site with CDN

  1. HTML/CSS/JS are built (e.g., via a static site generator).
  2. Content is uploaded to a CDN like Cloudflare or AWS CloudFront.
  3. Users fetch content from geographically distributed edge servers.
Client
 |      
 |   (HTTP GET)
 v
[CDN Edge Server] -- retrieves from origin if needed --> [Origin Bucket or Host]

This design excels for blogs, documentation, or landing pages without user-specific data.

Dynamic Web App with API

  1. A Node.js or Python server handles user sessions.
  2. Requests that need personalization or database queries go through the backend.
  3. Static assets (images, scripts) can still be offloaded to a CDN.
Client
 |
 |   GET /app
 v
[Web/App Server] -- queries DB --> [Database]
 |
 |   Serves HTML or JSON
 v
Client updates the UI

In this pattern, the server merges data with templates or returns JSON for a client-side app to render.

When to Choose Static vs Dynamic

  1. Static: Content that seldom changes, marketing pages, product brochures, or high-traffic sites that can benefit from CDN caching.
  2. Dynamic: Personalized dashboards, e-commerce with custom user carts, real-time feeds, or any scenario that relies on active data processing.

Real-world applications commonly blend both. Static resources like images and CSS are straightforward to cache, while dynamic endpoints handle user interactions or frequent data updates.

Graph View