0

NSFW：请注意该网站出售大麻种子，因此链接是 NSFW。

我有一些网站在相同或非常相似的系统上运行，除了一个之外，它们都运行得非常快，我无法弄清楚为什么，我相信这主要是由于我的经验不足，但我已经查看了 Firebug 的 Net 选项卡我不确定我是否完全理解它。

我可以看到其中一个快速网站的产品页面大小和内容为 80.33kb，这需要 1.28 秒的等待和 598 毫秒的加载才能显示，而慢速网站的大小为 22.87kb，内容为 158kb 和有 4.75 秒的延迟，其中 4.55 秒正在等待。

我真的很想知道如何减少等待时间以及为什么大小和内容数字如此不同。您可以在此页面上看到问题。

4

2 回答 2

2

在整个页面中，你有一个名副其实的 JavaScript 垃圾。

目标是在不使用 JS 的情况下尽可能多地进行物理加载，然后在最底层完成所有 JS 加载。

你也有很多不同的 JS 脚本。喜欢……真的很多。

您可能会考虑弄清楚它们需要以什么顺序出现，然后按该顺序将它们粘贴到一个文件中（或六个文件或其他文件，但 Google 建议该页面上有几十个 JS 文件)，然后将其加载到页面底部。

这可能意味着您需要了解更多关于延迟加载页面上的内容的知识，这可能意味着您需要了解如何更多地分离关注点（我没有比您的标志进一步了解每个人都有一个 onclick 处理程序，这无疑做了一些巨大的事情——最好将一个侦听器添加到包含所有标志的容器中，然后识别它是哪个并从那里运行）。

但是当一个 JS 文件下载时，浏览器会暂停并编译它。这通常是几分之一秒。但是如果你有几十个文件，一个接一个，加载文件的暂停，访问文件内容的暂停，文件中的JS编译暂停，然后运行JS，之前继续展示网站的下一部分......

所以所有这些小停顿都在加起来。

这就是为什么你应该只提供你需要的 JS ，你应该在页面底部提供它，然后再加载一些不错的东西。编译一个包含数百行代码的文件，甚至比编译只有几十行代码的 10 个文件花费的时间更少。

最后，它归结为用户看到发生了什么，而不是下载的基准速度有多快。

于 2012-09-29T04:22:01.767 回答
1

查看使用开发人员工具中的 Chrome 网络选项卡加载的页面，我在以下链接中收到以下时间：

http://www.seed-city.com/barneys-farm-seeds/liberty-haze

102 requests | 131.24KB | 8.41s (onload: 8.50s, DOMContentLoaded: 6.61s)
102 requests | 131.47KB | 8.47s (onload: 8.56s, DOMContentLoaded: 6.82s)
102 requests | 131.45KB | 8.71s (onload: 8.79s, DOMContentLoaded: 7.06s)

现在，做一个（有点简单的）改变：

103 requests | 110.16KB | 3.77s (onload: 3.86s, DOMContentLoaded: 2.03s)
103 requests | 110.17KB | 3.85s (onload: 3.94s, DOMContentLoaded: 2.21s)
103 requests | 110.16KB | 4.20s (onload: 3.50s, DOMContentLoaded: 2.28s)

这是从当前页面的网络选项卡输出的典型 HAR 日志：

http://pastebin.com/pM5Dd1Fw

重要的部分是要意识到浏览器正在等待将近 5 秒钟甚至做任何事情（仅截断以显示相关行）：

{
  "startedDateTime": "2012-09-29T04:58:07.861Z",
  "time": 4831,
  "request": {
    "method": "GET",
    "url": "http://www.seed-city.com/barneys-farm-seeds/liberty-haze",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "cache": {},
  "timings": {
    "blocked": 0,
    "dns": 16,
    "connect": 129,
    "send": 0,
    "wait": 4677,        // <<< Right here
    "receive": 8,
    "ssl": -1
  }
}

以及slow.html页面的时间：

{
  "startedDateTime": "2012-09-29T05:04:51.624Z",
  "time": 92,
  "request": {
    "method": "GET",
    "url": "http://example.com/t/slow.html",
    "httpVersion": "HTTP/1.1",
    ...
  },
  "timings": {
    "blocked": 0,
    "dns": 7,
    "connect": 38,
    "send": 0,
    "wait": 44,           // <<< Right here
    "receive": 1,
    "ssl": -1
  },
  "pageref": "page_3"
}

那是4677msvs 44ms。这是该更新页面的典型 HAR 日志：

http://pastebin.com/Jgm1YyU3

那么我做了什么来实现那些（非常真实和切实的）改进？我将 Javascript 移到body标签的底部：

http://pastebin.com/H9ajG99H

这带来了两倍的改进。首先，您允许浏览器在开始与阻塞进程（script调用）交互之前继续并加载您的内容。因此，您的客户会“注意到”一个更快的网站，仅仅是因为页面似乎加载得更快（实际上您只是允许它在运行时加载）。其次，您要等到body标签基本上完全加载后，才开始使用它的内容。

看起来您没有在标头中使用缓存指令来告诉浏览器不要长时间检查文件的更新。所以你的 Twitter 和 Facebook 图标，看起来浏览器认为它需要重新检查服务器，所以理论上应该是不必要的，除非经常这样。但是“等待”的时间：

twitter_aqu_64.png 1.32s
ajax-loader.gif    1.31s
ssl-icon.jpg       1.31s

现在，我不是缓存控制方面的专家。这是一个有点黑暗的艺术。但是这些时间让我觉得那里可能会发生一些事情。

试试这个答案以获取有关缓存控制的更多信息：

HTML 缓存控件

于 2012-09-29T05:20:23.807 回答