Html 针对浏览器的最优化CSS

作为一名web开发人员，您只需付出一定的努力来优化CSS代码。然而，计算机可以在几乎没有时间的情况下更多地考虑到这一点，从而更好地进行优化问题是：假设哪种CSS代码最优化？（适用于现代浏览器）

考虑到以下图像：

A、B、C和D是DOM对象（比如DIV元素），数字1-17表示属性（如颜色、背景、宽度、高度等）

而所有数字都代表一个唯一的属性。e、 g:

有多种方法可以生成此网站的css代码：

所有自己的ID

#A { 1 2 5 8 9 10 12 }
#B { 1 4 5 11 12 13 14 15 }
#C { 1 2 3 5 7 }
#D { 3 4 5 6 16 17 }

#A { 2 8 9 10 12 }
#B { 4 11 12 13 14 15 }
#C { 2 3 7 }
#D { 3 4 6 16 17 }
.1 { 1 }
.5 { 5 }

#A { 8 9 10 }
#B { 11 13 14 15 }
#C { 7 }
#D { 6 16 17 }
.1 { 1 }
.3 { 3 }
.2 { 2 }
.4 { 4 }
.5 { 5 }
.12 { 12 }

但是，该文件将非常大，属性不共享，并且简单的测试证明渲染速度相当慢。（image1.html，请参阅下面的文件生成脚本）

共享一些共同属性

#A { 1 2 5 8 9 10 12 }
#B { 1 4 5 11 12 13 14 15 }
#C { 1 2 3 5 7 }
#D { 3 4 5 6 16 17 }

#A { 2 8 9 10 12 }
#B { 4 11 12 13 14 15 }
#C { 2 3 7 }
#D { 3 4 6 16 17 }
.1 { 1 }
.5 { 5 }

#A { 8 9 10 }
#B { 11 13 14 15 }
#C { 7 }
#D { 6 16 17 }
.1 { 1 }
.3 { 3 }
.2 { 2 }
.4 { 4 }
.5 { 5 }
.12 { 12 }

文件将更小，渲染速度似乎更快。（见image2.html）

共享所有公共属性

#A { 1 2 5 8 9 10 12 }
#B { 1 4 5 11 12 13 14 15 }
#C { 1 2 3 5 7 }
#D { 3 4 5 6 16 17 }

#A { 2 8 9 10 12 }
#B { 4 11 12 13 14 15 }
#C { 2 3 7 }
#D { 3 4 6 16 17 }
.1 { 1 }
.5 { 5 }

#A { 8 9 10 }
#B { 11 13 14 15 }
#C { 7 }
#D { 6 16 17 }
.1 { 1 }
.3 { 3 }
.2 { 2 }
.4 { 4 }
.5 { 5 }
.12 { 12 }

该文件甚至更小（大多数情况下），而且渲染速度也更快。但是请注意，A、B和C最后都有一个ID，四个类只包含一个属性！（参见image3.html）

下面是三个简单的CSS代码示例。但是，正如您可以想象的那样，当存在更多的DOM对象，并且存在更多的属性重叠时，从理论上讲，您可能会得到一个ID为1、类数为10%的DOM对象

假设哪种CSS代码最优化？（适用于现代浏览器） 是否应该限制每个DOM对象的类数？您是否更喜欢“包含类的单个属性”而不是将其添加到ID中

p、 作为测试，我使用PHP加载了一个图像。然后读取PNG的像素值，并使用CSS和DIV元素创建相同的图片。

---

您可以使用任何PNG图像。。。我曾经考虑过一个挫折，那就是反应能力。让我们以以下代码为例：

HTML:

如何解决CSS代码重叠的问题，或者如果您希望在一行上有所有的方块时，以不同的分辨率或设备使用一个类而不覆盖它？（*无JS）

---

（我希望我理解了你的想法）

你已经用你创建的测试回答了你自己的问题

@torazaburo为您的问题提供了很好的输入

为每个共享属性创建ID和类将加快运行速度。另一方面，创建包含大多数属性的类将加快解析时间。 这两种方法的问题在于，如果将其作为经验法则使用，代码将很快变得不可读，并且维护起来很复杂

这就是你自己的判断和工作风格的体现。 我认为没有必要为DOM中不重复的元素创建单个属性或类的ID或类，因为您将体验到的加载时间增益将是微不足道的

---

因此，请尝试通过解决代码重复问题来确定CSS优化的优先级。这将有效地减少您的总体加载时间，并使您的代码在将来具有可读性和可维护性。

浏览器应该在内部进行任何此类优化，因为它们“编译”CSS。编译器负责优化，因为它知道它的实现细节，并且能够判断哪个最适合它的需要

程序员只能处理编译器无法推断的事情（例如，由于无法解决问题）。否则，编写语义正确的代码是他们最好的选择

这实际上符合WebKit core的贡献者Antti Koivisto在2011年所说的，他花了一些时间优化了CSS选择器匹配：

我的观点是，作者不需要担心优化选择器（从我看来，他们通常不需要），这应该是引擎的工作

引用Nicole Sullivan的via。顺便说一句，这是现代CSS优化的一个很好的来源。David Hyatt在2000年发表的过时文章顶部的注释中引用了这篇文章

---

因此，一些评论者和我分享的对css的关注可能是有道理的。

这与个人品味无关，因为我不是在征求意见，而是基于事实的证据来证明最优化的css代码。现在，这可能确实与其他浏览器略有不同，但肯定会有一些不同agreement@Jeffrey我不明白你的问题：你能够发现“共享所有公共属性”生成的文件最小，是最快的解决方案。然后，您似乎认为“A、B和C最终只有一个ID，并且4个类只包含一个属性！”是这个解决方案的一个缺点。这对我来说是件好事，不是坏事。。为什么你想说这应该是个问题？定义“优化”。最小代码？最快的解析时间？最容易写？最容易维护？在运行时禁食申请？所有优化问题的一般规则是，首先优化以获得清晰性和正确性。然后，如果您发现您在某个特定领域存在性能问题，您可以对其进行优化。除了在有数千个元素和极其复杂的规则的大型网站中，我很少看到CSS是优化重点的情况。所以我不认为这是一个重要的问题，除非这是一个学术性的练习。所以你想优先考虑的是解析时间，而不是在运行时应用规则的时间？一个简单的近似方法是，解析时间在长度上是线性的，这意味着任何压缩/因子/组合规则最好的方法都将“获胜”。然而，这种方法在运行时可能会比较慢。你