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

Building online apps that load quickly and function effectively on a variety of devices has always required server-side rendering. Blazor has historically offered a number of rendering alternatives in ASP.NET Core, such as WebAssembly-based rendering and interactive server rendering. Static Server-Side Rendering, often known as static SSR, is a more straightforward method in which the server creates the HTML and transmits it to the browser without creating an interactive Blazor circuit for that particular site.

That distinction may be significant.

Sending ready-to-use HTML can lessen the amount of work the browser must do if a page merely has to show content and doesn't involve client-side interaction. Additionally, it can lessen the amount of runtime infrastructure and application-specific JavaScript needed to make that page interactive.

Instead of seeing static SSR as merely another rendering option, it is worthwhile to consider it from a performance standpoint in light of the upcoming enhancements in ASP.NET Core 11.

This article describes the operation of static SSR, how to assess its effectiveness, and how to compare HTML payloads without drawing unwarranted conclusions about the outcomes. 

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);
}

Razor C#

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();

C#

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>

Razor C#

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

Bash

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"
    });
});

C#

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:

1. Request URL

2. Status code

3. Transferred size

4. Resource size

5. Waiting time

6. Content download time

7. 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;
});

C#

Then enable it in the middleware pipeline:

var app = builder.Build();

app.UseResponseCompression();

app.UseStaticFiles();

app.UseAntiforgery();

app.MapRazorComponents<App>();

app.Run();

C#

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:

1. Database query duration.

2. Number of database queries.

3. Server-side component processing.

4. Large object creation.

5. Expensive serialization.

6. HTML size.

7. Compression configuration.

8. Additional CSS and JavaScript requests.

9. Cache behavior.

10. 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.

Windows Hosting Recommendation

HostForLIFEASP.NET receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 10.0 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

Comparing NativeAOT CLI Tools with JIT-Based.NET Applications

The performance profile of long-running web services differs from that of command-line programs. In order to give the.NET runtime time to optimize execution after initialization, a web API may remain active for hours or days. A CLI tool may take some input, generate output, operate for a few seconds, and then terminate.

This increases the significance of startup time and application footprint. Instead of using the conventional JIT-based execution approach, NativeAOT offers a technique to compile an application into native code in advance.

But NativeAOT is not automatically faster for every workload.

A useful engineering question is:

When does NativeAOT provide a measurable advantage over a conventional JIT-based .NET CLI application?

The answer depends on startup cost, workload duration, binary size, memory usage, throughput, dependencies, reflection requirements, and deployment environment.

This article presents a practical methodology for benchmarking NativeAOT CLI tools against conventional .NET applications without confusing startup improvements with overall application performance.

What NativeAOT Changes

A conventional .NET application typically follows a runtime model similar to:

Application
    |
    v
.NET runtime
    |
    v
JIT compilation
    |
    v
Machine code
    |
    v
Execution

NativeAOT changes the model:

Application
    |
    v
AOT compilation
    |
    v
Native executable
    |
    v
Operating system
    |
    v
Execution

The important difference is when code generation happens.

With JIT-based execution, portions of code can be compiled at runtime.

With NativeAOT, application code is compiled ahead of time.

This can reduce startup work, but it also introduces additional build-time constraints.

Why CLI Applications Are Interesting

Consider a CLI command that executes for 300 milliseconds.

The total execution time may look like:

Startup      100 ms
Processing   150 ms
Shutdown      50 ms
-------------------
Total        300 ms

If startup is reduced significantly, the total runtime can change substantially.

Now consider a server application:

Startup       500 ms
Processing    12 hours

The startup difference is almost irrelevant to the application's lifetime.

This is why NativeAOT benchmarking is particularly interesting for:

• Developer CLI tools

• Build utilities

• Code generators

• File-processing tools

• Deployment utilities

• Short-lived automation jobs

• Containerized command-line workloads

JIT-Based and NativeAOT Builds Are Different Deployment Models

A fair benchmark should compare equivalent applications.

For example:

CLI source
   |
   +---- Standard .NET build
   |
   +---- NativeAOT publish

Both versions should:

• Perform the same work

• Process the same input

• Produce the same output

• Use the same algorithm

• Run on the same machine

• Use the same operating-system environment

Do not compare a highly optimized NativeAOT implementation with a different JIT implementation.

The benchmark is about the deployment model, not application design.

Create a Representative CLI Workload

Start with a simple application that performs measurable work.

For example, a JSON-processing CLI might:

1. Read a file.

2. Deserialize records.

3. Transform the data.

4. Calculate summary information.

5. Serialize the result.

