ASP.NET Core 11 Static SSR: Measuring Performance and HTML Payload Size

Introduction

Server-side rendering has always been an important part of building web applications that load quickly and work well across different devices.

In ASP.NET Core, Blazor has traditionally provided several rendering options, including interactive server rendering and WebAssembly-based rendering. Static Server-Side Rendering, commonly called static SSR, takes a simpler approach: the server generates the HTML and sends it to the browser without establishing an interactive Blazor circuit for that page.

That difference can matter.

If a page only needs to display content and does not require client-side interaction, sending ready-to-use HTML can reduce the amount of work the browser needs to perform. It can also reduce the amount of application-specific JavaScript and runtime infrastructure involved in making that page interactive.

With the improvements coming in ASP.NET Core 11, static SSR is worth looking at from a performance perspective rather than treating it as just another rendering option.

This article explains how static SSR works, how to measure its performance, and how to compare HTML payloads without making unsupported assumptions about the results.

What Is Static SSR?

Static SSR means that the server renders a component into HTML and returns that HTML as part of the HTTP response.

The basic flow looks like this:

Browser
   |
   | HTTP Request
   v
ASP.NET Core Server
   |
   | Render component
   v
Generated HTML
   |
   | HTTP Response
   v
Browser displays HTML

There is no requirement for the page to become interactive after rendering.

For example, a simple Razor component can contain:

@page "/products"

<h1>Products</h1>

<ul>
    @foreach (var product in Products)
    {
        <li>
            @product.Name - @product.Price.ToString("C")
        </li>
    }
</ul>

@code {
    private readonly List<Product> Products =
    [
        new("Laptop", 85000),
        new("Monitor", 18000),
        new("Keyboard", 2500)
    ];

    private record Product(string Name, decimal Price);
}

The server renders the component and returns HTML that the browser can display directly.

This is different from an application where the browser first downloads a client-side runtime and then performs additional rendering work.

Static SSR vs Interactive Rendering

The most important question is not whether static SSR is faster in every situation. It is whether it is the right rendering mode for a particular page.

Area	Static SSR	Interactive Server	WebAssembly
Initial HTML	Server-generated	Server-generated	Client-generated after startup
Browser runtime	Minimal	Requires interactive infrastructure	Requires WebAssembly runtime
Interactivity	No by default	Yes	Yes
Server connection	Not required for static rendering	Required for interactive circuit	Not required after download
Initial payload	Primarily HTML and required assets	HTML plus interactive infrastructure	HTML plus client application/runtime
Best fit	Content-focused pages	Interactive applications	Rich client-side applications

The table should not be interpreted as a universal performance ranking.

A page that contains complex server-side processing may still have a high response time even if the browser receives static HTML. Similarly, a highly interactive application may gain little from making every page static.

The rendering strategy should match the workload.

Creating a Static SSR Page

A minimal Blazor Web App can be configured with static rendering.

For example, the application can register Razor components:

var builder = WebApplication.CreateBuilder(args);

builder.Services.AddRazorComponents();

var app = builder.Build();

app.UseStaticFiles();
app.UseAntiforgery();

app.MapRazorComponents<App>();

app.Run();

The exact service and endpoint configuration can vary depending on the application and rendering modes being used.

A component can then be rendered without enabling an interactive render mode.

@page "/dashboard"

<h1>Dashboard</h1>

<p>Server-rendered dashboard content.</p>

The important idea is that the page does not automatically require an interactive client connection simply to display its content.

Why HTML Payload Size Matters

Startup performance is not determined by server response time alone.

The browser also needs to receive the response, parse the HTML, download required resources, construct the DOM, and render the page.

A simplified model is:

Request
   |
   v
Server Processing
   |
   v
HTML Response
   |
   v
Network Transfer
   |
   v
HTML Parsing
   |
   v
DOM Construction
   |
   v
Visual Rendering

A smaller response can reduce network transfer work, especially on slower connections.

However, HTML size is only one part of the overall page-load equation. Images, CSS, JavaScript, fonts, caching, compression, and server processing can all contribute to the final experience.

Measuring Response Size

The first useful experiment is to measure the actual HTTP response.

For example, you can use curl:

curl -o /dev/null -s -w \
"HTTP: %{http_code}\nSize: %{size_download} bytes\nTime: %{time_total}s\n" \
https://localhost:5001/products

For local development, the URL and port will depend on your ASP.NET Core configuration.

This gives you a basic measurement of:

HTTP status
Downloaded response size
Total request time

For more detailed analysis, browser developer tools can show request size, transferred size, response timing, and other network information.

Measuring Server Response Time

ASP.NET Core applications can expose timing information through logging and diagnostics.

For a simple test, keep the endpoint logic stable and compare the same page under different rendering configurations.

For example:

app.MapGet("/benchmark", async () =>
{
    await Task.Delay(1);

    return Results.Ok(new
    {
        Message = "Benchmark response"
    });
});

The example above is intentionally simple. In a real benchmark, the server should perform the actual work performed by the application.

If the page loads data from a database, use representative database access.

If the page performs expensive calculations, include those calculations.

Otherwise, the benchmark measures an artificial scenario rather than the application users actually experience.

Measuring Static SSR With Browser Developer Tools

The browser's Network tab is one of the easiest places to start.

Open the application and inspect the document request.

Look at:

Request URL
Status code
Transferred size
Resource size
Waiting time
Content download time
Number of additional requests

The distinction between transferred size and resource size is useful.

Compression can make the amount transferred over the network smaller than the uncompressed HTML document.

For example:

HTML resource size:      85 KB
Transferred over HTTP:   19 KB

Those numbers represent different things.

When comparing payloads, record both when possible.

