Chrome禁用JS后页面仍可交互，因disabled属性、:hover伪类和原生表单验证不受影响；禁用JS仅使fetch、addEventListener等脚本逻辑失效，而DOM结构、CSS响应和部分HTML行为照常运行。
Chrome DevTools 里禁用 JavaScript 后页面还能点？
不是所有交互都靠 JS 驱动，Chrome 默认不会禁用 disabled 属性、:hover 伪类或原生表单验证。禁用 JS 只影响脚本逻辑，但 DOM 结构、CSS 响应和部分 HTML 行为照常运行。
- 用
Ctrl+Shift+P（Win/Linux）或Cmd+Shift+P（Mac）打开命令菜单，输入Disable JavaScript并回车，这是最干净的禁用方式；勾选 Settings > Preferences > Debugger > “Disable JavaScript” 是无效的旧路径 - 禁用后仍能触发
submit表单提交（只要没被 JSpreventDefault），但fetch、addEventListener、setTimeout全部失效 - 某些框架（如 Vue 3 的
v-model）在 JS 禁用后会退化为只读输入框，但原生input[type="text"]依然可编辑
Chrome 渲染卡顿，优先查 layout thrashing 还是 forced synchronous layout？
两者是同一类问题的不同叫法，本质都是 JS 频繁读写 DOM 触发强制重排。Chrome Performance 面板里看到黄色长条标记为 Layout，且堆叠密集，基本就是它。
- 典型诱因：循环中反复读取
offsetHeight、getComputedStyle，再立刻修改style；Vue/React 中在mounted或useEffect里做这类操作极易踩坑 - 修复不是“少读几次”，而是批量读 + 批量写：用
getBoundingClientRect()一次读完所有尺寸，用requestAnimationFrame延迟到下一帧再写样式 - Chrome 120+ 对
offsetTop等属性做了轻量缓存，但getComputedStyle仍每次触发重排，别信“只读不写就安全”
chrome://flags 开启 #enable-experimental-web-platform-features 有啥实际用处？
这个 flag 不是“提升性能”，而是提前解锁尚未进入稳定版的标准 API，比如 ResizeObserver 的 box 选项、CSS @container 查询支持、document.hasStorageAccess() 的完整响应逻辑。
- 开启后不会自动加速页面，但能让开发阶段更早验证新特性兼容性；关闭它，
new ResizeObserver(..., { box: 'border-box' })会静默降级为默认行为 - 生产环境千万别依赖它——flag 关闭后相关代码直接报
TypeError: Failed to construct 'ResizeObserver'或忽略参数 - 替代方案更稳：用
if ('resizeObserverOptions' in document)检测能力，而非检查 Chrome 版本号
为什么 console.time() 在 Chrome 里不准，尤其测首屏？
因为 console.time() 只记录 JS 执行时间，完全不包含网络下载、HTML 解析、CSSOM 构建、布局计算这些关键耗时。测首屏必须用 performance.getEntriesByType('navigation') 或 LCP API。
立即学习“前端免费学习笔记（深入）”；
-
console.time('render')放在DOMContentLoaded里，测出来的是 JS 初始化时间，不是用户看到内容的时间 - 真实首屏延迟要看
performance.getEntriesByName('first-contentful-paint')[0].startTime，这个值受字体加载、图片解码、GPU 渲染队列影响，JS 计时器捕获不到 - DevTools 的 Network 面板里勾选 “Disable cache” 再刷新，比任何 console 计时都接近真实弱网场景
#smooth-scrolling 或 #enable-gpu-rasterization，结果 LCP 毫无改善——因为瓶颈压根不在渲染管线，而在第三方脚本阻塞了 HTML 解析。 
