Optimization 我的索引页是否太大？

我现在正在开发一个网站，我已经工作了一年多了。今天，我离发布还有一周的时间，所以我开始复习去年没有复习过的东西，包括加载时间。我没有注意到任何加载问题，但我仍然想看看

以下是我的索引页：

Documents (1 file) 22 KB Images (53 files) 96 KB Objects (0 files) Scripts (9 files) 90 KB - Including jQuery.min.js Style Sheets (6 files) 23 KB ------------------------------- Total 230 KB 我们不再生活在56k和28.8的世界里，但我想知道今天什么应该被认为太大了。我还应该提到的是，分析报告显示，我的访客中有3.28%有拨号上网。这些用户当前浏览的索引页大小为158kb

其他有趣的索引页大小：

谷歌：20kb 亚马逊：525kb 堆栈溢出：121kb Digg:58kb 修订3:936kb

---

这是相当大的，但除非它成为问题，否则我不会认为它是个问题。在任何情况下都要小心过早的优化。

这不是一个直接的答案，但网站上充斥着关于前端工程问题的文章和提示，这些问题可能会影响用户对网站加载时间的感知

---

特别是，我建议可以减少HTTP请求的数量——例如，6个样式表和59个图像——也许其中一些图像可以减少这个数字？

我完全同意。不幸的是，开发过程是敏捷的，很遗憾，大部分布局都是临时决定的。我想回去缩小我的.css文件，然后在可能的情况下加入，并在时间允许的情况下精灵化多个图像。你忘了敏捷开发的重构部分了吗？@webdtc-我是这个项目的唯一开发人员，目前由高层管理层提供支持。在上面添加一些包含X信息的内容，这些信息描述了我每周（有时是每天）收到的需求类型：我不是故意被嘲笑的。我发现大多数真实的项目不能遵循理想的流程。尽管如此，这将是一个很好的时机向高层管理人员指出，嘿，页面之所以庞大，部分原因是因为流程。。。如果你想：顺便说一句，我不认为页面太大。你已经尽可能缩小了图片了吗？PNG和减色是你的朋友。但毕竟：这就是缓存在第一次加载后的用途：PS：我提到图片，因为通过自动转换发送所有图片并将其与版本进行比较是我尝试的最便宜的优化。尤其是当它们占到了所有负载的三分之一时。@Leonida，我优化了我的大图像。我有一个.png，是50kb。现在大约是9kb。不过，我确实想稍后尝试一些精灵。