6. Exit.

A simplified implementation could look like:

using System.Text.Json;

var inputPath = args.Length > 0
    ? args[0]
    : "input.json";

await using var stream =
    File.OpenRead(inputPath);

var records =
    await JsonSerializer.DeserializeAsync<List<Record>>(stream)
    ?? [];

var total = records.Sum(x => x.Amount);

Console.WriteLine(
    $"Records: {records.Count}");

Console.WriteLine(
    $"Total: {total:N2}");

public sealed class Record
{
    public int Id { get; set; }
    public decimal Amount { get; set; }
}

C#

The application should do enough work to make the benchmark meaningful.

Publish the Standard Version

Build the conventional application using the normal release configuration:

dotnet publish \
    -c Release \
    -r win-x64 \
    --self-contained true

Bash

The exact runtime identifier should match the machine used for testing.

Self-contained and framework-dependent deployments should not be mixed in the same comparison because they represent different deployment characteristics.

Publish the NativeAOT Version

NativeAOT can be enabled in the project configuration.

A simplified project configuration looks like:

<PropertyGroup>
    <PublishAot>true</PublishAot>
</PropertyGroup>

XML

Then publish for the target runtime:

dotnet publish \
    -c Release \
    -r win-x64

Bash

The resulting output is intended to run as a native executable.

The important point is that the NativeAOT build should use the same source code and release configuration as the baseline unless the benchmark explicitly investigates a different configuration.

NativeAOT Has Compatibility Constraints

NativeAOT is not simply a switch that makes every .NET application faster.

Some applications depend heavily on runtime behaviors such as:

• Reflection

• Dynamic code generation

• Runtime type discovery

• Certain serialization patterns

• Dynamic loading

• Libraries that are not AOT-compatible

Modern .NET libraries increasingly provide AOT-friendly patterns, but an application should be tested rather than assumed to be compatible.

This matters when designing a benchmark.

If the JIT version works but the NativeAOT version requires substantial architectural changes, you are no longer measuring only the runtime deployment model.

Measure Startup Separately

One of the biggest mistakes in CLI benchmarking is measuring only total execution time.

Measure startup independently.

A useful conceptual model is:

Total Time
    =
Startup
+
Application Work
+
Shutdown

For a short-running CLI, startup can represent a large percentage of total execution time.

A benchmark should therefore capture:

Process launch
     |
     v
Application ready
     |
     v
Work begins
     |
     v
Application exits

Operating-system process timing tools can be used for coarse end-to-end measurements.

For more detailed investigation, application-level instrumentation can record when meaningful application work begins.

Warm Runs Can Mislead CLI Benchmarks

A JIT-based application can behave differently between its first and subsequent executions.

For example:

Run 1
Startup + JIT + application work

Run 2
Startup + cached operating-system state + application work

If you benchmark only warm runs, you may hide part of the startup cost that matters to users running a CLI command once.

Run both:

Cold-start scenario
Warm-start scenario

and clearly report which one each measurement represents.

Benchmark Repeated CLI Invocations

A useful test is to run each executable repeatedly.

For example:

Standard .NET
Run 1
Run 2
Run 3
...
Run 30

NativeAOT
Run 1
Run 2
Run 3
...
Run 30

Then calculate:

• Median

• p95

• Minimum

• Maximum

• Standard deviation

For short-lived processes, the median is often more useful than a single measurement.

A single execution can be affected by:

• File-system state

• Antivirus scanning

• CPU scheduling

• Background processes

• Operating-system caching

• Thermal conditions

Measure Memory Usage

Startup time is only one part of the comparison.

Measure process memory as well.

Useful metrics include:

Working set
Private memory
Peak memory
Managed allocations

Do not confuse process working set with managed heap size.

A native executable can have different memory behavior even when the managed allocation profile is similar.

For a CLI tool running hundreds or thousands of times in automation, small differences can become operationally important.

Measure Binary and Deployment Size

NativeAOT can change the shape of the deployment artifact.

Measure:

Executable size
Total publish directory size
Number of files
Required runtime components

For example:

Metric	JIT-Based	NativeAOT
Executable size	Measure	Measure
Publish directory	Measure	Measure
Startup time	Measure	Measure
Peak memory	Measure	Measure
Processing time	Measure	Measure
Total execution time	Measure	Measure

Do not assume that NativeAOT always produces a smaller artifact.

The correct result depends on application dependencies and publishing configuration.

Separate Startup From Throughput

Suppose the benchmark produces these measurements:

JIT
Startup:     80 ms
Processing: 120 ms
Total:       200 ms

