问题标签 [pagespeed]

我正在使用 cms (Wordpress) 并在每个页面上加载了一堆外部样式表，尽管其中一些样式表是特定于页面的。总的来说，我从 Yslow 和 Page Speed 得到了不好的分数，所以我正在考虑添加一些 php 条件来告诉浏览器在必要时只加载页面特定的 css 文件。但是，我想知道我是否真的要减少加载时间，因为我将为浏览器添加更多 PHP 请求。

似乎大多数人使用 CDN 来放置图像和/或视频。将您的 js 和 css 也放在 cdn 上是否明智？

Google PageSpeed 说我应该为 JS 和 CSS “指定一个 Vary：Accept-Encoding 标头”。如何在 .htaccess 中执行此操作？

我在我的网站上运行 Google PageSpeed，它告诉我需要
“指定缓存验证器”。

以下资源缺少缓存验证器。未指定缓存验证器的资源无法有效刷新。指定 Last-Modified 或 ETag 标头以启用以下资源的缓存验证：

...然后它列出了图像、CSS、JS 等。

根据http://code.google.com/speed/page-speed/docs/caching.html#LeverageBrowserCaching：

将 Last-Modified 日期设置为上次更改资源的时间。如果 Last-Modified 日期在过去足够远，浏览器很可能不会重新获取它。

我的 .htaccess 中有以下内容：

我究竟做错了什么？

我试过使用几个工具（apache bench，html_load），但它们只请求一个文件。

我正在测试捆绑策略，因此我需要该工具来下载原始 html 文件中包含的任何样式表、脚本等。即正是浏览器将加载的内容。

给定用户上传的图像，我需要创建它的各种缩略图以显示在网站上。我正在使用 ImageMagick 并试图让 Google PageSpeed 满意。不幸的是，无论quality我在convert命令中指定什么值，PageSpeed 仍然能够建议进一步压缩图像。

请注意，http ://www.imagemagick.org/script/command-line-options.php?ImageMagick= 2khj9jcl1gd12mmiu4lbo9p365#quality 提到：

对于 JPEG ... 图像格式，质量为 1 [提供] 最低图像质量和最高压缩 ....

实际上，我什至测试了使用 1 压缩图像（尽管它产生了一个不可用的图像），PageSpeed 仍然建议我仍然可以通过“无损压缩”图像来优化这样的图像。我不知道如何使用 ImageMagick 压缩图像了。有什么建议么？

这是测试我在说什么的快速方法：

在此先感谢您的帮助。

我一直在试验 YSlow 和 Google 页面速度，两者都提供了非常有用的建议，而且似乎都没有比另一个优势，但是当涉及到实体标签时，它们似乎在某种程度上存在分歧或冲突。以下代码满足 YSlows 'Configure entity tags (ETags)' 指针

然而，有了这个代码，Google Page Speed 提供了以下建议“指定一个缓存验证器”。另一位成员Aularon建议使用此代码来满足 Google 的要求

两者分别工作，但两种解决方案都不能满足两个验证器，所以我的问题是。

1. 我应该关心吗？
2. 两个验证器都有一个好的解决方案吗？
3. 这两种解决方案真的会产生重大影响吗？

我想遵循 Page Speed 的一项建议：Serve static content from a cookieless domain。因此，我需要将style.css文件从默认模板文件夹中移开，并将其放入我的无 cookie 域中。

我如何注意到 wordpress 的这种变化？

谢谢。

在尝试减小网页的 HTML 大小时，我遇到了 Google 和 PageSpeed Firefox Add-On 的建议，它们提高了 CSS 选择器的效率，这（几乎）让我重新考虑了这些更改：

http://code.google.com/intl/de-DE/speed/page-speed/docs/rendering.html#UseEfficientCSSSelectors

具体来说，后代选择器非常适合使用 ID 或 CLASS 属性选择整个块（例如 DIV），然后使其所有子元素都没有 CLASS/ID 属性。但如果应用规则的遍历顺序如谷歌所述，则不应使用它们：

后代选择器效率低下，因为对于每个匹配键的元素，浏览器还必须遍历 DOM 树，评估每个祖先元素，直到找到匹配项或到达根元素。密钥越不具体，需要评估的节点数量就越多。

我非常怀疑浏览器是否使用了如此低效的遍历顺序，当然它们只会处理与顶部选择器组件匹配的元素的子树，即#foo span {...} 仅应检查 #foo 以下的元素，而不是每个跨度。查看最近浏览器代码的任何人都可以确认/否认这一点吗？

第二个有问题的建议是关于过度限定的选择器：

ID 选择器根据定义是唯一的。包含标签或类限定符只会添加需要进行不必要评估的冗余信息。

如果 ID 选择器根据定义是唯一的，为什么浏览器需要检查冗余信息？我知道他们这样做是因为例如，

div#foo { 颜色：黑色；} #foo { 颜色：白色；}

会导致 a 中出现黑色文本<div id=foo>，但是 a) 它不应该完成（？需要 W3C 参考）和 b) 我不明白为什么当它导致对元素的简单 O(1) 检查时它会明显变慢标签名。

任何与现代浏览器源代码关系良好的人都可以阐明这些说法吗？由于大多数现代网站都使用后代选择器（包括 SO）并且它们具有明显的优势，所以我非常想使用它们......

编辑：

我对生成的页面进行了一些实验，似乎浏览器对后代选择器的处理确实很可怜：

包含（缩写）的页面：

#top a {文本装饰：无；}

#foo1 a.foo {颜色：红色；}

#foo2 a.foo {颜色：红色；}

[...重复 10000 次]

<主体标识=顶部>

<div>...[嵌套 50 次]<a href=foo>bla</a></div>[...]

[上一行重复 10000 次]

（基本上 10000 行，每行有 50 个嵌套的 div，要遍历到根节点和 1 个匹配的 10000 个选择器）

使用 Safari 5 在 2.2 秒内加载和呈现（直到window.onload()执行的时间），使用 Firefox 3.6.10 只需不到 10 秒。

当.foo从非应用规则中删除类选择器时，页面在 Safari 5 中大约需要 200 秒，在 Firefox 3.6.10 中大约需要 96 秒。这说明了后代选择器的实现有多么糟糕（在这种情况下，10000 条规则中的每一条都可能导致遍历到#top，在该规则失败的地方）。

儿童选择器的表现如何？#foo > span > div > div > div > div > div a {color: red;}（也从不匹配，但强制遍历 6 个父节点）使用 Safari 5 需要 27 秒，使用 Firefox 3.6.10 需要 31 秒。

结论

后代选择器和子选择器目前在主流浏览器上都很糟糕。如果您关心速度，最好为所有样式标签添加丑陋的 class/id 属性，至少对于非常常见的 HTML 标签（如 a、img、div 等）。

如何尊重 IIS6 中的“从无 cookie 域提供静态内容”页面速度规则？