class 选择器为什么比 attribute 选择器快?帮你翻开blink源码。

话不多说,让我们从大家常用的 Node.querySelectorAll 的 blink 源码入手,逐步分析这个问题:

我们调用它时 Node.querySelectorAll 做了哪些事?

翻了下源码,这个函数似乎很简单,其中主要逻辑位于Execute函数中:

Execute函数中,我们可以看到两个逻辑:

  1. 如果 use_slow_scan_ 为true,则会进入到 ExecuteSlow,走慢速查询。
  2. 如果 use_slow_scan_ 为false,如果是class选择器,则会执行 CollectElementsByClassName函数

看起来我们似乎找到了答案?再深究一下。

看起来我们似乎找到了答案,class 选择器为什么比 attribute 选择器快?因为blink中为class选择器做了特殊处理。

而做了啥处理呢?我们来看看函数逻辑,看起来似乎很简单,就是只检查后代所有元素中有class的元素。

而ExecuteSlow慢在哪呢?看代码我们知道,因为他是一个通用的函数,他会处理遍历检查所有后代元素,用所有css规则去做判断,自然会慢于只判断class的CollectElementsByClassName函数。

那么 use_slow_scan_是谁设置的、以什么逻辑设置的呢?

其实看到源码就很简单,当且仅当一个选择器时。

总结:

当且仅当一个选择器时,那么class会比attribute快,因为class选择器心无旁骛只找class,而attribute走的是通用规则处理的逻辑,会有更多逻辑。


最后,祝好。

我是尘码,有其他想从chrome源码找答案的问题,欢迎评论。

也欢迎来我 Fanbook ( 一个国内类似discord的免费平台 ) 来找我吹水聊天 ,频道邀请码如下:

in.fanbook.cn/CIe6NFQD

相关推荐
kyriewen1120 小时前
你点的“刷新”是假刷新?前端路由的瞒天过海术
开发语言·前端·javascript·ecmascript·html5
skywalk81631 天前
Kotti Next的tinyfrontend前端模仿Kotti 首页布局还是不太好看,感觉比Kotti差一点
前端
RopenYuan1 天前
FastAPI -API Router的应用
前端·网络·python
秋夜无霜1 天前
一场因chrome浏览器调试模式network中设置了offline模式导致的页面调试就会导致数据无法正常加载
chrome
走粥1 天前
clsx和twMerge解决CSS类名冲突问题
前端·css
Purgatory0011 天前
layui select重新渲染
前端·layui
weixin199701080161 天前
《中国供应商商品详情页前端性能优化实战》
前端·性能优化
刘~浪地球1 天前
Redis 从入门到精通(六):列表操作详解
数据库·chrome·redis