NativeAOT
Startup:     25 ms
Processing: 125 ms
Total:       150 ms

NativeAOT improves total execution time primarily because startup is lower.

That is different from saying:

NativeAOT makes the algorithm 50% faster.

It does not.

The processing phase actually became slightly slower in this hypothetical example.

This distinction is important when presenting benchmark results.

Measure CPU Usage

NativeAOT can change CPU behavior, but the direction is workload-dependent.

Measure CPU usage during:

Startup
Processing
Shutdown

For example:

CPU Time
   |
   +-- Process startup
   +-- JIT/AOT-related execution
   +-- Application processing

For short-running processes, percentage-based CPU measurements can be misleading because the process may terminate before sampling tools capture enough information.

CPU time is often more useful when available.

Avoid Overfitting to a Microbenchmark

A CLI tool that calculates a small mathematical expression may not represent a real application.

For example:

var result = 10 * 20;

C#

is not an interesting NativeAOT workload.

Instead, use workloads that represent actual CLI behavior:

JSON processing
File processing
Parsing
Code generation
Database interaction
Archive processing
Batch transformation

The benchmark should answer a real deployment question.

A Useful Benchmark Matrix

A practical test matrix might look like this:

Workload	Input Size	Runs	JIT	NativeAOT
JSON parsing	100 KB	30	Measure	Measure
JSON parsing	10 MB	30	Measure	Measure
File processing	10 MB	30	Measure	Measure
File processing	500 MB	10	Measure	Measure
Code generation	Small	30	Measure	Measure
Code generation	Large	30	Measure	Measure

The exact workloads should reflect the application's purpose.

Use BenchmarkDotNet Carefully

BenchmarkDotNet is useful for controlled .NET performance experiments, but process-startup benchmarking requires care.

A microbenchmark typically keeps one process alive and invokes methods repeatedly.

That is useful for measuring:

Method execution
Allocations
CPU performance

It is not automatically equivalent to:

Launching CLI process
Starting runtime
Loading application
Performing work
Exiting process

For CLI startup benchmarking, measure the executable as a process.

For algorithm benchmarking, BenchmarkDotNet can be used separately.

A strong performance study can therefore have two layers:

Layer 1
Process-level benchmark
        |
        +-- Startup
        +-- Total runtime
        +-- Memory
        +-- Deployment size

Layer 2
Method-level benchmark
        |
        +-- CPU
        +-- Allocations
        +-- Throughput

This prevents startup and algorithm performance from being mixed together.

Control the Benchmark Environment

Run both versions under the same conditions.

Keep consistent:

• Operating system

• CPU

• Memory

• Runtime identifier

• Input files

• Working directory

• Environment variables

• Power profile

• Background workload

• Security scanning configuration

• File-system location

For serious performance work, run the benchmark multiple times and document the environment.

Otherwise, the result may be impossible to reproduce.

Common Mistakes

Measuring Only One Execution

One process launch is not enough to establish a reliable performance difference.

Comparing Debug Builds

Always compare appropriate release builds.

Mixing Framework-Dependent and Self-Contained Builds

These deployment models have different characteristics.

Ignoring Cold Starts

For short-lived CLI tools, cold-start behavior can be the most important metric.

Measuring Only Total Runtime

Separate startup and application processing.

Assuming NativeAOT Is Always Faster

NativeAOT can improve startup while producing little or no improvement in steady-state processing.

Ignoring Compatibility

A library that depends on runtime code generation may require changes before it works correctly with NativeAOT.

Reporting Unsupported Precision

If two executions differ by a few milliseconds, do not turn that into a broad performance claim without repeated measurements.

Troubleshooting NativeAOT Build Problems

If the NativeAOT publish fails, first inspect the build output for compatibility diagnostics.

Common areas to investigate include:

Reflection
Dynamic code
Serialization
Assembly loading
Third-party dependencies
Source generators
Runtime type discovery

A useful troubleshooting approach is to isolate the problematic dependency.

For example:

Application
   |
   +-- Library A
   +-- Library B
   +-- Library C

Temporarily test whether the issue is associated with one library or one runtime feature.

Do not immediately rewrite the application.

First identify which part of the application is incompatible with the AOT compilation model.

When NativeAOT Is Worth Considering

NativeAOT deserves serious consideration when:

• Startup time is important.

• Applications run for short periods.

• Deployment as a native executable is valuable.

• Runtime installation should be minimized.

• CLI tools are launched frequently.

• Container startup matters.

• The application's dependencies support AOT effectively.

It may be less compelling when:

• The application runs continuously.

• Startup represents an insignificant portion of total runtime.

