做网站这行的人大概都有同感：去年评审会上还在讨论要不要上 SSR，今年的会已经没人问这个问题了，争的是边缘节点怎么切、预渲染比例给多少、第三方脚本还能留几个。技术选项变多的同时，判断成本也在往上涨。
将以2026年的这一特殊的时点作为我们对未来发展的新的起点，开启一系列具有里程碑意义的新征程。伴随浏览器的不断迭代，其侧的API的更新节奏也明显加快,而Core Web Vitals的考核口径也已经完成了从1.0版的基本的可用性和性能的两个指标的切换,同时国内对数据的采集和Cookie的使用的检查也比前两年更为的细,对网站的要求也更高了。由此一系列的变化的叠加，直接将我们的建站的技术选型推到了另一条不可逆的路径上。
智能生成介入研发链路，手写模板的比例在下降 🔧
伴随对 AI 的不断的深入地应用，2026年的更大更深的变化就不仅仅是AI的自身的升级了，而是它的接入的位置的变了。伴随技术的不断迭代，我们从曾经的在编辑器中一问一取的开发模式,逐渐将从设计稿到组件的这一步的工作也都被智能的工具们所接管了。伴随设计稿的逐步转化为可编码的设计语言，例如设计的Token的同步、组件的库的批量的产出等一系列的环节在不少的团队中都已经跑通了。
落到实际工作里，影响体现在三处：
页面搭建的时间结构变了，重复的栅格、表单、列表页基本不需要人工写，前端的时间更多花在接口联调和边界处理上
但令人深感意外的是，即使我们把整个架构的重量都都抛给了“框架”去承担，其实组件的契约、各个模块的状态的边界、数据的流向等都还都要由人来人为地来定，这一块的“交代”就还真交不出去
代码评审的重点转移了，从”语法对不对”变成”生成的东西有没有覆盖异常情况”
凭借对比传统的前端开发与现在的AI生成的组件，尤其是对比了AI生成的组件往往都带着冗余的DOM层级和无意义的wrapper容器等问题，我们就能更好的了解当前的AI生成的组件的短板所在.。但不幸的就是这样一来，就会把LCP和CLS的性能都给拖了下去，结构的精简就也不能省了。
比较稳的做法是先把设计规范（Design Token + 组件约定）固化下来，让生成工具基于这套规范产出，而不是让它自由发挥。规范越明确，返工率越低，这个顺序不能反。
INP 接棒之后，性能预算要按交互重新算 ⚡
2026 年谈性能，考核指标已经不是 FID 了。INP（Interaction to Next Paint）进入关键指标序列之后，很多”看起来很快”的站点开始暴露问题。
三条线要记牢：
LCP 控制在 2.5 秒以内
CLS 控制在 0.1 以内
INP 控制在 200 毫秒以内，超过 500 毫秒属于明显不合格
INP 难的地方在于它考核的是整个页面生命周期里的交互延迟，不是首屏那一瞬间。一个首屏秒开、但点开菜单要卡 800 毫秒才响应的站，在 INP 上照样拿不到好成绩。
实测中常见的几个 INP 杀手：
主线程被长任务占住，单个任务超过 50 毫秒就要警惕
事件回调里做了同步重计算或大批量 DOM 操作
状态管理在每次交互时触发全树重渲染
凭借对交互路径的精准对接，既能将埋点的数据收集与A/B测试的脚本有机的融合在一起，又能更好的保证了两者的顺序性，从而为后期的数据的分析提供了更为可靠的依据
对应能做的动作也清楚：用 scheduler.yield() 拆分长任务，把大块计算切成小片；交互反馈先出视觉响应，重计算推到下一帧；用 PerformanceObserver 采集线上真实 INP，实验室数据偏差较大；第三方脚本统一走 async 或 defer。
还有一点值得单独拎出来：BFCache 命中率。不少站点因为保留了 unload 事件监听，或者响应头里带着 Cache-Control: no-store，直接把往返缓存废掉了。移动端体验上这笔损失很明显，检查这两个点改动成本很低，收益立竿见影 📊
渲染位置往边缘靠，混合渲染成了默认选项 🌐
纯客户端渲染的站在 2026 年已经很少见到，纯服务端渲染也在退。主流做法是按路由、按数据敏感度来拆分渲染方式：
凭借对营销页、内容页的前置构建期预渲染并将其与增量的再生成（ISR）完美的对接上直接就能将页面的静态资源直接命中CDN的缓存，从而极大的减轻了后续的静态资源的请求压力
用户中心、订单页：服务端渲染，走边缘节点，不缓存
外壳静态、局部动态：Shell 预渲染 + 局部注水，或者 Islands 架构只对交互组件注水
借助实时的数据渲染，我们可以先将页面的“骨架”就先行生成，待后续的所有数据都渲染完毕后，再将各个部分的内容都填充进去，从而大大提高了页面的渲染速度为用户带来了更好的浏览体验
React Server Components、Partial Prerendering、Islands 架构来自不同框架，思路却是一致的：把不需要交互的部分留在服务端，只有真正要响应的那一小块才把 JavaScript 发到浏览器。
这对部署也提出了要求。边缘运行时通常不支持完整的 Node API，文件系统操作、部分原生模块都用不了。选型阶段就要先确认依赖里有没有踩雷的包，否则上线才发现要退回传统 Node 环境，代价不小。
通过对成本的科学的、合理的账算就能体现出项目的另一大实际的经济效益。借助将首屏的JS体积从300KB的高点压到80KB的较低的量级，不仅仅是提升了了页面的加载速度，更重要的还能为低端的安卓机的可交互时间都带来了一定程度的提升。伴随国内移动端的普及，移动端的流量也占到了七八成的比例，这其中大部分的用户的设备的性能都并不宽裕，自然而然的就把减少JS的请求作为最直接的一条优化的路径来考虑了。
第三方脚本和数据合规，从会后排期变成立项就要定 🔒
建站项目里最容易失控的部分，往往不是自己写的代码，而是塞进来的第三方脚本。统计、广告、客服、热力图、A/B 测试、地图、字体……一个企业官网挂十几个外部脚本并不罕见。
问题集中在三个层面：
由此可见，每个第三方的脚本都可能会将主线程的响应时间拖慢几百毫秒，并给用户带来额外的网络请求。但令人匪夷所思的是，外链脚本的存在却使得我们的INP在实测的数据中占了相当的比例。
由于其对系统的安全性最易被外部的脚本所破坏，从而成为供应链的最为省事的攻击入口。基于对2026年的更为务实的做法的探索，我们不难发现将对所有的外部资源都加上SRI（Subresource Integrity）的校验，紧紧的配合严格的CSP的规则，同时对第三方的域名都纳入了白名单的管理，甚至对新增的都一律都要走审批的流程。
合规层面，个人信息保护法落地之后，Cookie 和采集边界比以前清晰得多，需要做到：
非必要 Cookie 在用户同意前不写入
明确告知采集范围，提供可撤回的同意入口
埋点数据做脱敏，设备标识、手机号这类信息不能明文上报
服务端埋点与客户端埋点分开设计，降低对浏览器环境的依赖
一条比较实在的建议：每个季度做一次第三方脚本盘点，把还在用、已经没人看的脚本清掉。多数站点清理完能砍掉三分之一的外链，性能和合规压力同时下降 ✅
与此前相比，最新的版本在登录的方式上也做了不少的调整和优化。伴随时间的推移，2026年Passkey/WebAuthn的支持已基本成熟，主流的浏览器和移动端的系统都已经基本上得到了覆盖，逐步的替代了传统的密码的应用。基于对有条件的项目的推广，既可大大地压掉短信的成本的同时，也可顺带地避开了验证码的接口被刷的风险.。
可访问性和多端一致，从加分项变成验收项 ♿
但其对我们的社会的影响却被我们所低估了许多。伴随对可访问性的逐步的普及和深入，2026年可访问性（A11Y）的范畴早已不再只是简单的“图片有没有alt”之类的浅层的表面性问题，越来越多的项目的验收标准也都将可访问性写进了其中尤其是政务、金融、教育类的站点都将可访问性作为不可或缺的重要的内容之一。
具体要落实的几件事：语义化标签用对，别通篇 div，导航用 nav、主体用 main、辅助信息用 aside；键盘可达，所有交互元素能被 Tab 聚焦，焦点顺序符合视觉顺序，焦点样式不能被 reset 掉；对比度达到 WCAG AA，正文 4.5:1，大字号 3:1；表单错误提示要能被读屏软件读到，不能只给个红色边框；动效尊重 prefers-reduced-motion。
多端一致这块，2026 年有更多原生能力可以替代手写 JS：
容器查询（Container Query） 让组件按所在容器自适应，不用再靠全局断点猜布局
:has() 选择器 支持父级状态判断，”选中子元素改父样式”这类场景纯 CSS 就能解决
View Transitions API 做页面切换动效，代码量比引入动画库少很多
Speculation Rules API 做预取和预渲染，页面跳转几乎无等待
这几个 API 的兼容情况要按项目自身的浏览器分布来判断。国内仍有部分用户在用较老的 Chromium 内核和旧版 iOS，接入前先查占比，做好渐进增强，不支持的环境退回基础体验即可，别硬切。
落到执行层面，建议按这个顺序推进
5 个变化说完，真正动手时比较合理的推进次序是：
补齐线上性能采集，INP、LCP、CLS 要有真实用户数据，没有数据谈优化基本是拍脑袋
做一次外链脚本清点，同步上 CSP 和 SRI，这一步见效最快
通过对渲染的合理梳理，将不需要交互的页面都先通过静态的方式来实现，从而大大减少了对后台的请求和对数据库的访问，从而达到提高了系统的整体性能的目的
固化设计规范，再接智能生成工具，顺序反了会大量返工
可访问性检查进 CI，用 axe-core 这类工具做自动扫描，别等验收时才发现问题
网站建设这件事，2026 年的门槛其实没有变低，只是位置挪了。以前拼的是能不能把页面做出来，现在拼的是能不能在性能、合规、可维护这几条线上同时守住。框架和工具还会继续变，但上面这几条标准短期内不太可能退回去。
早一步按新标准做，后面就少一次重构。