做 ASP.NET 项目这些年“首页性能”是我被问得最多、也是坑踩得最多的话题之一。很多产品迭代到后期首页会变成各种功能块堆叠的“重灾区”轮播图、公告、推荐位、统计数字、用户信息全挤在同一屏每次打开都要一锅端地渲染一遍。首页慢不只是体验问题它直接影响用户对整个系统的第一印象也决定了很多业务指标的起点。这篇文章梳理的十条做法都是我在 .NET Framework 和 ASP.NET Core 项目里实际验证过的手段覆盖缓存策略、数据层优化、静态资源、网络传输和基础设施几个维度。每一条我都会说清楚“为什么要这么做”“常见坑在哪”以及我在排查中攒下来的经验。如果你正在优化一个典型的 MVC 或 Razor Pages 项目按这个顺序过一遍通常能很快看到变化。1. 首页性能优化先搞清楚瓶颈到底在哪1.1 首页慢通常是组合式爆发首页性能差往往不是某一个环节造成的。我拆过很多项目发现最典型的几类情况是数据层太重页面每次刷新都要实时查数据库甚至一个接口里藏着 N 次查询静态资源太肥JS、CSS、图片不做任何压缩和合并动辄几十个请求同时发出请求链路太长认证、会话、日志、权限每个环节都往响应时间里加一笔。这三类问题叠加起来用户感知到的就是“转圈好几秒才能看到东西”。如果一上来就盯着某个环节死磕很容易做了半天没效果。正确做法是先量化再对症下药。首页性能优化的本质不是把单个请求的速度做到极致而是把用户从点击到页面可交互的完整链路压缩到合理范围。1.2 先定指标再谈优化没有指标就动手基本等于盲人摸象。我习惯用这几个角度看首页指标含义建议关注点TTFB从发起请求到收到第一个字节的时间反映服务端处理速度目标尽量压到 500ms 内FCP / LCP首屏内容出现、最大内容绘制时间反映浏览器渲染与资源加载速度资源请求数首页加载产生的 HTTP 请求总量请求越多网络往返越重需配合 HTTP/2 与合并策略接口耗时 p95大多数请求的耗时上限平均耗时会掩盖尾延迟关注 p95 更贴近用户真实感受浏览器 DevTools 的 Network 面板就能看 TTFB 和资源加载瀑布图。如果 TTFB 高问题大概率在后端如果 TTFB 低但整页加载还是慢问题大概率在资源和渲染侧。先用这个方式把方向定下来再往下走。1.3 我给首页优化的固定顺序遇到具体项目我基本按照“改动越小、见效越快”的顺序推进先开压缩和静态资源缓存改配置就能完成再做数据层的缓存与异步化然后处理查询量最后才动架构层面的会话与集群配置。这个顺序能帮团队先拿到确定性收益再做需要更多投入的优化避免一上来就重构却迟迟看不到结果。2. 缓存三招让首页从数据库里“解脱”出来2.1 做法一用 ResponseCache 做 HTTP 层缓存ASP.NET Core 自带响应缓存中间件可以把一部分可公开的页面片段或接口响应直接缓存起来。注册方式很简单// Program.cs 或 Startup.ConfigureServices builder.Services.AddResponseCaching(); // Configure 中启用放在 UseRouting 之后、UseEndpoints 之前 app.UseResponseCaching();然后在控制器或最小 API 上打特性[ResponseCache(Duration 60, Location ResponseCacheLocation.Any, VaryByQueryKeys new[] { page })] public async TaskIActionResult Index(int page 1) { return View(await _service.GetHomeDataAsync(page)); }Duration60 表示 60 秒内相同 URL 的请求可以直接命中缓存VaryByQueryKeys 让带不同查询参数的请求分别缓存。这个做法很适合首页中不需要登录、内容更新不频繁的区块比如公告列表、行业资讯、公共数据面板。说几个踩过的坑。第一响应缓存中间件只对 GET 或 HEAD 请求生效而且要求响应里有正确的 Cache-Control 头很多新手会发现配置了却“没反应”先检查响应头。第二不要给依赖登录态的页面加这个缓存否则用户会看到别人的数据。第三如果部署在 IIS 后面HTTP.sys 内核缓存也可能参与工作调试时容易分不清是哪一层缓存生效可以在测试时临时禁用内核缓存来定位问题。2.2 做法二IMemoryCache 缓存高频计算结果首页上很多数据本身不是“查询慢”而是“每次都重新计算太浪费”。比如从多个服务聚合出的汇总数据、需要二次加工的对象列表用内存缓存是最经济的选择。依赖注入后直接使用public class HomeService { private readonly IMemoryCache _cache; public HomeService(IMemoryCache cache) { _cache cache; } public async TaskHomeSummaryDto GetSummaryAsync() { return await _cache.GetOrCreateAsync(home:summary, async entry { entry.SetAbsoluteExpiration(TimeSpan.FromMinutes(5)); entry.SetSlidingExpiration(TimeSpan.FromMinutes(1)); return await LoadSummaryFromDatabaseAsync(); }); } }GetOrCreateAsync 是常用模式缓存没有命中时自动执行委托并写入缓存。我建议绝对过期时间AbsoluteExpiration和滑动过期时间SlidingExpiration组合使用。滑动过期解决“缓存永不过期”的隐患绝对过期兜底防止缓存项在活跃状态下无限期存活。关于内存缓存有两点需要强调。它默认是进程内缓存部署多个实例时各实例数据独立如果业务对一致性要求高光靠 IMemoryCache 不够。另外要注意“缓存穿透”场景某个 key 在高并发下同时失效会有大批请求同时打到数据库可以给 IMemoryCache 设置合理的并发锁或者结合分布锁来保护。2.3 做法三Redis 分布式缓存解决多实例一致性负载均衡环境里多台实例共用一份分布式缓存往往是必要的。ASP.NET Core 官方封装了 Redis 实现builder.Services.AddStackExchangeRedisCache(options { options.Configuration your-redis-server:6379; options.InstanceName home:; });之后用 IDistributedCache 操作数据。Redis 做分布式缓存的好处是数据一致性有保障天然适合多实例共享坏处是会引入一次网络往返和序列化开销。我通常在“数据量较大且一定要跨实例共享”时才使用比如会话数据、用户状态、跨服务器共享的热点配置。组合玩法是“二级缓存”实例本地先用 IMemoryCache 做一层短时间缓存Redis 做第二层兜底。读数据时先查本地没命中再查 Redis再回源数据库。这样既减少了 Redis 压力也提高了读取速度。缺点是写操作要同时更新或清理两层缓存逻辑复杂度会上升适合首页这类读量远大于写量的场景。2.4 缓存键和失效设计才是真正的分水岭很多项目引入缓存后反而出了问题大多栽在键设计和失效策略上。缓存键不是随手拼接的字符串我习惯用“业务域:模块:版本:参数”的格式比如 home:products:v1:category-12版本号可以在数据格式发生变化时快速淘汰旧缓存。失效策略上被动过期缓存到期自然失效是最简单的但会出现“缓存刚过期、流量高峰瞬间打垮数据库”的时刻。更稳的方案是“主动失效 被动兜底”数据变更时主动删除对应缓存键同时保留一个合理的过期时间作为兜底。比如后台修改了公告立即调用 RemoveAsync 清理首页公告缓存用户不需要等缓存自然过期。还要提醒一个容易踩的坑不要把 null 值也缓存在内。如果数据库查询结果为空而缓存把这个空结果存下来后续请求全都会读到空数据更难排查。我一般对空结果直接返回不写入缓存。3. 数据层三件事别让首页每次请求都“搬仓库”3.1 做法四全链路异步别占着线程池ASP.NET Core 的线程池规模是有限的同步阻塞 I/O 会让线程长时间空等数据库或外部 API 返回导致线程池耗尽新请求被挂起。解决办法就是让整条链路保持 async。控制器和数据库调用要完整地 async/awaitpublic async TaskIActionResult Index() { var items await _db.Products .AsNoTracking() .Where(p p.IsActive) .Take(20) .ToListAsync(); return View(items); }注意不要混合阻塞调用比如在 async 方法里用 .Result 或 .Wait()。这个反模式会让异步方法退化成同步阻塞还容易引发死锁尤其在还有同步上下文的环境里。我也见过很多人把“async 方法”写上但里层调用的还是同步 API这等于白写。这里想说明一个容易被误解的点异步不会让单个请求变得更快它提升的是系统吞吐量。同一台服务器线程池能同时处理的请求多了高峰期首页的响应时间就不会因为线程饥饿而暴涨。对首页这种高并发入口来说这个价值非常大。3.2 做法五把首页的数据库请求量砍到最少首页慢最容易查出来的典型原因是页面只有几个模块代码却发了几十条 SQL。一个点击动作背后拖着几十次数据库往返再小的查询积累起来也会质变。我处理首页查询的思路是先把页面模块列出来区分“服务端必须渲染的数据”和“客户端可后加载的数据”。服务端必须渲染的比如用户身份信息、核心内容列表保留在主请求里那些统计数字、推荐位、运营位完全可以先给占位结构页面加载后再用异步接口填充。第二个手段是合并查询。在同一个聚合场景里尽量一次把关联数据取出来。EF Core 的投影很适合var vm await _db.Users .Where(u u.Id userId) .Select(u new HomeViewModel { UserName u.Name, RecentOrders u.Orders .Where(o o.Status OrderStatus.Paid) .OrderByDescending(o o.CreatedAt) .Take(5) .Select(o new OrderBriefDto { Id o.Id, Amount o.Amount }) .ToList() }) .FirstOrDefaultAsync();一次数据库往返拿到页面需要的数据比多次小查询快得多。但我也要说另一面不要为了合并强行把低频模块绑进主查询。首页某个模块如果只有少数用户会看到或者展示优先级不高就把它拆成异步加载别拖累所有人的首屏。3.3 做法六EF Core 查询与索引优化EF Core 本身只是工具真正的性能瓶颈经常在生成的 SQL 和数据库索引上。我常用的优化动作有三个只读查询加 AsNoTracking、重复执行的查询用预编译查询、给常用筛选字段建索引。AsNoTracking 很好理解告诉 EF 不用做变更追踪省掉大量内存和计算开销。预编译查询有点门槛但收益稳定private static readonly FuncAppDbContext, int, TaskHomeData GetHomeData EF.CompileAsyncQuery((AppDbContext db, int id) db.Users .Where(u u.Id id) .Select(u new HomeData { UserName u.Name }) .FirstOrDefault());编译一次查询后续执行直接复用表达式树省去每次查询的编译开销。适合首页中高频执行的固定查询。但要注意 CompileAsyncQuery 内部不能用额外服务或非常规调用限于纯 EF 查询表达式。索引方面我的习惯是对首页查询的 WHERE 条件字段、JOIN 字段、排序字段综合建索引并且优先用包含索引覆盖索引减少回表。如果发现某个查询执行计划里还有隐式类型转换比如字符串列和整型参数比较即便有索引也可能失效。最直观的办法是把 EF Core 输出的 SQL 拿到 SQL Server Management Studio 里跑一下执行计划看实际扫描行数和连接类型。3.4 关于 N1 和被忽视的“重复查询”N1 经典问题是先查列表再循环里逐条查关联。EF Core 里表现为导航属性延迟加载页面上一循环就触发大量 SQL。解决思路有两种如果需要完整关联数据用 Include 预加载如果只需要部分字段用投影 Select 让 EF 生成 JOIN。前者直观但可能带出太多列后者更精简我更推荐投影方案。排查时可以开启 EF 日志观察一次首页请求实际生成了几条 SQLbuilder.Logging.AddFilter(Microsoft.EntityFrameworkCore.Database.Command, LogLevel.Information);我遇到过很多次“ SQL 都很简单但数量爆炸”的情况日志一开立见分晓。每次都提醒团队首页这种入口级的请求查询瘦身比单个查询微调收益大得多。4. 资源与网络优化四招剩下的性能藏在浏览器到服务器的路上4.1 做法七静态资源上 CDN 和独立域名首页里占比最大的网络开销往往是 JS、CSS、图片这些静态资源。把这些资源放到 CDN 并采用独立子域名或者独立域名效果非常明显。核心原因有三个第一不走业务域就不会带上业务 Cookie减少了请求头和网络体积第二浏览器对同一域名有并发连接限制独立域名可以分散请求让资源加载更并行第三CDN 节点离用户更近静态资源的传输时间大幅缩短。资源地址直接改成 CDN 域名即可比如script srchttps://cdn.example.com/js/site.min.js?v1.0.3/script这里版本号很重要文件内容一改版本号必须变。否则浏览器和 CDN 很可能继续用旧缓存线上出现“改了代码没生效”的诡异现象。4.2 做法八启用 Brotli 和 Gzip 压缩很多项目上线后忘了开启压缩HTML、JS、CSS 都以原始大小传输首屏多出几倍的流量。ASP.NET Core 启用压缩非常简单builder.Services.AddResponseCompression(options { options.EnableForHttps true; options.Providers.AddBrotliCompressionProvider(); options.Providers.AddGzipCompressionProvider(); options.MimeTypes new[] { text/html, text/css, application/javascript, application/json, image/svgxml }; }); app.UseResponseCompression();Brotli 的压缩率通常比 Gzip 更高现代浏览器都已支持按上面的顺序把它放在首位即可。压缩范围建议只针对文本类 MIME图片JPEG/PNG/WebP本身已经压缩过再压一遍只会浪费 CPU。同时要注意压缩会消耗 CPU所以像 API 返回的 JSON 数据如果很大且调用频繁也要结合缓存来平衡。4.3 做法九资源打包与懒加载传统“少请求数”的思路是合并 JS/CSS。ASP.NET Core 里可以用 WebOptimizer 这类工具builder.Services.AddWebOptimizer(options { options.AddCssBundle(/css/bundle.min.css, /css/base.css, /css/home.css); options.AddJavaScriptBundle(/js/bundle.min.js, /js/util.js, /js/home.js); }); app.UseWebOptimizer();这样页面只需引用一个合并后的文件。不过随着 HTTP/2 普及合并的收益受限了因为多路复用使多个请求可以共用一个连接。所以我现在的判断标准是HTTP/1.1 环境多合并HTTP/2 环境更要关注“每个资源是否足够小、是否被合理缓存”。懒加载更关键。首屏只需要显示视觉核心区域和必要交互图片这种非首屏内容应该加上 loadinglazy让浏览器滚动到附近时再加载。我见过太多首页首屏加载了十几张轮播大图用户根本来不及看到白白浪费带宽和时间。4.4 做法十HTTP/2 与浏览器缓存头HTTP/2 在 Kestrel 下默认启用只要部署环境支持就能直接受益。多路复用让首页不用再为了并发限制强行合并资源连接握手次数也少了。如果部署在 IIS 后面需要确认 Windows Server 和站点配置支持 HTTP/2一般是操作系统层面的事。浏览器缓存头这块推荐给静态资源设置一个较长周期的 Cache-Control同时配合文件名版本号更新。可以在静态文件中间件里统一配置app.UseStaticFiles(new StaticFileOptions { OnPrepareResponse ctx { ctx.Context.Response.GetTypedHeaders().CacheControl new CacheControlHeaderValue { MaxAge TimeSpan.FromDays(30), Public true }; } });这样一来首次访问后会缓存 30 天下次访问不再向服务器发资源请求。版本号一变URL 就变又会触发新缓存。这里有个常见误区是只用查询字符串版本号部分代理和 CDN 会把查询字符串相同的资源视为相同所以更稳妥的方式是把版本号放进文件名比如 site-1.0.3.min.js。5. 容易被忽略的基础设施隐患会话状态、负载均衡与监控5.1 会话状态也可能拖慢首页默认情况下 ASP.NET Core 的会话是用内存存、Cookie 识别。首页并发一大每一次请求都可能读写会话数据锁定和序列化都是成本。更严重的是多实例部署后内存会话无法共享用户轮流访问不同实例就会频繁丢会话。我的建议分两步。第一步重新审视首页到底需不需要会话数据很多公共首页对匿名用户是完全不需要会话的请求里却依然携带会话 Cookie白白增加请求体量和存储压力。第二步如果真的需要会话共享改用 Redis 或 SQL Server 存储而不是依赖单机内存。会话存储的选择不直接缩短响应时间但能避免全站性的“随机掉线”问题。5.2 负载均衡场景下的缓存一致性问题多实例部署之后IMemoryCache 和本地响应缓存会变得“各为其主”同一页面在不同实例上可能返回不一样的内容。解决方向有两个要么接受弱一致把缓存过期时间压短要么把关键数据切到 Redis 分布式缓存。我在实际项目中一般把“用户无感知的数据”放本地缓存把“业务要求强一致的数据”放分布式缓存找到成本和效果的平衡点。另外负载均衡的健康检查地址不要做成重页面。很多团队把首页本身当成健康检查地址导致监测系统每几秒就真实访问一次首页既产生无效请求又会干扰性能数据。健康检查应单独用轻量端点。5.3 首页性能监控与排查清单优化做完不是终点得让性能持续可见。我会用 Application Insights 或类似 APM 工具给首页关键路径加跟踪记录 TTFB、数据库耗时、依赖调用次数。部署后用 dotnet-counters 看一眼线程池状态如果线程数持续上涨就去查是不是有同步阻塞调用用 dotnet-trace 抓热路径定位耗时最高的函数。日常排查时我习惯用一张检查表按可能性排序现象常见原因优先处理TTFB 高数据库查询多、N1、缺缓存先查日志看 SQL 数量加索引和缓存首页内容慢但接口快静态资源未压缩、未缓存开启压缩、配置 Cache-Control、上 CDN并发一高就慢线程池耗尽、会话锁、同步阻塞 I/O异步化、检查线程池指标多实例表现不一致内存缓存/内存会话切到 Redis页面资源请求特多没合并、没懒加载、HTTP/1.1合并资源、懒加载、开启 HTTP/2这套清单能覆盖大多数首页缓慢的根因。搭配持续监控你就能保证这次优化不是“一次性止血”而是长期稳定的性能水位。我自己在实际项目里最常用的顺序是先做“性价比最高”的改动压缩、静态资源缓存头、浏览器缓存这三步配置级改动就能明显改善加载体验然后再做数据层优化最后才是架构级的会话和分布式改造。首页性能往往不是一锤子买卖它会随着业务增长不断出现新瓶颈。关键是一边优化一边把判断依据沉淀下来不要凭感觉猜。给团队成员留一份清晰的问题定位路径比单纯把代码调快更有价值。