Merge pull request #37065 from dotnet/main

Merge to Live

Author: wadepickett

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 <xref:Microsoft.AspNe
 
 In the preceding code, returning the base class <xref:Microsoft.AspNetCore.Components.ComponentBase.SetParametersAsync%2A> runs the normal lifecycle method without assigning parameters again.
 
-As you can see in the preceding code, overriding <xref:Microsoft.AspNetCore.Components.ComponentBase.SetParametersAsync%2A> 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 <xref:Microsoft.AspNetCore.Components.ComponentBase.SetParametersAsync%2A> 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&mdash;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 <xref:Microsoft.AspNetCore.Components.ComponentBase.SetParametersAsync%2A> 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
 

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
 
 * <xref:System.ComponentModel.DataAnnotations?displayProperty=fullName>
 * [Model Binding](xref:mvc/models/model-binding)
+* <xref:blazor/forms/index>
 
 :::moniker-end