NSFW :请注意该网站销售大麻种子,所以链接是NSFW。
我有几个网站运行在相同或非常相似的系统上,它们都运行得非常快,我不知道为什么,我相信这主要是由于我的经验不足但我已经查看了Firebug的Net选项卡,我不确定我是否理解它。
我可以看到其中一个快速网站的产品页面大小和内容为80.33kb,这需要1.28秒的等待和598ms的加载才能显示,慢速网站的大小为22.87kb和内容158kb,延迟为4.75s,其中4.55s正在等待。
我真的很想知道如何减少等待时间以及为什么尺寸和内容数字如此不同。您可以在this page找到问题。
答案 0 :(得分:2)
在整个页面中,您都有一个真正的垃圾邮件。
目标是在不使用JS的情况下尽可能多地加载,然后在最底层完成所有的JS加载。
您还有很多不同的JS脚本。 喜欢......真的很多。
你可能会考虑确定他们需要出现的顺序,然后按顺序将它们粘贴到一个文件中(或者半打,或者其他什么,但谷歌建议有几十个JS文件那一页),然后加载到页面底部。
这可能意味着您需要了解更多关于延迟页面上的内容加载的信息,这可能意味着您需要学习如何将问题分开一些(我没有看到比你的标志,看看每个人都有一个onclick处理程序,这无疑会做一些巨大的事情 - 最好将一个监听器添加到容纳所有标志的容器中,然后确定它是哪一个并从那里运行。)
但是当下载JS文件时,浏览器会暂停并编译所有内容。 这通常只是一小部分。 但是,如果你有几十个文件排成一列,一个接一个,加载文件暂停,访问文件内容暂停,在文件中编译JS暂停,然后运行JS,继续展示网站的下一部分......
所有这些小停顿都在加起来。
这就是为什么你应该只为你 需要 提供服务的JS,你应该在页面底部提供它,然后加载好的在那之后有一点东西。 使用数百行代码编译单个文件,比编译只有几十行的10个文件花费的时间更少。
最后,它归结为用户 SEES 发生的事情,而不是下载基准测试的速度。
答案 1 :(得分: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)
现在,进行一次(somewhat simple)更改:
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)
以下是从当前页面的“网络”标签中输出的typical HAR log:
重要的是要意识到浏览器正在等待将近五秒甚至做任何事情(仅剪切以显示相关行):
{
"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"
}
那是4677ms
vs 44ms
。以下是该更新页面的典型HAR日志:
那么我做了什么来实现那些(非常真实和有形的)改进呢?我将Javascript移到body
标记的底部:
这提高了两倍。首先,您允许浏览器在开始与阻止进程(script
调用)交互之前继续并加载您的内容。因此,您的客户将“注意到”一个更快的站点,因为页面似乎加载速度更快(当您真正只是允许它加载时)。其次,在开始使用它的内容进行修改之前,请等待body
标记基本上完全加载。
看起来您还没有在标头中使用缓存指令,这些指令告诉浏览器不要长时间检查文件的更新。所以你的Twitter和Facebook图标,看起来浏览器认为它需要重新检查服务器,从理论上讲,往往应该是不必要的往返之外。但是花在“等待”的时间:
twitter_aqu_64.png 1.32s
ajax-loader.gif 1.31s
ssl-icon.jpg 1.31s
现在,我不是缓存控制方面的专家;这是一个黑暗的艺术。但是那些时间让我觉得可能会有一些事情发生。
尝试此答案以获取有关缓存控制的更多信息: