HTML表单提交不阻塞加载但会中断页面生命周期，触发全新跳转；AJAX则异步执行且可捕获响应。提交后旧DOM销毁、资源重载、监控失效，优化关键在服务端响应类型与压缩策略。
HTML 表单提交本身不会阻塞页面加载，但跳转行为会中断当前页面生命周期，实际效果等同于一次全新页面加载。 这和 AJAX 提交有本质区别——它不走 fetch/XHR 流程，也不受同源策略拦截，但代价是用户感知上的“白屏”和资源重载。
表单提交触发的是页面跳转，不是异步请求
当你点击 或调用 form.submit()，浏览器会立即终止当前页面的渲染与脚本执行，向 action 地址发起请求，并等待响应。如果响应是 HTML，就解析渲染新页面；如果是 JSON 或纯文本，就直接显示原始内容（无法被 JS 捕获）。
- 没有
DOMContentLoaded或load事件延续性，旧页面 DOM 瞬间销毁 - 所有未 flush 的 console.log、定时器、监听器全部失效
- 即使
action是同域静态 HTML，也需重新下载 CSS/JS/图片，无法复用缓存中的运行时状态
target="_blank" 不缓解性能问题，反而增加开销
用 target="_blank" 确实避免了当前页跳转，但新开窗口仍会完整加载目标资源，且带来额外负担：
- 每个新窗口都独立初始化渲染进程、JS 引擎实例、网络连接池
- 若目标页体积大（比如含大量第三方脚本），多个
target="_blank"可能拖慢主页面响应（尤其低端设备） -
rel="noopener noreferrer"是安全必需，但不改善加载性能 - 移动端 Safari 对多标签页内存限制更严，容易触发页面冻结或丢帧
真正影响加载体验的是响应内容类型与服务端处理
表单提交的“快慢感”，80% 取决于后端返回什么，而非前端怎么发：
- 返回轻量 HTML（如仅含
提交成功
- 返回重定向（
302 Location: /success）：多一次 HTTP 往返，TTFB 翻倍风险高 - 返回 JSON + 前端 JS 渲染：必须改用
fetch，已不属于原生表单行为 - 服务端未启用 GZIP/Brotli、未设置
Cache-Control：静态资源重复下载
最容易被忽略的一点：表单提交后的页面跳转，会让所有前端性能监控（如 LCP、CLS）完全失效——你测的不是“提交性能”，而是“新页面的首次加载性能”。如果业务允许，用 fetch + event.preventDefault() 替代原生提交，才能真正把控制权拿回来。
前端入门到VUE实战笔记：立即使用
在学习笔记中，你将探索 前端 的入门与实战技巧！
