最大文件大小网站答案

【问题标题】：maximum file size website最大文件大小网站
【发布时间】：2014-01-28 12:48:32
【问题描述】：

我有一个简单的问题，它可能不是问它的正确地方，但我希望有人能帮助我，因为我很好奇。

我正在创建一个风格多变的单页网站（设计不适合网络并使用大量图像）这不是一个大问题，因为我们相信我们的目标是一个更有可能有种类的设计分支良好的个人电脑与互联网的连接非常好，并且该网站的大小缩小了很多移动设备。

但我仍然想知道人们推荐什么。我的网站目前加载时为 2.2mb（是否有一个网站可以检查这个 btw？我只是通过计算图像的文件大小等来猜测）我仍然可以优化很多，但我认为低于 1mb 是一个艰巨的任务。这足够好还是有谁经历过它不是？

提前感谢

【问题讨论】：

应该是 500kb。优化图片
我认为这不可能。有超过50张图片。并且每个页面都有一个全屏背景图像。它只有一个页面，因此所有网站内容都以 1 束的形式加载。
您可以查看Firebug、Chrome developer tools 的Net 选项卡，了解正在发出多少请求，以及页面的总大小。

标签： html web filesize

【解决方案1】：

如果用户体验不受影响，您不必担心网站的大小（尤其是在您了解目标受众的情况下）。但是，您应该在不牺牲设计的情况下尽可能优化一切。 Google's Page Speed 可能对您有很大帮助。他们甚至有您想要的总尺寸计算器。网上也有大量类似的工具。

另外，请阅读有关去年网站大小趋势的信息：http://www.theglobeandmail.com/technology/tech-news/bloated-web-pages-costly-for-smartphone-users/article9355125/

根据定期研究在线访问量最高的 10,000 个网站的网站 HTTP Archive 显示，现在平均网页大小约为 1.3 兆字节，比去年增长了约 35% .

更新

受@pwdst 的 cmets 启发，我想补充一点，如果您想要支持手机、平板电脑等...无需牺牲主站点的外观 - 您可以使用 media queries 并实际提供服务对这些用户的不同呈现。当然，您可以更进一步，为他们创建不同的网站（通常是子域）。

【讨论】：

无论骑手是谁，我都很难接受“您不应该担心网站的大小”——您是否排除了连接速度较慢的用户（例如 Edge 或 3G）、移动用户（数量惊人的美国人仅可以通过手机访问互联网）或其他市场。
@pwdst 我不排除任何人，但 OP 是。阅读问题中的目标受众。
我同意这是 OP 的选择 - 不过，这个答案鼓励而不是挑战这种选择。
@pwdst 这是我的意图，尽管我说他应该尽可能优化它。如果您正在制造/销售产品，您将尽最大努力为您的目标受众优化它，而不是在其他方面妥协（当然，如果您针对每个人，这是没有意义的，这就是您的目标答案是约，没关系）...世上没有奢华又实惠，有时你只需要做出选择并坚持下去。
我确实在使用媒体查询，我得到了每张图片的低分辨率副本，等等，这些副本将在较小的屏幕上加载

【解决方案2】：

如果您使用开发工具，例如在 Chrome 中，您可以在“网络”标签下查看请求数和传输的数据总量。为了准确地复制用户的体验，您应该使用空缓存来执行此操作 - 在大多数浏览器中，“隐身”或“私人”选项卡可能是执行此操作的好方法。还值得记住的是，本地测试的体验与延迟和上行带宽的影响发挥作用时的体验截然不同。

如果您想保持可用性，请非常小心对用户的假设。 “足够好”是非常符合上下文的，对于使用稳定 DSL 连接的台式机、笔记本电脑或高级平板电脑上的用户来说，它可能“足够好”——但除了手机上的 Edge 或 3G 连接之外的任何东西。应尽可能通过分析来自服务器日志或分析软件（如 Google Analytics）的用户代理字符串来支持假设。还值得记住的是，您的手机或平板电脑请求可能相对较少，不是因为手机或平板电脑用户不想访问该网站 - 或选择使用其他设备访问，而是因为这很难，缓慢甚至无法在他们选择的设备上使用。这个case study from an engineer at YouTube 说明了客户是如何被完全排除在网站之外的。

通常页面应该尽可能小，除了优化之外，您可能还想查看延迟加载，这将有助于初始渲染时间 - 公平地说，尽管您估计的大小不会比 Internet 存档大很多 @截至今年 1 月 15 日，987654322@ 为 1681kB。不要忘记，其他资源也可能使用大量空间——JavaScript 占该平均值的 274kB——并且不清楚您是否已将其计入您的估计中。积极使用缓存将有助于回访者并最大限度地减少这些情况下所需的数据传输。

我总是尝试考虑是否可以根据功能来证明页面重量成本是合理的。您网站访问者的目标是什么？添加的功能或图像是否有助于充分证明性能成本是合理的。许多以性能为导向的开发人员现在都在积极设置page weight budget，但这对于您无法对资源进行精细处理的单页应用程序来说更难。

【讨论】：

是的，谢谢你的好建议！加载在手机和平板电脑上的网站会更小。
@Merijndk 很高兴您发现此答案很有用 - 我添加了更多信息，可以帮助您评估页面大小的影响。

【解决方案3】：

我建议使用Image Pre-loading，它可以帮助您缩短页面加载时间，即使页面很大。

【讨论】：

我有点不同意。当您需要在内存中拥有在页面上不可见的图像（但在某些时候会变得如此）时，使用预加载。事实上，它们消耗了额外的带宽。
移动用户可能会讨厌你。 ;o) 如果他们有一个有限的网络计划，你会用他们可能永远看不到的图像来打破他们的限制。