• The application depends heavily on dynamic runtime behavior.

• The workload is dominated by external I/O.

• AOT compatibility requires substantial architectural changes.

The decision should come from measurements rather than the technology label.

A Practical Benchmark Report

A useful report should contain more than a table of execution times.

Record:

Application version
.NET SDK version
OS
CPU
Memory
Runtime identifier
Publish configuration
Input dataset
Number of iterations
Cold/warm methodology
JIT configuration
NativeAOT configuration

Then report:

Metric	JIT-Based .NET	NativeAOT	Difference
Cold startup	Measure	Measure	Calculate
Warm startup	Measure	Measure	Calculate
Total runtime	Measure	Measure	Calculate
Processing time	Measure	Measure	Calculate
Peak memory	Measure	Measure	Calculate
Executable size	Measure	Measure	Calculate
Publish size	Measure	Measure	Calculate

This format makes the benchmark useful for an engineering decision.

Frequently Asked Questions

Is NativeAOT the same as ReadyToRun?

No. They are different compilation and deployment approaches. ReadyToRun can reduce some JIT work while retaining the .NET runtime model. NativeAOT produces a native executable using ahead-of-time compilation.

Does NativeAOT always improve startup time?

It can provide significant startup benefits for appropriate applications, but the actual improvement depends on the application, operating system, dependencies, and deployment configuration. Measure it.

Does NativeAOT always reduce memory usage?

No. Memory behavior depends on the application and its dependencies. Measure working set and peak memory rather than assuming a result.

Is NativeAOT useful for ASP.NET Core?

It can be useful for certain server workloads, particularly where startup and deployment characteristics matter, but the value proposition is different from a short-lived CLI tool.

Should I use BenchmarkDotNet for CLI startup?

Use process-level measurements for actual CLI startup and lifecycle behavior. BenchmarkDotNet is more appropriate for controlled method-level performance experiments.

Does NativeAOT eliminate the .NET runtime?

The deployment model produces a native executable rather than requiring the traditional JIT-based runtime execution model. However, the application still uses the relevant .NET runtime libraries and native runtime components incorporated into the application.

Conclusion

NativeAOT can be a strong option for .NET CLI applications, but its value should be demonstrated with measurements rather than assumed from the fact that the application is compiled ahead of time.

For short-lived command-line tools, startup time can represent a significant part of total execution time, making NativeAOT particularly interesting. For long-running workloads, steady-state processing performance may matter much more than startup.

A reliable comparison should therefore measure cold and warm startup, total execution time, processing time, memory usage, CPU consumption, and deployment size using the same workload and environment. Separating process-level startup measurements from method-level performance benchmarks also prevents misleading conclusions.

The best outcome of a NativeAOT benchmark is not simply proving that one deployment model is faster. It is identifying which part of the application's lifecycle benefits, by how much, and whether that improvement justifies the compatibility and build-time trade-offs of NativeAOT.

Windows Hosting Recommendation

HostForLIFE.eu receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 10.0 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More

.NET MAUI CoreCLR Migration: Startup and Memory Benchmarks

Mono has historically been utilized as the runtime for mobile platforms in.NET MAUI apps.

With.NET 11, that drastically changes.

The only runtime available for.NET MAUI mobile apps aimed at Mac Catalyst, iOS, and Android as of .NET 11 Preview 6 is CoreCLR. The CoreCLR runtime, which powers desktop programs, cloud services, ASP.NET Core, and other.NET workloads, is being leveraged by Microsoft for mobile workloads.

This goes beyond a simple implementation detail.

 

Changing the runtime can affect:

• Application startup

• Memory behavior

• Package size

• JIT and AOT behavior

• Diagnostics

• Debugging

• Reflection-heavy libraries

• Third-party dependencies

• Platform integrations

Microsoft's own guidance is clear that developers should measure their applications rather than assume that every application will improve equally. The .NET MAUI team specifically recommends comparing startup and package size against a .NET 10 baseline using real devices and Release builds.

This makes CoreCLR migration an excellent opportunity for a controlled benchmark.

What Changed in .NET MAUI?

Previously, the runtime architecture for mobile applications was different from the server and desktop .NET ecosystem.

The simplified model was:

.NET MAUI Android/iOS
        |
        v
      Mono

while many other .NET workloads used:

ASP.NET Core
    |
    v
  CoreCLR

.NET 11 brings the mobile platforms onto CoreCLR.

The current .NET 11 Preview 6 architecture is:

.NET MAUI
   |
   +---- Android
   |
   +---- iOS
   |
   +---- Mac Catalyst
   |
   v
 CoreCLR

