以太网帧有效载荷_减少有效载荷：压缩，缩小，204秒

最新推荐文章于 2024-06-30 13:22:12 发布

cunbei2644

最新推荐文章于 2024-06-30 13:22:12 发布

阅读量604

点赞数

文章标签： python java linux javascript 大数据 ViewUI

原文链接：https://www.phpied.com/reducing-tpayload/

版权

以太网帧有效载荷

2010 update: Lo, the Web Performance Advent Calendar hath moved

2010年更新： Lo， Web Performance Advent Calendar已移动

Dec 11 This post is part of the 2009 performance advent calendar experiment. Stay tuned for the next articles.

12月11日这篇文章是2009年性能出现日历实验的一部分。请继续关注下一篇文章。

After removing all the extra HTTP requests you possibly can from your waterfall, it's time to make sure that those that are left are as small as they can be. Not only this makes your pages load faster, but it also helps you save on the bandwidth bill. Your weapons for fighting overweight component include: compression and minification of text-based files such as scripts and styles, recompression of some downloadable files, and zero-body components. (A follow-up post will talk about optimizing images.)

在从瀑布中删除所有可能的额外 HTTP 请求之后，是时候确保剩下的请求尽可能小了。这不仅使您的页面加载速度更快，而且还帮助您节省了带宽费用。解决超重组件的武器包括：压缩和压缩基于文本的文件(如脚本和样式)，重新压缩某些可下载文件以及零主体组件。 (后续文章将讨论优化图像。)

压缩纯文本组件 (Gzipping plain text components)

Hands down the easiest and at the same time quite effective optimization - turning on gzipping for all plain text components. It's almost a crime if you don't do it. Doesn't "cost" any development time, just a simple flip of a switch in Apache configuration. And the results could be surprisingly pleasant.

进行最简单，同时又非常有效的优化-为所有纯文本组件打开gziping。如果不这样做，几乎是犯罪。无需“花费”任何开发时间，只需简单地切换一下Apache配置即可。结果可能令人惊讶。

When Bill Scott joined Netflix, he noticed that gzip is not on. So they turned it on. And here's the result - the day they enabled it, the outbound traffic pretty much dropped in half (slides)

当Bill Scott加入Netflix时，他注意到gzip尚未打开。所以他们打开了它。结果是-他们启用它的那一天，出站流量几乎减少了一半(幻灯片)

Netflix traffic after turning on gzipping

Gzip常见问题 (Gzip FAQ)

How much improvement can you expect from gzip? 您对gzip有什么期望？

On average - 70% reduction of the file size!

平均-文件大小减少70％！

Any drawbacks? 有什么缺点吗？

Well, there's a certain cost associated with the server compressing the response and the browser uncompressing it, but it's negligible compared to the benefits you get

好吧，服务器压缩响应和浏览器将其压缩会产生一定的成本，但是与您获得的收益相比，可以忽略不计

Any browser quirks? 有浏览器怪癖吗？

fixed for after that. You can boldly ignore this edge case, but if you're extra paranoid you can disable gzip for this user agent 修复。您可以大胆地忽略这种情况，但是如果您特别偏执，可以为此用户代理禁用gzip

How to tell if it's on? 如何判断它是否开启？

webpagetest.org. You should see the header: webpagetest.org)查看HTTP标头。您应该看到标题：

Content-Encoding: gzip

provided, of course, that your browser claimed it supports compression by sending the header:

当然，前提是您的浏览器通过发送标头声明支持压缩：

Accept-Encoding: gzip, deflate

What types of components should you gzip? 您应该gzip什么类型的组件？

javascripts
JavaScripts
css
CSS
plain text
纯文本
html, xml, including any other XML-based format such as SVG, also IE's .htc
html，xml，包括其他任何基于XML的格式(例如SVG)，也就是IE的.htc
JSON responses from web service calls
Web服务调用的JSON响应
anything that's not a binary file...
任何不是二进制文件的东西...

You should also gzip @font-files like EOT, TTF, OTF, with the exception of WOFF. Average about 40% to be won there with font files.

