现实世界CSS与CSS-IN-JS性能比较

CSS-In-JS在前端工具中取得了一个坚实的地方，似乎这一趋势将在不久的将来继续。特别是在反应世界中。例如，在2020年参加CSS调查状态的11492人中只有14.3％的人没有听到风格的组件（一个占主导地位的CSS-In-JS图书馆）。超过40％的参与者使用了图书馆。

我希望看到CSS-In-JS库的深入性能比较，如样式组件和很长一段时间的旧CSS。可悲的是，我无法在真实世界项目中找到比较，而不是一些简单的测试场景。所以我决定自己这样做。我已将Real-World应用程序从样式组件迁移到Linaria，这将在构建时提取CSS。没有用户机器上的样式的运行时生成样式。

在我们开始之前短暂的通知。我不是CSS-In-JS的仇恨。我承认他们有很棒的DX，并且从反应中遗传的组成模型很棒。它可以为开发人员提供一些良好的优势，如Josh W. Comeau亮点在他的文章中称为风格组件的快乐道路。我还在我工作的几个项目或项目中使用风格组件。但我想知道，来自用户的角度来看，这个伟大的DX的价格是多少。

如果您关注您网站的负载性能，请不要使用运行时CSS-INS。简单地少JS =更快的网站。我们可以做些什么。但如果你想看到一些数字，继续阅读。

我用于测试的应用程序是一个漂亮的标准React应用程序。使用CREATE RECK APP项目引导，使用REDUX并使用样式组件（V5）进行样式。它是一个相当大的应用程序，具有许多屏幕，可定制的仪表板，客户主题等。由于它是用CRA构建的，它没有服务器端渲染，因此所有内容都在客户端呈现（因为它是B2B应用程序，这不是一个要求）。

我拍了这个应用程序并用Linaria替换了风格的组件，似乎有一个类似的API。我以为转换很容易。事实证明，它并不那么容易。我花了两个月了迁移它，即使那么，我也只迁移了几页，而不是整个应用程序。我想这就是为什么没有比较这样的比较。替换样式库是唯一的更改。其他一切都保持不变。

我已经使用Chrome Dev工具在两个最常用的页面上运行多个测试。我始终运行三次测试，而呈现的数字是那些3运行的平均值。对于所有测试，我已经将CPU限制为4倍，网络限制为慢速3G。我使用了一个单独的镀铬型材，用于在没有任何扩展的情况下进行性能测试。

我们将从网络开始。 CSS-In-JS的一个优点是没有未使用的样式，对右？好吧，不是完全的。虽然只有页面上使用的时尚，但您仍可能下载不必要的样式。但不是在单独的CSS文件中拥有它们，而是将它们放在JS捆绑中。

以下是使用样式组件和Linaria的相同主页构建的数据比较。斜杠尺寸之前的大小尺寸，未压缩大小在它之后。

即使我们的CSS有效载荷增加了很多，我们仍然在测试用例中仍在下载更少的数据（但在这种情况下，差异几乎疏忽）。但更重要的是，Linaria的CSS和JS的总和仍然小于样式组件中的JS本身的大小。

如果我们比较覆盖范围，那么与风格组件的6KB相比，我们为Linaria（约55kb左右）获得了大量未使用的CSS（此CSS来自NPM包，而不是来自风格组件本身）。与样式组件相比，Linaria的未使用JS的大小为20kb。但未使用的资产的整体规模在Linaria更大。这是外部CSS的权衡之一。

如果我们谈论表现，那将是一个耻辱，不要使用灯塔。您可以在下面的图表中看到比较（平均从3个LI运行）。除了Web Vitals之外，我还包括主题工作（解析，编译和执行资产的时间，这是JS的最大部分，但它涵盖了布局和样式计算，绘画等）和JS执行时间。由于它接近零，因此我省略了累积布局偏移，并且在Linaria和风格的组件几乎没有区别。

如您所见，Linaria在大多数Web Vitals（在CLS中丢失）更好。有时是大幅度的。例如，LCP在主页上的870ms更快，搜索页面上的1.2s。页面不仅呈现正常的CSS是否要快得多，但它也需要更少的资源。阻止执行所有JS所需的时间和时间较小300ms，分别为大约1.3秒。

灯塔可以为您提供对性能的许多见解。但要进入详细信息，Dev Tools中的性能选项卡是最好的选择。在这种情况下，“性能”选项卡确认了灯塔结果。您可以在下面的图表上查看详细信息。

使用样式组件构建屏幕具有更长的长时间的任务。与Linaria Variant相比，这些任务也需要更长时间才能完成。

为了给您另一点看数据，这里是使用样式组件（顶部）和Linaria（底部）加载主页的性能图表的可视比较。

要比较用户互动，而且不仅是页面加载。我已经测量了用于将项目分配成组的拖放活动的性能。结果摘要如下。即使在这种情况下，Linaria甚至在几个类别中击败了运行时CSS-In-JS。

就是这样。正如您可以看到运行时，CSS-In-JS可以对您的网页带来明显的影响。主要用于低端设备和地区，具有较慢的互联网连接或更昂贵的数据。所以也许我们应该更好地思考我们如何使用我们的工具。伟大的开发人员经验不应该以牺牲用户体验为代价。

我相信我们（开发人员）应该更多地考虑我们为项目选择的工具的影响。下次我将开始一个新项目，我不会再使用运行时css-in-js了。我将使用良好的旧CSS或使用一些构建时CSS-IN-JS替代方案来将我的样式从JS捆绑中获取。

我认为建设时间CSS-In-JS Libs将成为CSS生态系统中的下一个大事，因为越来越多的LIB来（最后一个是从Seek中提取）。和大公司也是如此，如Facebook与他们的造型lib）。

感谢您阅读文章。如果您有任何建议或想法如何使文章更好或简单地类似，请随时分享和讨论Twitter。