CSS压缩& 组合 / js 缩小 - 在运行时或构建时更好?

发布于 2024-07-25 23:05:18 字数 464 浏览 3 评论 0原文

我必须想出一个压缩、版本(用于缓存目的)并可能结合我们的 JS 和 CSS 文件的解决方案,到目前为止我已经看到了两种主要方法:

1)在构建时:作为 MSBuild 任务或类似任务。 2)在运行时动态:作为 .js 和 .css 文件的自定义 HTTPHandler(顺便说一句,我们是 ASP.NET),在您的页面中会出现这样的内容:

<link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css" /> 

任何人都可以提供每个的优点和缺点的信息吗? 就我个人而言,我看不出动态执行此操作并在每次请求时浪费 CPU 周期的意义(我猜你只会第一次执行工作,然后缓存,但仍然如此),但我感觉我可能会这样做缺少什么吗?

谢谢! 标记。

I have to come up with a solution to compress, version (for caching purposes) and potentially combine our JS and CSS files and I've seen two dominant approaches so far:

1) At build time: As an MSBuild task or similar.
2) Dynamically at run time: As a custom HTTPHandler (we are ASP.NET btw) for .js and .css files, with something like this ending up in your pages:

<link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css" /> 

Can anyone provide information of pro's and con's of each? Personally, I can't see the point of doing it dynamically and wasting CPU cycles at the time of each request (I guess you'd only do with the work first time and then cache, but still) but I get the feeling I might be missing something?

Thanks!
Mark.

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

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

发布评论

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

评论(5

酒绊 2024-08-01 23:05:18

我认为一个好的方法是针对不同的环境使用不同的策略:

  • 压缩开发(用于开发和调试)
  • 运行时压缩< em>测试环境(灵活,不是性能关键)
  • 构建时间压缩登台和生产(经过测试,性能关键)

我有一些使用的经验用于 Javascript 和 CSS 的 href="http://developer.yahoo.com/yui/compressor/" rel="noreferrer">YUI 压缩器 并学会了(艰难的方式)测试缩小的 JS 和 CSS确实非常重要。

创建静态缩小的 JS 和 CSS 文件作为生产构建的一部分具有以下优点:

  • 它们是经过测试的
  • 静态文件,可以在没有 ASP.NET 开销的情况下提供服务
  • 可以是浏览器缓存
  • 应该是 webserver-gzipped

I think a good approach is to use different strategies for different environments:

  • no compression for development (for developing & debugging)
  • runtime compression for test environment (flexible, not performance-critical)
  • buildtime compression for staging and production (tested, performance-critical)

I have some experience using the YUI compressor for both Javascript and CSS and have learned (the hard way) that testing minified JS and CSS is indeed very important.

Creating static minified JS and CSS files as part of your build for production has the following benefits:

  • they are tested
  • static files, can be served without ASP.NET overhead
  • can be browser cached
  • should be webserver-gzipped
家住魔仙堡 2024-08-01 23:05:18

最好的方法是根本不这样做,因为所有现代浏览器和服务器都处理 Gzip 编码。 看一下数字:

  • cfform.js - 21k
  • cfform-minified.js - 12k
  • cfform.js.gz - 4.2k
  • cfform-minified.js.gz - 2.2k

这是一个相当大的 JS 文件,其中有大量不必要的空格,但在最后的方程式你已经节省了高达 2k 的钱! 不仅如此,由于缓存,这种节省是针对每个访问者的,而不是针对每个页面的。 呼呼,现在所有的麻烦都值得了,不是吗?

通过裁剪横幅顶部的像素宽度,您可以节省 10 倍的时间,并且由于 99% 的用户使用宽带,您已经为他们节省了大约 1 毫秒的下载时间。 亮起彩带和香槟!

JS 压缩更糟糕,因为您刚刚给您的客户带来了在每个页面加载时解压缩的负担。 gzip 之后的节省也同样惨不忍睹。

严重地。 除非您的目标是移动市场(甚至假设用户仍然使用 CDMA,而不是 3G)或者每天的点击量达到 10 亿次,否则增加的复杂性和调试是不值得的。 否则就别打扰了。

The best way is to not do it at all, since all modern browsers and servers handle Gzip encoding. Look at the numbers:

  • cfform.js - 21k
  • cfform-minified.js - 12k
  • cfform.js.gz - 4.2k
  • cfform-minified.js.gz - 2.2k

This is a fairly large JS file with plenty of unnecessary whitespace but in the final equation you've saved a whopping 2k !! Not only that but thanks to caching this saving is per-visitor, not per-page. Whoo-hoo, now that was worth all the trouble wasn't it?

You'd save 10 times that by cropping a pixel width off the top of your banner and with 99% of your users on broadband you've saved them about 1 millisecond of download time. Break out the streamers and champagne!

JS compression is even worse, since you've just hit your clients with the burden of decompressing on EVERY PAGE LOAD. And the savings after gzip are just as miserable.

Seriously. The added complexity and debugging is not worth it unless you are targetting a mobile market (and even that assumes the users are still on CDMA, not 3G) or have a billion hits per day. Otherwise just don't bother.

终陌 2024-08-01 23:05:18

我想说最好在第一次请求和缓存时执行。 这样做的原因是,您可以根据需要以可读格式更新 css,而无需返回重建。 您可以将缓存基于 css 文件,以便一旦更改,缓存就会刷新。

乔什

I'd say its better to do on first request and cache. the reason for this is so that you can update the css as needed in a readable format without having to go back to rebuilding. you can base your cache on the css file so as soon as it is changed the cache refreshes.

Josh

没有你我更好 2024-08-01 23:05:18

您可以在运行时执行此操作,但仅在需要时执行。 这为您提供了最大的灵活性。 对于 PHP 来说,这尤其是一个问题,否则它没有构建步骤(即,当您没有构建步骤时,您不想添加一个步骤),但对于其他有构建步骤的平台来说,这仍然是一个问题。

冒着自我推销的风险,您可能需要阅读在 PHP 中增强 Javascript< /a> 和 在 PHP 中增强 CSS,其中概述问题、方法和最佳实践。 这些示例是用 PHP 编写的,但代码本身很简单。 这些问题和原则适用于任何 Web 平台。

You do it at runtime but only when you need to. This gives you the most flexibility. It's particularly an issue with PHP which otherwise has no build step (ie you don't want to add one when you don't have one otherwise) but still an issue for other platforms that do.

At the risk of self-promotion, you might want to read Supercharging Javascript in PHP and Supercharging CSS in PHP, which outline the issues, approaches and best practices. The examples are in PHP but the code itself is trivial. The issues and principles apply to any Web platform.

情深已缘浅 2024-08-01 23:05:18

我认为你应该在运行时创建它,除非你的 CSS 和 JS 文件非常大(超过 1MB)。
可以通过设置一些 http headers 来强制浏览器缓存,并且当您希望应用程序在客户端强制重新加载,只需更改 HTTP 参数:

<link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css&token=1" />

您可以更改令牌以在客户端强制重新加载 CSS。

I think you should make it at run time, except if your CSS and JS files are really huge (more than 1MB).
The browser cache can be force by setting a few http headers, and when you want your application to force a reload at the client side, just change an HTTP param :

<link rel="stylesheet" type="text/css" href="~/StyleSheetHandler.ashx?stylesheets=~stylesheets/master.css&token=1" />

You can change the token to force the reload of the CSS at client side.

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