您还应该gzip @ font-files，例如EOT，TTF，OTF，WOFF除外。那里大约有40％的字体文件可以赢得。

如何开启gzip (How-to turn on gzipping)

Ideally you need control over the Apache configuration. If not full control, at least most hosting providers will offer you ability to tweak configuration via .htaccess. If your host doesn't, well, change the host.

理想情况下，您需要控制Apache配置。如果不能完全控制，至少大多数托管服务提供商将为您提供通过.htaccess调整配置的功能。如果您的主机不行，请更换主机。

So just add this to .htaccess:

因此，只需将其添加到.htaccess ：

AddOutputFilterByType DEFLATE text/html text/css text/plain text/xml application/javascript application/json

If you're on Apache before version 2 or your unfriendly host don't allow any access to configuration, not all is lost. You can make PHP do the gzipping for you. It's not ideal but the gzip benefits are so pronounced that it's worth the try. This article describes a number of different options for gzipping when dealing with uncooperative hosts.

如果您使用的是版本2之前的Apache或不友好的主机不允许任何配置访问，则不会丢失所有信息。您可以使PHP为您执行gziping。这并不理想，但是gzip的好处是如此明显，值得一试。本文介绍了在处理不合作的主机时用于gzip压缩的许多不同选项。

重新压缩 (Rezipping)

As Billy Hoffman discovered, there's potential for file size reduction with common downloadable files, which are actually zip files in disguise. Such files include:

正如Billy Hoffman所发现的那样，使用常见的可下载文件(实际上是变相的zip文件)可以减小文件的大小。这些文件包括：

Newer MS Office documents - DOCX, XLSX, PPTX
较新的MS Office文档-DOCX，XLSX，PPTX
Open Office documents - ODT, ODP, ODS
开放办公室文件-ODT，ODP，ODS
JARs (Java Applets, anyone?)
JAR(Java Applet，有人吗？)
XPI Firefox extensions
XPI Firefox扩展
XAP - Silverlight applications
XAP-Silverlight应用程序

These ZIP files in disguise are usually not compressed with the maximum compression. If you allow such downloads from your website, consider recompressing them beforehand with maximum compression.

通常不以最大压缩率压缩变相的这些ZIP文件。如果您允许从您的网站进行此类下载，请考虑事先以最大压缩率对其进行重新压缩。

There could be anywhere from 1 to 30% size reduction to be won, definitely worth the try, especially since you can do it all on the command line, as part of the build process, etc. (re)Compress once, save bandwidth and offer faster downloads every time 😉

可能会减少1％到30％的尺寸，这绝对值得一试，特别是因为您可以在命令行中，在构建过程中进行所有操作，等等。(重新)压缩一次，节省带宽并每次提供更快的下载速度😉

15％的未压缩流量 (15% uncompressed traffic)

Tony Gentilcore of Google reported his findings that a significant chunk of their traffic is still sent uncompressed. Digging into it he realized there's a number of anti-virus software and firewalls that will mingle with the browser's Accept-Encoding header changing into the likes of:

Google的Tony Gentilcore报告了他的发现，他们的很大一部分流量仍未压缩发送。深入研究它，他意识到有许多防病毒软件和防火墙将与浏览器的Accept-Encoding标头混合在一起，例如：

Accept-Encoding: xxxx, deflxxx
Accept-Enxoding: gzip, deflate

Since this is an invalid header, the server will decide that the browser doesn't support gzip and send uncompressed response. And why would the retarded anti-virus program do it? Because it doesn't want to deal with decompression in order to examine the content. Probably not to slow down the experience? In doing so it actually hurts the user to a greater extend.

由于这是无效的标头，因此服务器将确定浏览器不支持gzip并发送未压缩的响应。以及为什么迟钝的防病毒程序会这样做？因为它不想为了检查内容而处理减压。可能不会减慢体验？这样做实际上会更大程度地伤害用户。

So compression is important, but unfortunately it's not always present. That's why minification helps - not only because compressing minified responses is even smaller, but because sometimes there is no compression despite your best efforts.

