CSS 和 jQuery 选择器速度

发布于 2024-09-30 17:32:14 字数 587 浏览 2 评论 0原文

在 jQuery 中,每当我遇到这样的事情时:

$("div#MyDiv").....

我通常会对开发人员说:“别费心把 div 放在 #MyDiv 前面,ID 选择器是最快的。 ”即,

$("#MyDiv")....

这是因为后者将直接挂钩到 document.getElementById 而不必首先扫描 DOM 中的所有

元素。

我的问题是,同样的规则也适用于 CSS 选择器吗?即,而不是:

div#MyDiv
{
}

简单地更快吗?

#MyDiv
{
}

:(我意识到CSS选择器无论如何都快得令人难以置信,所以实际上两者都不会产生显着的差异。)

非常感谢

编辑

任何链接或引用都可能对于本次讨论的目的是有用的。谢谢 :-)

In jQuery whenever I encounter something like this:

$("div#MyDiv").....

I generally say to the developer: "Don't bother putting the div in front of #MyDiv, ID selectors are the fastest." I.e.

$("#MyDiv")....

This is because the latter will hook directly into document.getElementById rather than having to scan the DOM for all <div> elements first.

My question is, do the same rules apply to CSS selectors? I.e. rather than:

div#MyDiv
{
}

Is it faster to have simply?:

#MyDiv
{
}

(I realise that CSS selectors are incredibly fast anyway, so in reality neither would make a significant difference.)

Many Thanks

EDIT

Any links, or references might be useful for the purposes of this discussion. Thanks :-)

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(3

瘫痪情歌 2024-10-07 17:32:14

我想说的是,它极不可能对现实世界产生任何影响。从理论上讲,是的,需要的检查少了一次(因为根据 规范)。但它对现实世界的浏览器应用程序产生真正影响的可能性有多大?接近于零。

也就是说,当我在 HTML 应用程序中看到诸如 div#foo 之类的内容时,我总是感到畏缩。 HTML 只有一个 ID 类型属性 (id),因此无需进一步限定。你让 CSS 选择器引擎(浏览器的或 jQuery 的)更加努力地理解你的意思,你让选择器变得脆弱(如果 div 变成 footer,对于实例)等,当然,您确实让自己对一个愚蠢的选择器实现保持开放,它无法识别它可以通过ID查找某些内容,然后然后检查以查看如果它是一个 div ,那么就遍历所有的 div 。 (这样的实现是否存在?可能,你永远不知道。)除非有一些边缘情况,它总是让我觉得有人不太知道他们在做什么。

所以对我来说,速度不是主要论点。无意义是。 ;-)

I'd say that it's extremely unlikely that it makes any real-world difference. In theory, yes, there's one fewer check required (because div#foo really does need to be a div to match the selector, according to the spec). But the odds of it making any real difference in a real-world browser app? Near zero.

That said, I always cringe when I see things like div#foo in HTML applications. HTML has only one ID-type attribute (id), so there's no need for the further qualification. You make the CSS selector engine (either the browser's or jQuery's) work harder to figure out what you mean, you make the selector fragile (if the div becomes a footer, for instance), etc., and of course you do leave yourself open to a stoopid selector implementation that fails to recognize that it can look something up by ID and then check to see if it's a div and so goes looking through all the divs. (Does such an implementation exist? Possibly, you never know.) Barring some edge cases, it always makes me think someone doesn't quite know what they're doing.

So for me, speed isn't the main argument. Pointlessness is. ;-)

╄→承喏 2024-10-07 17:32:14

是的,由于解析速度更快,并且浏览器不必检查元素是否也是

。 (对于一些规则,用户无法察觉速度差异)

yes this is faster because of parsing speed and because browser must not check if element is also a <div>. (for a few rules speed difference is not perceivable by the user)

七颜 2024-10-07 17:32:14

根据 这篇 Mozilla 文章,它确实有所不同,尽管一分钟。 (请注意,虽然该文章讨论了 XUL 用户界面的样式,但 Gecko 布局引擎都用于呈现 Firefox 的用户界面及其加载的网页。)

ID 旨在应用于无论如何,无论是否重要,尝试匹配标签名称所造成的性能损失都是完全不必要的。更不用说它还会在样式表中浪费一些字节。

According to this Mozilla article, it does make a difference, although a minute one. (Note that while that article discusses styling XUL user interfaces, the Gecko layout engine is used both for rendering Firefox's user interface and the Web pages it loads.)

The ID is meant to apply to a single element in the DOM anyway, so the performance hit incurred by attempting to match the tag name is completely unnecessary, whether significant or not. Not to mention it would waste a few bytes in your stylesheet as well.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文