CSS 微优化

发布于 2024-08-07 22:13:43 字数 208 浏览 2 评论 0原文

我正在考虑对一个巨大的 CSS 样式表进行微优化,并且有几个与之相关的问题:

  1. 小写字母比大写字母更能减少文件大小吗?
  2. 是背景位置:右(5 个字符);小于背景位置:0 100%; (6 个字符,包括空格)?

还有其他什么可以帮助减小文件大小吗? (当然,除了合并 CSS 选择器、属性等,我还必须手动完成)

谢谢

I'm considering micro-optimization of a huge CSS stylesheet and have a couple questions related to that:

  1. Is lowercase better than uppercase for reducing file size?
  2. Is background-position:right (5 chars); smaller than background-position:0 100%; (6 chars incl whitespace)?

Is there anything else that might help reduce file size? (Besides merging CSS selectors, properties etc ofcourse, that I'll have to do manually)

Thanks

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

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

发布评论

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

评论(3

恍梦境° 2024-08-14 22:13:43

您最好为压缩后的 css 提供服务,而不是担心类似的事情。

You'd be much better serving the css gzipped, rather than worrying about things like that.

笨死的猪 2024-08-14 22:13:43
  1. 字符大小写并不重要,字节数没有区别。
  2. 这取决于浏览器:

第一个语句短了一个字节,但它也有不同的含义。

一般来说,文件大小并不是影响速度计算的唯一因素。它还取决于浏览器解释它的难度。因此,任何过于聪明的 CSS 构造都可能会从总大小中挤出一些字节,但解析过程本身可能需要更长的时间。

回到您的示例:第二条语句可能会慢一些,不仅仅是因为额外的空间,而且该值由两个标记组成,并且根据背景的内部表示,浏览器可能必须执行一些操作单位换算。另一方面,关键字查找也可能需要更多时间,因此它确实特定于特定的浏览器实现。任何增益很可能都在纳秒范围内,您不应该为这种优化而烦恼,因为它很可能不会有回报。但如果你真的想这样做,你必须分析,即测量加载时间。

一般来说,删除所有注释和所有不必要的空格就足够了,但永远不要在该“缩小”的源代码上进行任何开发工作。保留原始版本并在需要时重新创建压缩版本。

有关此主题的更多信息:www.minifycss.com

  1. The character case doesn't matter, there's no difference in the number of bytes.
  2. It depends on the browser:

The first statement is one byte shorter, but it also has a different meaning.

In general file size is not the only factor in the speed calculation. It also depends on how difficult it is for the browser to interpret it. So any overly clever CSS construct might squeeze some bytes out of the total size, but it's possible that the parsing process itself takes longer.

Back to your example: It is possible that second statement is a little bit slower, not just because of the extra space, but also the value consists of two tokens and depending on the internal representation of the background, the browser might have to do some unit conversions. On the other hand that keyword lookup can take a little more time, too, so it is really specific to a certain browser implementation. Most likely any gain would be in the range of nano-seconds and you shouldn't bother with this kind of optimization, as it most likely will not pay off. But if you really want to do this, you have to profile, i.e. measure the loading time.

In general it's enough to remove all comments and all unnecessary whitespace, but never do any development work on that "minified" source. Keep the original and recreate the compressed version when needed.

More information about this topic: www.minifycss.com and this.

我的奇迹 2024-08-14 22:13:43

听起来这很麻烦,如果你想获得更好的性能,你的时间最好花在其他地方。您知道 Steve Souders 在高性能网站方面的工作吗? http://stevesouders.com/hpws/

Sounds like this is a lot of trouble, you're time might be best spent elsewhere if you're trying to get better performance. Are you aware of Steve Souders work on High Performance Websites? http://stevesouders.com/hpws/

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