在PHP中打包、缓存、JS和CSS区分开发和生产环境。

时间:2022-03-01 12:49:40

I am trying to make development easy and have highly optimized output in production.

我正在努力使开发变得简单,并且在生产中有高度优化的输出。

The goals of what I am trying to do is:

我所要做的目标是:

  • Make production pages fast! I would like that the Google Page Speed and YSlow return the best scores. This means:
    1. Combine and compress JS files and CSS and position the group in the right place (bottom or top of the page) in the HTML. For .js Google Closure seems the best choice.
    2. 合并和压缩JS文件和CSS,将组放在HTML中正确的位置(页面底部或顶部)。对于.js谷歌来说,闭包似乎是最好的选择。
    3. .JS and .CSS are smartly cached but be sure that they get reloaded when of the .JS or CSS componet is updated. 301 File not changed etc.
    4. . js和.CSS被巧妙地缓存,但是要确保在. js或CSS组件更新时重新加载它们。301文件未更改等。
    5. Cache type: I think cache on disk is fine. Consider APC and Memcache or Redis if they significantly improve speed.
    6. 缓存类型:我认为磁盘上的缓存没问题。如果APC和Memcache或Redis能显著提高速度,请考虑它们。
    7. Capable to specify and use lazy load of .JS when necessary or at least not to block the page rendering.
    8. 能够在必要时指定和使用. js的延迟加载,或至少不阻塞页面呈现。
    9. (Optional) Compress the HTML too.
    10. (可选)也压缩HTML。
  • 使生产页面快!我希望谷歌的页面速度和YSlow能得到最好的分数。这意味着:合并和压缩JS文件和CSS,并将组放在HTML中的正确位置(页面的底部或顶部)。对于.js谷歌来说,闭包似乎是最好的选择。.js和.CSS被巧妙地缓存,但是要确保它们在.js或CSS组件更新时被重新加载。301文件未更改等缓存类型:我认为磁盘上的缓存没问题。如果APC和Memcache或Redis能显著提高速度,请考虑它们。能够在必要时指定和使用. js的延迟加载,或至少不阻塞页面呈现。(可选)也压缩HTML。
  • Make website development easy:
    1. Use short command in the .php file when you want to include .js or .css and compress them only in the production environment
      • Use syntax like pack_js(['first.js', 'second.js' 'third.js']) and pack_css(['first.less', 'second.less' 'third.css'], true)
      • 使用语法pack_js(['。js”、“第二。js ' ' third.js '])和pack_css(['。少”、“第二。少“第三。css '],真的)
      • It is easy to configure develpment or production environment. Maybe just a call to SetDebug(true or false). Default production
      • 配置开发或生产环境很容易。可能只是调用SetDebug(true或false)。默认的生产
      • Easy to set up cache folders and source folders
      • 容易设置缓存文件夹和源文件夹。
    2. 当您希望包含.js或.css时,请在.php文件中使用简短命令,并仅在生产环境中压缩它们,请使用pack_js(['first])之类的语法。js”、“第二。js ' ' third.js '])和pack_css(['。少”、“第二。少“第三。配置开发或生产环境很容易。可能只是调用SetDebug(true或false)。默认产品容易设置缓存文件夹和源文件夹
    3. Use of LESS to make CSS development sucks less. Automatically compile LESS files in CSS in production but use of LESS.js in development so that each time you change the .less file in development it is updated on the server.
    4. 减少CSS开发的使用。在生产中自动编译较少的CSS文件,但使用较少。开发中的js,以便每次在开发中更改.less文件时,它都在服务器上更新。
    5. (optional) In development it includes a JS and a LESS console similar to the shell at https://www.squarefree.com/bookmarklets/webdevel.html
    6. (可选)在开发中,它包含一个JS和一个类似于https://www.squarefree.com/bookmarklets/webdevel.html的更小的控制台
  • 使网站开发更容易:当你想要包含.js或.css时,在.php文件中使用简短的命令,并且只在生产环境中压缩它们,使用pack_js(['first])之类的语法。js”、“第二。js ' ' third.js '])和pack_css(['。少”、“第二。少“第三。配置开发或生产环境很容易。可能只是调用SetDebug(true或false)。默认产品容易设置缓存文件夹和源文件夹使用较少,使CSS开发更少。在生产中自动编译较少的CSS文件,但使用较少。开发中的js,以便每次在开发中更改.less文件时,它都在服务器上更新。(可选)在开发中,它包含一个JS和一个类似于https://www.squarefree.com/bookmarklets/webdevel.html的更小的控制台

Note: it is OK to use Apachee modules and .htaccess files if they significantly speed up the process. But it should be able to set them up quicky, ideally with just a setup command.

注意:如果Apachee模块和.htaccess文件显著加快了进程,那么可以使用它们。但是它应该能够快速地设置它们,理想情况下只需一个setup命令。

Is there something that do this? Or what are the best resources to start?

有什么东西能做到这一点吗?或者最好的资源是什么?

I would prefer a solution that consists of a PHP script (eventually few .php files, .htaccess and compressing executables) that compresses the .JS with the Google Closure Compiler and compress/compile the CSS/LESS files stripping out useless comments and white spaces. A special cookie could be used on production server to output the development version.

我更喜欢一个由PHP脚本(最终只有几个. PHP文件、.htaccess和压缩可执行文件)组成的解决方案,它使用谷歌闭包编译器压缩. js,压缩/编译CSS/LESS文件,去掉无用的注释和空格。可以在生产服务器上使用一个特殊的cookie来输出开发版本。

I would like to have:

我想要:

A php function usable like this: pack_js(['first.js', 'second.js', 'third.js']) that write something like:

php函数可用如下:pack_js(['first)。js”、“第二。写的东西是这样的:

On developments servers:

在开发服务器上:

<script type="text/javascript" src="static/js/first.js"></script>
<script type="text/javascript" src="static/js/second.js"></script>
<script type="text/javascript" src="static/js/third.js"></script>

On production servers (if the special cookie is not present):

在生产服务器上(如果没有特殊的cookie):

<script type="text/javascript" src="cache/12a42323bfe339ea9w.js"></script>

Another function: pack_css(['first.less', 'second.less', 'third.css'], true) that write something like:

另一个函数:pack_css(['。少”、“第二。少”、“第三。)这样写:

On developments servers:

在开发服务器上:

<link rel="stylesheet/less" href="/static/css/first.less" type="text/css" />
<link rel="stylesheet/less" href="/static/css/second.less" type="text/css" />
<link href="/static/css/third.css" type="text/css" />
<script src="http://lesscss.googlecode.com/files/less-1.0.21.min.js"></script>

<script type="text/javascript" charset="utf-8">
    less.env = "development";
    less.watch();
</script>

On production servers (if the special cookie is not present):

在生产服务器上(如果没有特殊的cookie):

<link href="/cache/46537a8b8e876f7a8e7.css" type="text/css" />

the second parameter specify if the less.js should be output on the development server

第二个参数指定是否小于。js应该输出在开发服务器上

Obviously 12a42323bfe339ea9w.js and 46537a8b8e876f7a8e7.css are the optimized, packed and compiled version of the script. This solution should be able to detect when a source file change and recompile the scripts for production. It should be configurable to regarding locations of the script and type of caching (disk is fine). Ideally the pack_js should probably have an option to make possible lazy load of the js in production.

显然12 a42323bfe339ea9w。js和46537 a8b8e876f7a8e7。css是脚本的优化、打包和编译版本。该解决方案应该能够检测源文件何时更改并重新编译用于生产的脚本。它应该可以配置为关于脚本的位置和缓存的类型(磁盘没问题)。在理想情况下,pack_js应该有一个选项,可以在生产中延迟加载js。

Every suggestion is welcomed.

每个建议都欢迎。

3 个解决方案

#1


6  

Still working on exploring the best solution leveraging the resource already available.

仍然致力于探索利用现有资源的最佳解决方案。

CSS-JS-Booster and Turbine so far looks like the best starting point: http://github.com/Schepp/CSS-JS-Booster and http://turbinecss.org/

到目前为止,CSS-JS-Booster和Turbine看起来都是最好的切入点:http://github.com/Schepp/CSS-JS-Booster和http://turbinecss.org/

Other JS/CSS Combiners solutions and articles

Resource for JS compression and caching:

  • http://code.google.com/p/php-closure/ PHP script that let you combine .js files ancd combile thought the Google Closure REST API. Check timestamps and cache the combined version locally.
  • http://code.google.com/p/php-closure/ PHP脚本,它允许您组合.js文件和combile认为谷歌闭包REST API。检查时间戳并在本地缓存合并的版本。
  • http://dean.edwards.name/download JS packer compressor/obfuscator. I am not sure how long the decompression take. But it was able to shrink the jQuery 1.4.2 compiled/minified with Closure to 50639 bytes from 71946 (almost 30% reduction!) with Base62 Encode on! It would be interesting to compare the gzipped versions. Regarding JS obfuscation Packer optimizer make a little more difficult to tamper in your JS code.
  • http://dean.edwards.name/download JS封隔器压缩机/模糊处理。我不知道减压需要多长时间。但是它能够将jQuery 1.4.2编译/缩小到50639字节(从71946年减少了近30% !)比较gzip版本会很有趣。关于JS混淆封隔器优化器,在您的JS代码中篡改会更加困难。
  • http://thinkvitamin.com/dev/serving-javascript-fast/ Great discussion about gzip and caching
  • http://thinkvitamin.com/dev/serving-javascript-fast/关于gzip和缓存的精彩讨论
  • http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool Ruby Juicer JS/CSS packaging tool
  • http://cjohansen。没有/en/ruby/juicer_a_css_and_javascript_packaging_tool ruby Juicer JS/CSS打包工具

LESS compilers/tutorials/tools:

At Deployment time options:

#2


2  

Why don't you use a project build system to deploy your application to the production server that does just that? For PHP you might like Phing, since it would allow you to write extra plugins in PHP, that you can execute while deploying. Other options you might want to consider of you take this route are Ant and Capistrano (and there's lots of others), but these require knowledge of other languages (granted, you could start the php parser from them if you really wanted to...).

为什么不使用项目构建系统将应用程序部署到生产服务器上呢?对于PHP,您可能喜欢Phing,因为它允许您在PHP中编写额外的插件,您可以在部署时执行这些插件。您可能需要考虑的其他选项是Ant和Capistrano(还有很多其他的选项),但是这些都需要了解其他语言(当然,如果您确实想要……,您可以从它们开始php解析器)。

#3


0  

Great Question!

好问题!

I've worked with a process with similar requirements, but we took somewhat of a different approach. I realise its maybe not exactly what you're after, but would still make some recommendations:

我曾处理过一个具有类似需求的流程,但我们采用了不同的方法。我意识到这也许并不是你想要的,但还是会给你一些建议:

  1. Make the compression/compilation part of the shipping process.(You may already be doing this, but it wasn't clear from the above).
  2. 使压缩/编译成为运输过程的一部分。(你可能已经在这么做了,但从上面看不清楚)。
  3. Compress/compile it on the development servers too. It might be a hassle for debugging/testing but you want to be able ensure the production version and test versions are as similar as possible. If you have the luxury of multiple development stages, then you could possibly compress on one of them.
  4. 在开发服务器上也压缩/编译它。调试/测试可能会很麻烦,但是您希望能够确保产品版本和测试版本尽可能相似。如果您拥有多个开发阶段的优势,那么您可以对其中一个进行压缩。
  5. Only do the compression/compilation if it passes some sort of quality scan (e.g. jslint)
  6. 只有在通过某种质量扫描(例如jslint)时才进行压缩/编译
  7. Don't combine the modules - keep them separate. The performance benefits you will gain will be so negligible, as to be almost pointless.
  8. 不要合并这些模块——将它们分开。你将获得的性能收益是如此微不足道,以至于几乎毫无意义。
  9. Don't change the HTML, just change the dependant modules content.
  10. 不要更改HTML,只需更改依赖模块的内容。

I realise its a bit different from what you were intending, but in my experience it leads to a more robust development promotion model.

我意识到这与你的预期有点不同,但根据我的经验,这将导致一种更稳健的发展促进模式。

#1


6  

Still working on exploring the best solution leveraging the resource already available.

仍然致力于探索利用现有资源的最佳解决方案。

CSS-JS-Booster and Turbine so far looks like the best starting point: http://github.com/Schepp/CSS-JS-Booster and http://turbinecss.org/

到目前为止,CSS-JS-Booster和Turbine看起来都是最好的切入点:http://github.com/Schepp/CSS-JS-Booster和http://turbinecss.org/

Other JS/CSS Combiners solutions and articles

Resource for JS compression and caching:

  • http://code.google.com/p/php-closure/ PHP script that let you combine .js files ancd combile thought the Google Closure REST API. Check timestamps and cache the combined version locally.
  • http://code.google.com/p/php-closure/ PHP脚本,它允许您组合.js文件和combile认为谷歌闭包REST API。检查时间戳并在本地缓存合并的版本。
  • http://dean.edwards.name/download JS packer compressor/obfuscator. I am not sure how long the decompression take. But it was able to shrink the jQuery 1.4.2 compiled/minified with Closure to 50639 bytes from 71946 (almost 30% reduction!) with Base62 Encode on! It would be interesting to compare the gzipped versions. Regarding JS obfuscation Packer optimizer make a little more difficult to tamper in your JS code.
  • http://dean.edwards.name/download JS封隔器压缩机/模糊处理。我不知道减压需要多长时间。但是它能够将jQuery 1.4.2编译/缩小到50639字节(从71946年减少了近30% !)比较gzip版本会很有趣。关于JS混淆封隔器优化器,在您的JS代码中篡改会更加困难。
  • http://thinkvitamin.com/dev/serving-javascript-fast/ Great discussion about gzip and caching
  • http://thinkvitamin.com/dev/serving-javascript-fast/关于gzip和缓存的精彩讨论
  • http://cjohansen.no/en/ruby/juicer_a_css_and_javascript_packaging_tool Ruby Juicer JS/CSS packaging tool
  • http://cjohansen。没有/en/ruby/juicer_a_css_and_javascript_packaging_tool ruby Juicer JS/CSS打包工具

LESS compilers/tutorials/tools:

At Deployment time options:

#2


2  

Why don't you use a project build system to deploy your application to the production server that does just that? For PHP you might like Phing, since it would allow you to write extra plugins in PHP, that you can execute while deploying. Other options you might want to consider of you take this route are Ant and Capistrano (and there's lots of others), but these require knowledge of other languages (granted, you could start the php parser from them if you really wanted to...).

为什么不使用项目构建系统将应用程序部署到生产服务器上呢?对于PHP,您可能喜欢Phing,因为它允许您在PHP中编写额外的插件,您可以在部署时执行这些插件。您可能需要考虑的其他选项是Ant和Capistrano(还有很多其他的选项),但是这些都需要了解其他语言(当然,如果您确实想要……,您可以从它们开始php解析器)。

#3


0  

Great Question!

好问题!

I've worked with a process with similar requirements, but we took somewhat of a different approach. I realise its maybe not exactly what you're after, but would still make some recommendations:

我曾处理过一个具有类似需求的流程,但我们采用了不同的方法。我意识到这也许并不是你想要的,但还是会给你一些建议:

  1. Make the compression/compilation part of the shipping process.(You may already be doing this, but it wasn't clear from the above).
  2. 使压缩/编译成为运输过程的一部分。(你可能已经在这么做了,但从上面看不清楚)。
  3. Compress/compile it on the development servers too. It might be a hassle for debugging/testing but you want to be able ensure the production version and test versions are as similar as possible. If you have the luxury of multiple development stages, then you could possibly compress on one of them.
  4. 在开发服务器上也压缩/编译它。调试/测试可能会很麻烦,但是您希望能够确保产品版本和测试版本尽可能相似。如果您拥有多个开发阶段的优势,那么您可以对其中一个进行压缩。
  5. Only do the compression/compilation if it passes some sort of quality scan (e.g. jslint)
  6. 只有在通过某种质量扫描(例如jslint)时才进行压缩/编译
  7. Don't combine the modules - keep them separate. The performance benefits you will gain will be so negligible, as to be almost pointless.
  8. 不要合并这些模块——将它们分开。你将获得的性能收益是如此微不足道,以至于几乎毫无意义。
  9. Don't change the HTML, just change the dependant modules content.
  10. 不要更改HTML,只需更改依赖模块的内容。

I realise its a bit different from what you were intending, but in my experience it leads to a more robust development promotion model.

我意识到这与你的预期有点不同,但根据我的经验,这将导致一种更稳健的发展促进模式。