Microsoft also clarifies that Blazor WebAssembly is not affected by this change and continues to use Mono.

Why CoreCLR Matters

Runtime unification provides several potential benefits.

CoreCLR brings technologies such as:

• Tiered JIT

• ReadyToRun

• Profile-Guided Optimization

• Shared runtime implementation

• Common .NET diagnostics tooling

Microsoft describes CoreCLR as providing a stronger foundation for runtime performance and future NativeAOT work on mobile platforms.

However, these capabilities do not guarantee that every application will automatically become faster.

Application startup depends on much more than the runtime:

Startup
  |
  +-- Runtime initialization
  +-- JIT / native code
  +-- Dependency loading
  +-- DI registration
  +-- XAML loading
  +-- Database initialization
  +-- Network calls
  +-- Image loading
  +-- Third-party SDKs

That is why measurement is essential.

Define the Benchmark Before Migrating

A useful benchmark compares the existing application with the migrated version.

For example:

Baseline
.NET 10 + existing runtime
        |
        v
Measurements

Candidate
.NET 11 + CoreCLR
        |
        v
Measurements

Comparison
        |
        v
Decision

Do not change several unrelated application components at the same time.

If you simultaneously:

• Upgrade .NET

• Replace the database

• Rewrite startup logic

• Upgrade every NuGet package

• Change image libraries

then you will not know which change caused a performance difference.

Benchmark Environment

A reproducible benchmark should document:

.NET SDK version
.NET MAUI version
Target platform
Device model
OS version
CPU architecture
Build configuration
Linker/trimming settings
AOT configuration
Application build
Network state
Database state

For mobile benchmarks, real devices are especially important.

An emulator can be useful for development, but it should not be the only source of production-performance conclusions.

Microsoft explicitly recommends measuring .NET 11 MAUI applications on target devices and comparing them with the .NET 10 baseline.

Create a .NET 10 Baseline

Before migrating, build the existing application in Release mode.

For example:

dotnet publish \
  -f net10.0-android \
  -c Release

Bash

The exact target framework depends on the project and installed SDK.

Record at least:

Cold startup
Warm startup
Package size
Memory usage
CPU usage
Time to first screen
Time to usable application

Do not rely only on stopwatch measurements.

Automated instrumentation provides more consistent results.

Measure Cold Startup

Cold startup means the application is not already running.

A simplified test looks like:

Force Stop
    |
    v
Launch Application
    |
    v
Runtime Starts
    |
    v
Application Initializes
    |
    v
First Usable Screen

Measure the interval between launch and a clearly defined application-ready event.

For example:

var startupTimer =
    Stopwatch.StartNew();

InitializeApplication();

startupTimer.Stop();

logger.LogInformation(
    "Application startup: {ElapsedMs} ms",
    startupTimer.ElapsedMilliseconds);

C#

The exact location of the timer matters.

If you stop the timer too early, you may measure only framework initialization rather than the time users actually experience.

Define "Startup Complete"

This needs to be explicit.

Possible definitions include:

Application process started
        |
        v
Main page created
        |
        v
Navigation initialized
        |
        v
Initial data loaded
        |
        v
First interactive screen

For a user-facing benchmark, the last meaningful event is often more useful than process creation.

However, the definition should remain consistent between the baseline and migrated builds.

Measure Warm Startup

Warm startup is different.

The operating system may retain application-related resources after the first launch.

A benchmark should therefore distinguish:

Cold Start
Application not running

Warm Start
Application restarted with some resources cached

Run each test multiple times rather than relying on one measurement.

For example:

Cold:
Run 1
Run 2
Run 3
Run 4
Run 5

Warm:
Run 1
Run 2
Run 3
Run 4
Run 5

Then report the distribution.

Avoid publishing a single number without explaining how it was obtained.

Measure Package Size

Runtime changes can also affect application size.

For Android, measure the resulting APK or AAB.

For iOS, measure the resulting IPA or relevant packaged application artifact.

Microsoft specifically recommends comparing package size between the .NET 10 baseline and .NET 11 CoreCLR builds.

Record:

Raw package size
Compressed distribution size where relevant
Architecture-specific size

Be consistent between builds.

Do not compare an Android APK from one configuration with an Android AAB from another and treat the difference as a runtime effect.

Measure Memory Usage

Startup time is only one part of the benchmark.

Measure memory after defined application states.

For example:

Launch
  |
  v
Main Screen
  |
  v
Load Data
  |
  v
Navigate
  |
  v
Open Detail Screen
  |
  v
Return
  |
  v
