Why WPF Slows Down with Many Labels and When to Switch to TextBlock

Overview

A performance issue was observed in WPF screens that placed many Label controls.
Initial rendering and redraw responsiveness degraded as the number of text elements increased.
This article explains the structural difference between Label and TextBlock, clarifies the root cause, and provides practical selection criteria.

Prerequisites / Environment

Framework / Language: .NET 8 / C# 12 / WPF
Target controls: Label, TextBlock
Architecture: MVVM (the same behavior appears in code-behind)
Screen type: list views and dashboards with many text elements

Problem

When Label controls are placed in large quantities, the following issues become noticeable.

Initial screen rendering becomes slower.
Redraw operations during resize and scroll become less responsive.
Memory usage tends to increase compared to an equivalent TextBlock-based layout.

A common cause is reusing a form-label-oriented Label design in dense, read-heavy display areas.

Cause / Background

TextBlock is a lightweight text-rendering element and directly derives from FrameworkElement.
By contrast, Label derives from ContentControl, which is designed as a more general UI component that can host non-text content and interaction features.

Label renders through ContentPresenter and provides additional capabilities such as access-key handling and Target-based focus linkage.
This functional overhead is useful in forms but becomes a cost factor when large numbers of simple text elements are rendered.

The difference is measurable.
Placing 1,000 elements carrying the same string into a StackPanel and measuring both the number of visuals in the resulting tree and the time from Measure to UpdateLayout gives the following.

A table of measurements. 1000 Label controls produce 4,002 visual elements and take 385.3 milliseconds to lay out, while TextBlock produces 1,002 and takes 153.9 milliseconds. — Measured on .NET 10 / Windows 11 with the default theme (Aero2) `ControlTemplate` and a string assigned to `Content`. Under those conditions each `Label` builds four visuals where a `TextBlock` builds one, and the layout pass took roughly 2.5 times as long. The visual count changes with the theme or a replaced `ControlTemplate`, and absolute timings depend on the machine, so read the ratio rather than the numbers.

The roughly fourfold element count is the essential point.
With the default template, each Label additionally builds a Border, a ContentPresenter and the TextBlock that actually draws the text, so every measure, arrange and render pass has more objects to process.
When Content holds a string containing an access key (_), the ContentPresenter inserts an AccessText as well, bringing the count to five.
The measurement above uses a string without an access key.

Solution

The recommended approach is to separate use cases into display-only text and interactive form labels.

Display-only text: use TextBlock as the default.
Form captions: keep Label only where access keys or Target linkage are required.
Existing screens: migrate incrementally instead of replacing every Label at once.

Implementation

The first example replaces a display-only Label with TextBlock.
This change removes unnecessary control features from high-volume text areas and reduces rendering overhead.

<!-- Before -->
<Label Content="Status: Running" />

<!-- After -->
<TextBlock Text="Status: Running" />

This replacement is straightforward for static display text.
Because Label has default padding and TextBlock is more compact, spacing may need explicit adjustment using Margin or layout properties.

The next example keeps Label for an input form caption where focus behavior is required.
This preserves usability and keyboard accessibility while limiting Label usage to places where it adds value.

<StackPanel Orientation="Horizontal">
    <Label Content="Name(_N):"
           Target="{Binding ElementName=NameTextBox}"
           VerticalAlignment="Center" />
    <TextBox x:Name="NameTextBox" Width="180" />
</StackPanel>

If Alt + N focus movement and label-click focus transfer are required, Label remains the appropriate choice.
The key point is selective use, not complete elimination.

Notes

Replacing Label with TextBlock removes access-key behavior (_) and Target-based focus linkage.
For long text, set TextWrapping="Wrap" or TextTrimming explicitly on TextBlock to avoid layout regressions.
Existing layouts may depend on Label’s default padding, so visual spacing and alignment should be revalidated after migration.
In DataGrid and ItemsControl templates, evaluate this change together with virtualization settings for best results.

Alternatives / Comparison

Approach	Pros	Cons	Best suited for
Keep all controls as `Label`	Preserves access keys and `Target` behavior everywhere	Higher rendering overhead in dense views	Small forms with limited item counts
Replace display-only areas with `TextBlock`	Reduces rendering and memory pressure	Requires spacing and wrapping review	List and monitoring screens with many text elements
Convert the entire screen to `TextBlock`	Simplifies and lightens the visual tree	Loses `Label`-specific interaction features	Read-only screens without input focus linkage

Summary

The main reason WPF slows down with many Label controls is the overhead of Label as a general-purpose ContentControl.
For performance-sensitive screens, shifting display-only text to TextBlock is an effective baseline strategy.

Selection criteria are as follows.

Keep Label where Target linkage and access keys are required.
Use TextBlock for simple text display by default.
In high-density rendering areas, reevaluate control choice together with layout and virtualization settings.

Following this policy improves rendering performance while preserving form usability where needed.

Why WPF Label Hides Underscores and How to Fix It