用 document.getElementById 替代 document.querySelector 通常不能直接优化首屏性能，仅在目标元素有稳定id、原用querySelector查该id且处于首屏关键路径时，才有微小执行效率提升；真正影响首屏的是减少阻塞资源、SSR/SSG及资源预加载。
用 document.getElementById 替代 document.querySelector 通常**不能直接优化首屏性能**，但能在特定场景下带来微小的执行效率提升——前提是原本用 querySelector 去查一个本可用 id 精准定位的元素。关键不在“替换”本身，而在于**是否选对了最轻量、最直接的 API**。
为什么 getElementById 更快？
getElementById 是浏览器原生最快的 DOM 查找方法之一，原因很直接：
- 它只按
id属性查找，且要求id全局唯一，浏览器内部做了高度优化（例如哈希表索引） - 无需解析 CSS 选择器字符串，不涉及样式匹配、层级遍历或伪类判断
- 返回值一定是单个元素（或
null），无数组封装开销
哪些情况适合换成 getElementById？
仅当满足以下全部条件时，替换才有意义：
- 目标元素有合法、稳定的
id属性（如<div id="header">） - 你原本写的
querySelector('#header')或querySelector('main .hero > h1')中，其实只需取那个id元素 - 该查找发生在首屏关键路径中（例如 SSR 后的 hydration、首屏 JS 初始化逻辑）
❌ 错误示例：document.querySelector('.nav-item.active') → 无法用 getElementById 替代，因为没 id，也不唯一。
实际替换建议
不是盲目全局替换，而是聚焦高频、首屏必需的查找点：
- 把首屏容器（如
<main id="app">）的获取从querySelector('#app')改为document.getElementById('app') - 在 React/Vue 的 mount 挂载点、或初始化脚本开头，优先使用
getElementById获取根节点 - 避免封装成通用函数（如
$(selector)）再统一调用querySelector，若已知是id，就直写getElementById
别忽略更有效的首屏优化
比起这种微优化，真正影响首屏的是：
- 减少阻塞渲染的 JS/CSS（内联关键 CSS、延迟非关键 JS）
- 服务端渲染（SSR）或静态生成（SSG）提前输出 HTML
- 使用
loading="eager"或资源提示（<link rel="preload">）加速首屏资源加载 - 避免在
DOMContentLoaded前大量操作 DOM（尤其是循环querySelectorAll）
DOM 查找本身耗时通常在纳秒到微秒级，除非单页执行上千次，否则对 LCP、FCP 几乎无感。优先保证结构清晰、ID 合理、查找必要，比强行替换更有价值。