Measure

This helps detect memory growth caused by application behavior rather than startup alone.

Useful measurements include:

• Working set

• Managed heap

• Allocation rate

• GC collections

• Native memory where available

Use .NET Diagnostics

One advantage of CoreCLR on mobile is the availability of familiar .NET diagnostics.

Microsoft states that tools such as dotnet-trace and dotnet-counters can now be used with .NET MAUI mobile applications running on CoreCLR.

That makes it easier for teams already familiar with server-side .NET diagnostics to investigate mobile runtime behavior.

Conceptually:

MAUI Application
      |
      v
CoreCLR
      |
      +---- dotnet-trace
      |
      +---- dotnet-counters
      |
      +---- Runtime Metrics

The exact connection and collection workflow varies by platform and development environment.

Monitor Runtime Counters

Runtime counters can help identify whether an observed slowdown is related to:

• CPU utilization

• GC

• Allocation

• Threading

• Exceptions

The important point is correlation.

For example:

Startup slower
     |
     +-- CPU high?
     +-- Allocation high?
     +-- GC activity high?
     +-- Dependency loading slow?

A benchmark result becomes much more useful when you can explain why it changed.

Benchmark Memory After Navigation

A mobile application may appear efficient during startup but accumulate memory as users navigate.

Create a repeatable workflow:

Home
 |
 v
List
 |
 v
Details
 |
 v
Back
 |
 v
List
 |
 v
Details
 |
 v
Back

Repeat the workflow several times.

Measure memory after each cycle.

If memory continuously increases, investigate whether the application has:

• Event-handler leaks

• Unreleased subscriptions

• Cached images

• Retained pages

• Native resource leaks

• Long-lived references

Do not automatically attribute memory growth to CoreCLR.

The runtime is only one part of the application.

Compare Equivalent Builds

The baseline and candidate should be as similar as possible.

For example:

Variable	.NET 10 Baseline	.NET 11 Candidate
Application source	Same	Same
Device	Same	Same
OS	Same	Same
Build mode	Release	Release
Data	Same	Same
Network	Same	Same
Test workflow	Same	Same
Runtime	Baseline	CoreCLR

This makes the runtime migration the primary experimental variable.

Test Real Application Flows

A benchmark based only on:

Launch -> Exit

is not enough for a complex application.

Microsoft recommends exercising the complete application flow, including navigation, data loading, and platform-specific integrations.

A realistic workflow might be:

Launch
  |
  v
Authentication
  |
  v
Dashboard
  |
  v
Load API data
  |
  v
Open list
  |
  v
Open detail
  |
  v
Perform action
  |
  v
Return to dashboard

This exposes issues that a startup-only benchmark cannot detect.

Test Platform-Specific Integrations

.NET MAUI applications frequently use platform-specific capabilities.

Examples include:

• Camera

• Location

• Notifications

• Bluetooth

• Files

• Sensors

• Media

• Native SDKs

Test them separately.

For example:

CoreCLR Migration
       |
       +-- Android API
       +-- iOS API
       +-- Mac Catalyst API
       +-- Third-party native SDK

A runtime migration can expose compatibility problems in libraries that depend on reflection, dynamic code generation, or runtime-specific behavior.

Microsoft specifically calls out third-party libraries using reflection, dynamic code generation, or Mono-specific APIs as areas that should be validated during the transition.

Review Reflection-Heavy Libraries

Reflection can be important for:

• Dependency injection

• Serialization

• ORMs

• Plugin systems

• Dependency discovery

• Native bindings

Audit libraries that dynamically inspect types.

For example:

var type =
    Type.GetType(typeName);

C#

The code may work under one runtime configuration but behave differently when trimming, AOT, or runtime assumptions change.

Do not assume a successful startup proves that all dynamically discovered types remain available.

Test the actual feature.

Review Dynamic Code Generation

Some libraries rely on:

Expression Trees
Reflection.Emit
Dynamic Methods
Runtime-generated proxies

These areas deserve additional testing when moving between runtime and compilation configurations.

If a third-party component documents runtime-specific requirements, follow the vendor's compatibility guidance.

CoreCLR and ReadyToRun

CoreCLR can use ReadyToRun (R2R) images to reduce some runtime compilation work.

Microsoft describes partial R2R and packaged PGO profiles as part of the .NET 11 mobile performance work.

Conceptually:

Application Assembly
       |
       v
ReadyToRun Code
       |
       v
Runtime
       |
       v
Reduced JIT Work

This can affect startup behavior, but the actual result depends on the application.

Therefore, measure startup rather than assuming R2R will produce a specific percentage improvement.