因此压缩很重要，但不幸的是并非总是如此。这就是为什么缩小有帮助的原因-不仅因为压缩缩小的响应甚至更小，而且因为有时即使您尽了最大努力也没有压缩。

缩小 (Minification)

Minification means striping extra code from your programs that is not essential for execution. The code in question is comments, whitespace, etc from styles and scripts, but also renaming variables with shorter names, and various other optimizations.

缩小意味着从程序中剥离不必要的多余代码，这些代码对于执行来说不是必需的。有问题的代码是样式和脚本中的注释，空格等，而且还使用更短的名称以及各种其他优化来重命名变量。

This is best done with a tool, of course, and luckily there a number of tools to help.

当然，最好使用工具完成此操作，幸运的是，有许多工具可以帮助您。

缩小JavaScript (Minifying JavaScript)

Some of the tools to minify JavaScript include:

减少JavaScript的一些工具包括：

YUICompressor
YUI压缩机
Dojo ShrinkSafe
Dojo ShrinkSafe
Packer
封隔器
JSMin
敏敏
... and the new kid on the block - Google's Closure compiler
...和新手一样-Google的Closure编译器

How much size reduction can you expect from minification? To answer that I ran jQuery 1.3.2. through all the tools mentioned above (using hosted versions) and compared the sizes before/after and with/without gzipping the result of minification.

您期望缩小尺寸多少？为了回答这个问题，我运行了jQuery 1.3.2。通过上述所有工具(使用托管版本)进行了比较，并比较了压缩前后的大小(有无gzip)。

The table below lists the results. All the % figures are % of the original, so smaller is better. 29% means the file was reduced to 29% of its original version, or a saving of 71%

下表列出了结果。所有百分比数字均为原始百分比，因此越小越好。 29％表示文件已减少到原始版本的29％，或节省了71％

File	original size	size, gzipped	% of original	gzip, % of original
original	120619	35088	100.00%	29.09%
closure-advanced	49638	17583	41.15%	14.58%
closure	55320	18657	45.86%	15.47%
jsmin	73690	21198	61.09%	17.57%
packer	39246	18659	32.54%	15.47%
shrinksafe	69516	22105	57.63%	18.33%
yui	57256	19677	47.47%	16.31%

文件	原始尺寸	大小，已压缩	原始百分比	gzip，原始百分比
原版的	120619	35088	100.00％	29.09％
提前关闭	49638	17583	41.15％	14.58％
关闭	55320	18657	45.86％	15.47％
杰斯敏	73690	21198	61.09％	17.57％
封隔器	39246	18659	32.54％	15.47％
安全收缩	69516	22105	57.63％	18.33％
ui	57256	19677	47.47％	16.31％

As you can see gzipping alone gives you about 70% savings, minification alone cuts script sizes with more than half and both combined (minifying then gzipping) can make your scripts 85% leaner. Verdict: do it. The concrete tool you use probably doesn't really matter all that much, pick anything you're comfortable with to run before deployment (or best, automatically during a build process)

如您所见，仅gzip压缩可为您节省约70％的资源，仅通过缩小压缩就可以将脚本大小减少一半以上，并且将两者组合在一起(最小化然后进行gzip压缩)可以使脚本精简85％。判决：做吧。您使用的具体工具可能并没有多大关系，在部署之前选择您愿意运行的任何工具(或者最好在构建过程中自动运行)

缩小CSS (Minifying CSS)

In addition to the usual stripping of comments and whitespaces, more advanced CSS minification could include for example:

除了通常去除注释和空格外，更高级CSS缩小可以包括例如：

// before
#mhm {padding: 0px 0px 0px 0px;}
// after
#mhm{padding:0}

// before
#ha{background: #ff00ff;}
// after 
#ha{background:#f0f}
//...

A CSS minifier is much less powerful than a JS minifier, it cannot rename properties or reorganize them, because the order matters and for example text-decoration:underline cannot get any shorter than that.

CSS缩小器的功能远不如JS缩小器，它无法重命名属性或重新组织属性，因为顺序很重要，例如text-decoration:underline不能比其短。

There's not a lot of CSS minifiers, but here's a few I tested:

没有太多CSS缩小器，但是我测试了一些：

YUI compressor - yes, the same YUI compressor that does JavaScript minification. I've actually ported the CSS minification part of it to JavaScript (it's in Java otherwise) some time ago. There's even an online form you can paste into to test. The CSS minifier is regular expression based
YUI压缩器-是的，使用相同的YUI压缩器进行JavaScript压缩。实际上，前一段时间我已经将其中CSS缩小部分移植到了JavaScript(否则使用Java)。您甚至可以粘贴在线表格进行测试。 CSS缩小器是基于正则表达式的
Minify is a PHP based JS/CSS minification utility started by Ryan Grove. The CSS minifier part is also with regular expressions, I have the feeling it's also based on YUICompressor, at least initially
Minify是由Ryan Grove启动的基于PHP的JS / CSS缩小实用程序。 CSS minifier部分也带有正则表达式，我觉得它也基于YUICompressor，至少在最初
CSSTidy - a parser and an optimizer written in PHP, but also with C version for desktop executable. There's also a hosted version. It's probably the most advanced optimizer in the list, being a parser it has a deeper understanding of the structure of the styleshets
CSSTidy-用PHP编写的解析器和优化器，还具有用于桌面可执行文件的C版本。还有一个托管版本。它可能是列表中最先进的优化器，它是一个解析器，可以更深入地了解样式表的结构
HTML_CSS from PEAR - not exactly an optimizer but more of a general purpose library for creating and updating stylesheets server-side in PHP. It can be used as a minifier, by simply reading, then printing the parsed structure, which strips spaces and comments as a side effect.
来自PEAR的 HTML_CSS-并非完全是优化器，而是更多用于在PHP中在服务器端创建和更新样式表的通用库。只需阅读，然后打印已解析的结构，即可将其用作缩小器，该结构会将空格和注释剥离为副作用。

Trying to get an average figure of the potential benefits, I ran these tools on all stylesheets from csszengarden.com, collected simply like:

为了获得潜在收益的平均数，我在csszengarden.com的所有样式表上运行了这些工具，其收集方式如下：

<?php
$urlt = "http://csszengarden.com/%s/%s.css";
for ($i = 1; $i < 214; $i++) {
  $id = str_pad($i, 3, "0", STR_PAD_LEFT);
  $url = sprintf($urlt, $id, $id);
  file_put_contents("$id.css", file_get_contents($url));
}
?>

3 files gave a 404, so I ran the tools above on the rest 210 files. CSSTidy ran twice - once with its safest settings (which even keep comments in) and then with the most aggressive. The "safe" way to use CSSTidy is like so:

3个文件提供了404，所以我在其余的210个文件上运行了上面的工具。 CSSTidy运行了两次-一次使用最安全的设置(甚至保留注释)，然后进行最激进的设置。使用CSSTidy的“安全”方式如下：

<?php
// dependencies, instance
include 'class.csstidy.php';
$css = new csstidy();
 
// options
$css->set_cfg('preserve_css',true);
$css->load_template('high_compression');
 
// parse
$css->parse($source_css_code);
 
// result
$min = $css->print->plain();
?>

The aggressive minification is the same only without setting the preserve_css option.

仅在未设置preserve_css选项的情况下，主动缩小才是相同的。

Running Minify is simple:

运行Minify很简单：

<?php
// dependencies, instance
require 'CSS.php';
$minifier = new Minify_CSS();
 
// minify in one shot
$min = $minifier->minify($source_css_string_or_url);

As for PEAR::HTML_CSS, since it's not a minifier, you only need to parse the input and print the output.

至于PEAR :: HTML_CSS，由于它不是缩小器，因此只需要解析输入并输出输出即可。

<?php
require 'HTML/CSS.php';
 
$options = array(
    'xhtml' => false,
    'tab' => 0,
    'oneline' => true,
    'groupsfirst' => false,
    'allowduplicates' => true,
);
 