Testing With Compression Enabled

ASP.NET Core supports response compression, which can significantly affect network transfer size.

A compression configuration can look like this:

builder.Services.AddResponseCompression(options =>
{
    options.EnableForHttps = true;
});

Then enable it in the middleware pipeline:

var app = builder.Build();

app.UseResponseCompression();

app.UseStaticFiles();

app.UseAntiforgery();

app.MapRazorComponents<App>();

app.Run();

The exact compression behavior depends on the request headers and server configuration.

This is why a benchmark should clearly state whether compression is enabled.

Comparing one application with compression enabled against another without compression produces misleading payload results.

Designing a Fair Benchmark

A useful benchmark should change one major variable at a time.

For example:

Variable	Test A	Test B
Application	Same	Same
Data	Same	Same
Server	Same	Same
Database	Same	Same
Network	Same	Same
Compression	Same	Same
Browser	Same	Same
Rendering mode	Static SSR	Alternative mode

This gives you a controlled comparison.

Also run the test multiple times.

The first request can behave differently because of application startup, JIT compilation, database connections, caches, and other environmental factors.

What Should You Measure?

For a practical static SSR experiment, collect several metrics.

Server-Side Metrics

Measure:

Request processing time
Response size
Server CPU usage
Server memory usage
Request throughput

Browser and Network Metrics

Measure:

HTML transferred size
HTML resource size
Document request time
Number of requests
DOM content loaded
Largest Contentful Paint where applicable

You do not need every metric for every project. Start with the measurements that answer the question you are trying to investigate.

A Simple Test Matrix

A useful experiment can compare three scenarios:

Scenario A
Static SSR + Compression

Scenario B
Static SSR + No Compression

Scenario C
Interactive Rendering

Run each scenario against the same page and data.

For example:

Scenario	Response Time	HTML Size	Transferred Size	Additional Requests
Static SSR + Compression	Measure	Measure	Measure	Measure
Static SSR	Measure	Measure	Measure	Measure
Interactive Rendering	Measure	Measure	Measure	Measure

The values should come from actual test runs rather than assumptions.

This is especially important when publishing benchmark results because server hardware, application complexity, network conditions, and browser behavior can change the outcome.

Production Considerations

Static SSR is particularly attractive for pages where the user primarily needs information.

Examples include:

Product details
Documentation
Public profiles
News or article pages
Search result pages
Marketing content
Read-only dashboards

An interactive page, however, may still need interactive rendering.

For example, a shopping cart with quantity controls does not become a better user experience simply because its initial HTML is static.

A practical application can also combine approaches.

A page can render most content statically while using interactive rendering only for components that actually require user interaction.

This avoids treating the entire application as either completely static or completely interactive.

Common Mistakes

Measuring Only HTML Size

A smaller HTML document does not automatically mean a faster application.

Look at the complete request and rendering path.

Ignoring Compression

Compressed and uncompressed payload sizes are different measurements.

Always document the compression configuration.

Comparing Different Data Sets

A page containing 10 records and another containing 10,000 records cannot provide a meaningful payload comparison.

Use the same dataset.

Benchmarking Development Builds

Development tooling can affect performance.

Use a production-like Release configuration for meaningful measurements.

Treating One Device or Network as Universal

A result from a fast local connection does not necessarily represent users on mobile networks.

Consider testing under realistic network conditions when user-facing performance is the goal.

Troubleshooting

If static SSR appears slower than expected, investigate the server before blaming the rendering mechanism.

Check:

Database query duration.
Number of database queries.
Server-side component processing.
Large object creation.
Expensive serialization.
HTML size.
Compression configuration.
Additional CSS and JavaScript requests.
Cache behavior.
Network latency.

For example, a static page that performs several slow database queries can still have a poor Time to First Byte even though the browser receives ordinary HTML.

The rendering model cannot eliminate expensive server-side work.

Advantages

Sends ready-to-display HTML from the server.
Can reduce the amount of client-side runtime work for static content.
Works well for content-focused pages.
Can provide a simple request-response model.
Allows developers to avoid unnecessary interactivity.
Can be combined with interactive rendering where needed.

Disadvantages

Does not provide client-side interactivity by itself.
Server-side rendering can still be slow if application logic is expensive.
Large datasets can produce large HTML responses.
Performance depends on server, network, browser, and application behavior.
Pages requiring rich interaction may need a different rendering mode.

Best Practices

Render Only What the User Needs

Do not generate thousands of unnecessary HTML elements simply because the server can.

Pagination, filtering, and virtualization can still matter for server-rendered applications.

Keep Server Work Efficient

Static SSR moves rendering work to the server. It does not remove that work.

Optimize database queries, avoid unnecessary service calls, and keep component initialization focused.

Measure Compressed and Uncompressed Size

Both numbers provide useful information.

Use Appropriate Rendering Modes

Use static SSR for content that does not need immediate interactivity and interactive rendering where users actually need it.

Benchmark Production-Like Builds

Use realistic data, Release configuration, representative hardware, and realistic network conditions.

Conclusion

ASP.NET Core static SSR provides a straightforward way to deliver server-generated HTML without automatically turning every page into an interactive client application.

Its performance should be evaluated using real measurements rather than broad assumptions.

The most useful experiment is a controlled comparison where the application, data, server, device, network conditions, and compression settings remain consistent while the rendering strategy changes.

Measure server response time, HTML size, transferred bytes, browser timing, and additional resource requests. Those measurements provide a much clearer picture than looking at any single metric.

Static SSR is not a universal replacement for interactive rendering. Its real value comes from using it where it fits: pages where users primarily need fast, server-generated content and do not require an interactive client runtime for every part of the experience.