CoreCLR and PGO

Profile-Guided Optimization can use runtime behavior to improve generated code.

The simplified concept is:

Application Execution
        |
        v
Profile Information
        |
        v
Optimization
        |
        v
Application Build/Runtime

Again, the correct engineering approach is measurement.

If your application has a different execution profile from the workload used to produce an optimization profile, the results may differ.

Compare Memory Under Load

Do not only measure memory immediately after launch.

Create defined checkpoints:

T0  = After launch
T1  = After login
T2  = After initial data load
T3  = After navigation
T4  = After repeated workflow
T5  = After idle period

Then compare:

.NET 10
vs
.NET 11 CoreCLR

The resulting graph or table can reveal whether memory stabilizes or continually increases.

Do not claim a memory improvement unless the measurements support it.

Example Benchmark Table

A final article or engineering report can use a table such as:

Metric	.NET 10	.NET 11 CoreCLR	Difference
Cold startup	Measure	Measure	Calculate
Warm startup	Measure	Measure	Calculate
Package size	Measure	Measure	Calculate
Initial memory	Measure	Measure	Calculate
Memory after workflow	Measure	Measure	Calculate
Allocation rate	Measure	Measure	Calculate

The numbers should come from your actual test environment.

For example, if baseline startup is 1,000 ms and the candidate is 900 ms:

Improvement =
(1000 - 900) / 1000 * 100
= 10%

Do not substitute hypothetical values into a production benchmark.

Automate the Benchmark

Manual measurements are useful for initial validation, but automation improves repeatability.

A benchmark harness can record:

{
  "runtime": "net11.0",
  "platform": "android",
  "device": "test-device",
  "build": "Release",
  "coldStartupMs": 0,
  "warmStartupMs": 0,
  "packageSizeBytes": 0,
  "memoryBytes": 0
}

JSON

The actual values should be populated by the measurement system.

Then compare baseline and candidate builds automatically.

Test on Multiple Devices

Mobile hardware varies significantly.

A single device cannot represent every target.

Where practical, test representative device classes:

Older / lower-end
        |
        v
Mid-range
        |
        v
High-end

For iOS, similarly test the device generations relevant to the application's supported deployment range.

The objective is not to benchmark every device.

It is to identify whether runtime behavior changes significantly across the supported hardware range.

Test Android and iOS Separately

Do not combine platform results.

Use:

Android
.NET 10 -> .NET 11

iOS
.NET 10 -> .NET 11

Mac Catalyst
.NET 10 -> .NET 11

Microsoft reports different performance characteristics across platforms during the CoreCLR transition. Its Preview 6 update states that iOS and Mac Catalyst are generally faster than Mono, while Android was within 10 percent of Mono for startup and app size in Microsoft's reported validation. These are Microsoft's observations, not a universal benchmark for every application.

Your application's results can differ.

Common Migration Problems

Startup Gets Worse

Do not immediately revert the migration.

Profile startup first.

Look at:

Dependency loading
JIT
R2R
PGO
Reflection
Third-party libraries
Network calls
Database initialization

Microsoft has acknowledged reports of startup and package-size regressions in some larger Android applications during the preview transition.

Package Size Increases

Compare the complete packaged artifact.

Then inspect:

Runtime
Native libraries
Managed assemblies
Resources
Architecture-specific binaries

Determine whether the increase comes from the runtime or another dependency.

A Third-Party Library Stops Working

Check whether the library depends on:

• Mono-specific APIs

• Reflection

• Dynamic code generation

• Native bindings

• Runtime assumptions

Then check the library's compatibility information.

Hot Reload Behaves Differently

Hot Reload and debugging have been actively evolving during the CoreCLR mobile transition.

Microsoft reports substantial progress in Preview 6 while noting that some scenarios remain in progress.

Do not use development-time tooling behavior as the only reason to reject a Release build migration.

Common Benchmarking Mistakes

Comparing Different Devices

Always use the same device when comparing two builds.

Comparing Debug With Release

Use Release builds for production-oriented performance measurements.

Measuring Only Startup

Startup is important, but it is only one part of mobile performance.

Measuring Only Memory

Memory should be evaluated alongside allocations, GC behavior, application state, and native resources.

Using One Run

One measurement can be affected by background processes, caches, thermal conditions, and other variables.

Changing Application Code During the Experiment

If you optimize the application between baseline and candidate measurements, the runtime is no longer the only variable.

Publishing Microsoft's Numbers as Your Own

Microsoft's published observations are useful context, but they should not be presented as a benchmark of your application.