$css = new HTML_CSS($options);
$css->parseFile($input_filename);
$css->toFile($output_filename);
// ... or alternatively if you want the result as a string
// $minified = $css->toString();

So I ran those tools on the CSSZenGarden 200+ files and the full table of results is here, below are just the averages:

因此，我在CSSZenGarden 200+文件上运行了这些工具，结果的完整列表在此处，下面只是平均值：

	Original	YUI	Minify	CSSTidy-safe	CSSTidy-small	PEAR
raw	100%	68.18%	68.66%	84.44%	63.29%	74.60%
gzipped	30.36%	19.89%	20.74%	28.36%	19.44%	20.20%

	原版的	UI	缩小	CSSTidy-safe	CSSTidy-small	梨
生的	100％	68.18％	68.66％	84.44％	63.29％	74.60％
压缩	30.36％	19.89％	20.74％	28.36％	19.44％	20.20％

Again, the numbers are percentage of the original, so smaller is better. As you can see, on average gzip alone gives you 70% size reduction. The minification is not so successful as with JavaScript. Here even the best tool cannot reach 40% reduction (for JS it was usually over 50%). But nevertheless, gzip+minification on average gives you a reduction of 80% or more. Verdict: do it!

同样，数字是原始数字的百分比，因此较小的数字更好。如您所见，平均而言，仅gzip可使您减小70％的大小。缩小效果不像JavaScript那样成功。在这里，即使是最好的工具也无法减少40％的费用(对于JS，通常减少了50％以上)。但是，尽管如此，平均而言，gzip + minification可使您减少80％或更多。判决：做吧！

An important note here is that in CSS we deal with a lot of hacks. Since the browsers have parsing issues (which is what hacks often exploit), what about a poor minifier? How safe are the minifiers? Well, that's a subject for a separate study, but I know I can at least trust the YUICompressor, after all it's used by hundreds of Yahoo! developers daily and probably thousands non-Yahoos around the world. PEAR's HTML_CSS library also looks pretty safe because it has a simple parser that seems to tolerate all kinds of hacks. CSSTidy also claims to tolerate a lot of hacks, but given that the last version is two years old (maybe new hacks have surfaced meanwhile) and the fact that it's the most intelligent optimizer (knows about values, colors and so on) it should be approached with care.

这里要注意的重要一点是，在CSS中，我们处理了很多黑客问题。由于浏览器存在解析问题(这是黑客经常利用的问题)，可怜的粉碎机怎么办？矿工有多安全？嗯，这是一个单独的研究主题，但是我知道我至少可以相信YUICompressor，毕竟它已经被数百个Yahoo!所使用。每天都有开发人员，全球可能有成千上万的非雅虎用户。 PEARHTML_CSS库看起来也很安全，因为它有一个简单的解析器，似乎可以容忍各种黑客行为。 CSSTidy还声称可以容忍许多hack，但是鉴于最新版本已有两年历史(可能同时出现了新hack)，而且它是最智能的优化器(知道值，颜色等)，因此应该小心翼翼地接近。

204 (204)

Let's wrap up this lengthy posting with an honorable mention of the 204 No Content response (blogged before). It's the world's smallest componet, the one that has no body and a Content-Length of 0.

让我们结束这段漫长的发布，并在光荣地提到204 No Content响应(在之前博客)。这是世界上最小的组件，没有Content-Length为0。

Often people use 1x1 GIFs for logging and tracking purposes and other types of requests that don't need a response. If you do this, you can return a 204 status code and no response body, only headers. Look no further that Google search results with your HTTP sniffer ON to see examples of 204 responses.

人们通常将1x1 GIF用于记录和跟踪目的以及不需要响应的其他类型的请求。如果这样做，则可以返回204状态代码，不返回响应主体，仅返回标头。开启HTTP嗅探器即可查看Google搜索结果，以查看204个响应示例。

The way to send a 204 response from PHP is simply:

从PHP发送204响应的方法很简单：