如果您所说的“效率”是指它如何影响页面的加载时间，那么您应该坚持使用类和 ID 而不是标签名称。 Google 有一个 best practices page 用于编写您可能会感兴趣的快速 CSS。他们建议的要点是减少浏览器必须排序的元素数量。
页面上最相关的一点是，“更喜欢类和 ID 选择器而不是标签选择器。” 稍后我们将看到，这实际上只会在这些类时提高效率和 ID 选择器会减少匹配元素的数量。
不过，在我开始讨论之前，让我们从该页面的建议总和得出其合乎逻辑的结论。我们应该发现编写 CSS 最有效的方法是为页面上的所有内容应用 ID，并且只使用 ID 选择器。但是你应该这样做吗？应该不会吧。
原因是在编写 CSS 时还有其他因素需要考虑。以下是一些：
- 无论您的选择器效率多么低，您页面上的其他内容可能比处理 CSS 花费的时间要长得多。如果您将时间花在优化上，最好花在其他地方。
- 您希望保留您的网页
semantic，这绝对不意味着要为您网页上的所有内容提供 ID。
- 维持这样的结构会很痛苦
- 这将是不美观的 HTML
我从这一切中得出的结论是，只要您不牺牲太多上述几点，尤其是第一点和第二点，就遵循效率的最佳实践。
对于您的具体示例，最简单的答案是底部选择器如果减少匹配项的数量会更有效。
逐一浏览：
header 与 #header
如果您的页面上有多个标题元素，则 ID 总是更有效。如果只有一个标题，那么它们应该同样快速。
header nav 与 #header .nav
Google 最佳实践页面告诉我们，后代选择器是 CSS 中效率最低的选择器。
这是因为 CSS 从右到左读取。一旦它找到最右边的后代，它需要通过 DOM 树返回以确定其父代是否匹配。它必须为每场比赛都这样做。
选择器在匹配失败时会停止解释。因此，如果它正在寻找 nav 并在 ul 上运行，它就不会在 DOM 树上寻找该 ul 的标题父级。这不应该让我们太惊讶，但我只是想为了完整起见我会提到它。
这些点共同使我们得出结论，在使用后代选择器时，您希望选择器的最右边部分尽可能具体。这样可以最大限度地增加不匹配的元素数量，从而最大限度地减少慢速 DOM 树搜索的次数。
回到您示例中的两个选择器：如果您有多个带有多个导航的标题，但其中只有少数具有.nav 类，那么右侧会更有效。
如果您只有一个 ID 为 header 的 header 和一个 ID 为 nav 的 nav，那么它们将同样快速。
header nav ul li 与 #header .nav .menu
之前的相同规则适用于这种情况。然而，在这种情况下，由于这里有两个后代选择器，而不仅仅是一个，这一事实放大了速度上的差异。
如果您的页面有多个无序列表，那么您可能希望使用这两个选择器中的第二个，以防止页面上的每个 li 匹配这个（更）复杂的选择器。