A Practical Migration Benchmark Workflow

Use this sequence:

Build .NET 10 Baseline
        |
        v
Release to Test Device
        |
        v
Measure Startup
        |
        v
Measure Memory
        |
        v
Measure Package Size
        |
        v
Run Full App Workflow
        |
        v
Migrate to .NET 11
        |
        v
Repeat Identical Tests
        |
        v
Compare Results
        |
        v
Investigate Regressions

This approach produces evidence rather than assumptions.

Best Practices

1. Create a .NET 10 baseline before migration.

2. Use .NET 11 Release builds for comparison.

3. Test on real target devices.

4. Keep the test workload identical.

5. Measure cold and warm startup separately.

6. Measure package size.

7. Measure memory at multiple application states.

8. Use runtime diagnostics when investigating differences.

9. Test third-party libraries explicitly.

10. Test complete application flows.

11. Separate Android, iOS, and Mac Catalyst results.

12. Do not assume CoreCLR produces the same improvement for every application.

13. Record the exact SDK, runtime, device, and build configuration.

14. Do not publish benchmark numbers that you did not actually measure.

Frequently Asked Questions

Is CoreCLR now the default for .NET MAUI in .NET 11?

More precisely, as of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI mobile apps targeting Android, iOS, and Mac Catalyst. The previous Mono selection path has been removed for those targets in that preview.

Does this affect Blazor WebAssembly?

No.

Microsoft explicitly states that Blazor WebAssembly continues to use Mono and is not affected by this .NET 11 MAUI runtime transition.

Will CoreCLR automatically make my MAUI application faster?

No universal guarantee should be made.

Microsoft reports positive results in its validation, but also acknowledges application-specific regressions, particularly in some Android scenarios. The recommended approach is to measure your own application against its .NET 10 baseline.

What should I benchmark first?

Start with:

1. Cold startup

2. Warm startup

3. Package size

4. Initial memory

5. Memory after a representative workflow

Then investigate any meaningful differences with runtime diagnostics.

Should I benchmark an emulator?

An emulator can be useful for development and repeatable functional tests.

For production performance conclusions, prioritize real devices that represent your supported hardware.

Can I continue using Mono with .NET 11 Preview 6?

Microsoft's Preview 6 announcement states that CoreCLR is now the only runtime for .NET MAUI mobile applications on Android, iOS, and Mac Catalyst and that the previous Mono selection path has been removed.

Conclusion

The move from Mono to CoreCLR is one of the most significant runtime changes for .NET MAUI mobile applications.

As of .NET 11 Preview 6, CoreCLR is the only runtime for .NET MAUI Android, iOS, and Mac Catalyst applications. Microsoft has positioned the change around runtime unification, performance foundations, diagnostics, and the longer-term NativeAOT direction.

But the correct migration strategy is not:

.NET 10
   |
   v
.NET 11
   |
   v
Assume Faster

It should be:

.NET 10 Baseline
       |
       v
Measure
       |
       v
.NET 11 CoreCLR
       |
       v
Measure Again
       |
       v
Compare
       |
       v
Profile
       |
       v
Optimize

The most important metrics are not limited to startup time.

A meaningful CoreCLR migration benchmark should examine:

Startup
+
Memory
+
Package Size
+
Allocations
+
GC Behavior
+
Application Workflow
+
Third-Party Compatibility
+
Platform Integrations

The key principle is simple:

Do not migrate to CoreCLR because a benchmark says mobile applications are faster. Migrate with evidence that CoreCLR works correctly and delivers acceptable behavior for your application, devices, and production workload.

The .NET 11 preview window provides an opportunity to establish that evidence before the final release. Microsoft is explicitly asking developers to test their applications now and report reproducible results, making application-specific benchmarking particularly valuable during this transition.

Windows Hosting Recommendation

HostForLIFE.eu receives Spotlight standing advantage award for providing recommended, cheap and fast ecommerce Hosting including the latest Magento. From the leading technology company, Microsoft. All the servers are equipped with the newest Windows Server 2022 R2, SQL Server 2022, ASP.NET Core 7.0.10 , ASP.NET MVC, Silverlight 5, WebMatrix and Visual Studio Lightswitch. Security and performance are at the core of their Magento hosting operations to confirm every website and/or application hosted on their servers is highly secured and performs at optimum level. mutually of the European ASP.NET hosting suppliers, HostForLIFE guarantees 99.9% uptime and fast loading speed. From €3.49/month , HostForLIFE provides you with unlimited disk space, unlimited domains, unlimited bandwidth,etc, for your website hosting needs.

 

Read More