diff --git a/aspnetcore/blazor/performance/rendering.md b/aspnetcore/blazor/performance/rendering.md index ba953be91769..c444757c00d8 100644 --- a/aspnetcore/blazor/performance/rendering.md +++ b/aspnetcore/blazor/performance/rendering.md @@ -1,11 +1,12 @@ --- title: ASP.NET Core Blazor rendering performance best practices +ai-usage: ai-assisted author: guardrex description: Tips for improving the rendering performance of ASP.NET Core Blazor apps and avoiding common performance problems. monikerRange: '>= aspnetcore-3.1' ms.author: wpickett ms.custom: mvc -ms.date: 11/11/2025 +ms.date: 04/28/2026 uid: blazor/performance/rendering --- # ASP.NET Core Blazor rendering performance best practices @@ -331,7 +332,17 @@ In extreme cases, you can override the component's virtual runs the normal lifecycle method without assigning parameters again. -As you can see in the preceding code, overriding and supplying custom logic is complicated and laborious, so we don't generally recommend adopting this approach. In extreme cases, it can improve rendering performance by 20-25%, but you should only consider this approach in the extreme scenarios listed earlier in this section. +:::moniker range=">= aspnetcore-8.0" + +As you can see in the preceding code, overriding and supplying custom logic is complicated and laborious, so we don't generally recommend adopting this approach. In extreme cases, the approach can yield a small rendering improvement, typically under ~10% even at 10,000+ component instances when targeting .NET 10. The potential gains are smaller in later releases because reflection-based parameter assignment is optimized. Only consider this approach in the extreme scenarios listed earlier in this section and benchmark first—the savings are usually dwarfed by other costs, for example, the SignalR [diff (DOM edits)](xref:blazor/components/lifecycle#lifecycle-events) transport for Interactive Server. + +:::moniker-end + +:::moniker range="< aspnetcore-8.0" + +As you can see in the preceding code, overriding and supplying custom logic is complicated and laborious, so we don't generally recommend adopting this approach. In extreme cases, the approach can improve rendering performance by 20-25%, but you should only consider this approach in the extreme scenarios listed earlier in this section. + +:::moniker-end ## Don't trigger events too rapidly diff --git a/aspnetcore/mvc/models/validation.md b/aspnetcore/mvc/models/validation.md index ae89dcb5c74b..b23f10b7449b 100644 --- a/aspnetcore/mvc/models/validation.md +++ b/aspnetcore/mvc/models/validation.md @@ -5,7 +5,7 @@ description: Learn about model validation in ASP.NET Core MVC and Razor Pages. monikerRange: '>= aspnetcore-3.1' ms.author: tdykstra ms.custom: mvc -ms.date: 08/28/2025 +ms.date: 04/28/2026 uid: mvc/models/validation --- # Model validation in ASP.NET Core MVC and Razor Pages @@ -153,7 +153,10 @@ To implement remote validation: :::code language="csharp" source="~/mvc/models/validation/samples/6.x/ValidationSample/Models/User.cs" id="snippet_Email"::: -[Server side validation](#custom-validation) also needs to be implemented for clients that have disabled JavaScript. +Remote validation: + +* Doesn't perform server-side validation after the form is submitted. +* Doesn't perform client-side checks if the client has disabled JavaScript. If the client-side validation check is required for form processing on the server, always implement separate server-side validation. ### Additional fields @@ -429,6 +432,7 @@ The preceding approach won't prevent client-side validation of ASP.NET Core Iden * * [Model Binding](xref:mvc/models/model-binding) +* :::moniker-end