自从上次帖子 有点失败 （不过结果很好！） - 让我们马上开始下一个投票。我们会保持相同的思路：页面大小，这次是关于整个页面。
很久以前，Google 曾经 只索引页面 100k （虽然我认为这只是 HTML），但现在情况已经不同了。整个页面的 200k（包括所有资源：css、图片、js 等）曾经是一个常见的目标。我想说，现在很少有网页能低于 200k。
所以，新的投票是
您认为对于现代网页设计而言，合理的目标页面大小是多少？
此投票和所有帖子投票的完整实时结果都在 投票存档 中。
最新投票：理想页面大小
Chris Coyier 于 发布
DigitalOcean 为您旅程的每个阶段提供云产品。立即开始使用 免费赠送 200 美元信用额度！
这取决于，如果您的网站是博客，那么由于图片，它将是 600KB 以上，如果您的网站是 Web 应用程序，那么您的大多数资源将集中在 javascript 和 css 上，400KB 以上，并带有图片资源。如果是项目页面之类的，它可能需要更少的组件，我猜是 100KB 以上。
我认为您需要将其拆分为移动网页大小和桌面大小。但是，即使页面是 2MB，但它在几秒钟内加载，这重要吗？
什么？
我认为 John 说得对。我的总页面大小约为 1.7MB，但它在 1.63 秒内加载完成。因此，如果它在几秒钟内加载，那么大小并不重要。根据这份报告，CSS-Tricks 重约 645KB，但它在 2.66 秒内加载完成。
http://gtmetrix.com/compare/qjcxT4I7/CWlM1LUN
但我仍然认为，对于现代网页设计而言，合理的页面大小约为 500k，包括资源。
2MB 在几秒钟内加载，这是假设所有访问者都拥有最高带宽速度，更具体地说，反映的是您自己的连接速度，而不是您的访问者的连接速度。
为所有访问者优化加载时间，无论连接速度如何，都是良好的实践，就像可访问性一样。
”我的总页面大小约为 1.7MB，但它在 1.63 秒内加载完成。”
您是否曾经想过那些网速慢的人，他们永远也看不到您的网站……只是说一下……
保持较低！css 雪碧，少量的 http 请求，良好的缓存等……
例如，尝试模拟它 (http://www.dallaway.com/sloppy/)
很难用通用的术语来谈论这种事情，因为我认为这只是众多情况之一，其中上下文将决定结果。您是否希望拥有很多移动设备/低带宽用户？或者，主要目的是高度视觉化的图形体验，还是与大量内容相关的东西？是否涉及 Flash 或音频/视频内容？
无论如何，无论如何，我选择 1MB 作为要努力达成的相当宽松的限制。如果超过这个限制，用户可能需要等待很长时间才能加载页面，这可能会让他们非常恼火。
对于未知页面 - 也就是说，用户不确定页面内容的页面，我目标是 100K。超过这个限制，下载所有内容所需的时间太长。
我意识到大多数人拥有快速连接速度，但这并不意味着您需要使用它。更快的速度应该使用户能够更快地浏览互联网，而不是以更漂亮的方式查看相同数量的内容。
对于用户知道自己将要看到的内容的页面（例如：指向我的照片库的链接），则没有限制。
我认为这不仅仅是页面大小的问题。从技术角度来看，您至少应该考虑大小和请求数量。
然后，这取决于（如其他人提到的）网站的类型。
我认为，对于网站的平均着陆页，一个好的经验法则是大约 200-300k，最多 20-25 个请求。
好吧，理想的页面大小应该是尽可能低，也许是 300k（这很难实现），但实际上，它通常在 500k 到 700k 之间
在今天这样阴天的情况下，在一栋两层楼的密集砖钢建筑的一楼内部，我的智能手机的 3G 信号有 3/5 格。我的速度测试结果表明我的下载速度在 600kbps 到 800kbps 之间。如果我移动到能够获得 4 或 5 格信号的地方，它会跳到 1300kbps 到 1800kbps 之间。我们在这里谈论的是 DSL 和/或 T1 速度，对于大多数住宅宽带来说，这相当保守。
这意味着，在 3 格信号下，我将在 20 秒内下载 2MB，而在 4 到 5 格信号下，我将在 10 秒内下载它。
我投票选择 2MB，基于这些结果。
在我的国家，大多数乡村地区，只有 500kb/s 的 DSL 速度是常态，而且这是针对桌面环境的，并且要在整个房屋中共享。我独自一人住，在我的 8/1MB 连接上，最大速度为 480kb/s。
太糟糕了。最近的研究表明，许多移动用户在页面加载超过 3 秒时就会停止加载。即使认为这是错误的，您也正在谈论将用户放弃您网站的时间从三秒增加到六倍，考虑到放弃是指数级增长而不是线性增长，这是一个**大量**的潜在损失访问者。
LOL WOWW！！页面加载需要 20 秒？！我放弃！如果网站在我的 DroidX 上没有在几秒钟内加载，我就离开。我无法想象等待 20 秒才能加载一个网站，这太不可思议了。我在 Verizon 上使用 3G。我相信我的 Comcast 是 16mb/s 下载速度，实际情况下我得到的速度在 1.8mb/s 到 3mb/s 之间（根据我的经验），也许我的下载速度是 12mb/s 而不是 16mb/s，我忘了，但我投票选择 350kb。再说一次，这取决于它是否是一个有很多文章图片的博客，或者它是一个需要大量图片来娱乐的互动儿童网站。
很棒的博客
我认为这取决于很多因素。
您的分析数据显示的与用户连接速度相关的信息。您显示的内容的上下文。以及您针对的目标设备。
根据研究，如果页面在 4 秒内没有加载，用户就会离开页面，因此，在这个时间限制内完成加载的任何内容都很好。由于这个加载时间取决于网络速度，所以归根结底是您要缩小页面大小，还是制作一些令人惊叹的内容（这样用户就不会离开您的页面）。我个人认为，任何低于 500Kb 的内容都很好。
附言：我什么时候开始关心 CSS-Tricks 的加载时间
我记得是 3 秒规则，这是针对加载页面和熟悉页面结构而言的。超过 2 秒的时间 simply 不可接受。
越快越好，但对于非移动网站，低于 500K 并不现实，因为您通常已经在框架代码中拥有几百 KB。
但当然，如果没有上下文，投票本身毫无意义。连接速度、延迟、设备、受众……所有这些都需要考虑。如果世界上有一半的人正在观看 Youtube，每秒几百 K，您不能说您需要低于 100K。
什么框架只有几百 KB 的代码？
真正重要的是页面加载方式。比较以下几种情况：
1. 你等了 10 秒，屏幕一片空白，然后整个页面突然出现。
2. 文本内容在 1 秒内出现，但你无法正常阅读，因为它是米色背景上的白色文字。5 秒后，深色背景图片出现，你可以阅读文本。再过 4 秒，整个页面加载完成。
3. 文本内容在 1 秒内出现，你可以阅读它。3 秒后，一些 JavaScript 代码重新排列了页面布局，你失去了阅读的线索。再过 6 秒，整个页面加载完成。
4. 文本内容和布局/样式在 1 秒内出现（所有装饰都使用 CSS3，而不是图片）。加载大型内容图片以及引入一些 JavaScript 交互还需要 9 秒，但页面不会跳动。
所有这些页面都需要 10 秒才能加载；它们甚至可能具有相同的 HTTP 请求数量。但情况 (4) 的体验要好得多。
我同意你的观点，Mike。我为第三世界国家客户设计网站——每次都必须是情况 (4)。我们处理的下载速度从 56Kbps 到 1Mbps 不等。[注意，该地区的上传速度永远不会超过 128Kbps]。从一开始，一切都必须清晰易读且稳定。
大多数这里的客户都想要花哨的装饰，但不愿意接受第三世界基础设施的限制。所以我们投入了大量精力，确保即使在 56K 连接下，页面也能在几秒钟内加载。而且看起来也很不错……
对我来说，最糟糕的是等待外部链接……在“正在等待https://#”和“正在等待 platform.twitter.com”等消息出现时，页面冻结了 15-20 秒，真是令人作呕。
这种延迟对网站所有者来说是值得的——她获得了统计数据、广告收入、工具栏等，而且她已经获得了我的访问量，但她也失去了我。如果这对她很重要，她可能需要重新考虑。
我可能会回来，但我的心情不会像我控制浏览器后，所有这些内容都加载完一样愉快。
我认为，一个更重要的考虑因素是页面不包含内容的重量。内容会极大地影响页面加载速度，而且通常超出前端设计人员的控制范围。当然，我们可以做出相应的准备，但有时客户坚持上传包含 25-30 张图片的页面。
然而，网站布局是最能提高加载速度的地方。网站真的需要那个巨大的背景图片吗？它真的需要加载包含整个网站中每个页面上所有样式的庞大样式表吗？它真的需要加载 jQuery，因为你写了一个只有 10 行的脚本，而这个脚本是用 jQuery 编写的吗？
就我个人而言，除非设计极其丰富，否则我会努力将布局的加载重量控制在 150 KB 以内。如果可能，我会将大多数设计的加载重量控制在 100 KB 以内。
向那些强调时间重要性的人致敬。我们必须以符合接收者对特定任务期望的方式来构建网站和应用程序。
大小仅在大小影响时间的情况下才相关。当用户必须等待才能可视化、阅读和交互时，我们更有可能失去他们。
~ Dao
P.S. 非常棒的话题！
我认为 350 KB 对加载速度来说很不错。
页面重量远没有加载速度重要。
如果你有一个网站，包含 1000 张图片，每张图片大小为 100 字节，这可能比一张 1 MB 的图片花费更多的时间。
假设下载每张 100 字节的图片需要 0 毫秒，但你每次请求的平均延迟为 25 毫秒（延迟显然取决于你的位置）。现在，下载所有 1000 张图片（总重量只有 10 KB）需要 2.5 秒。
在现代互联网连接下，你可以在 1-2 秒或更短的时间内轻松下载 1 MB 的图片。
所以，基本上，你可以有一个 10 KB 的页面重量，但仍然需要很长时间才能加载。
这是我的两分钱。
你需要考虑很多变量（人口统计学）。不过，这主要取决于你典型用户的连接类型。
针对移动用户的网站应该很小（我认为最大为 100 KB）。针对海外移动用户的网站应该更小（漫游费用）。拨号连接的桌面用户（是的，他们仍然存在），请将页面重量控制在 250 KB 以内？对于有线/DSL 连接（带宽有限），我建议控制在 1 MB 以内。对于其他情况，则没有限制。
所以，基本上，你需要调查目标受众并根据他们的情况进行调整；没有一个答案是正确或错误的。
当你提到“现代网站”时，我假设你指的是使用 jQuery、CSS3、HTML5 等技术。因此，对于稍微大一些的 CSS/JS 文件来说，可以大幅减少图片的使用。我认为 350 KB 应该是当今大多数网站的平均最大值。总的来说，重要的是用户加载时间，即使服务器负载对我们开发者来说非常重要。就我个人而言，我喜欢将所有内容都做成 AJAX。网站实际上只有一个索引页面，所有内容都是通过 AJAX（从数据库检索数据）和 jQuery（从外部文件加载静态 HTML，并解析/使用通过 AJAX 从服务器接收的数据）动态加载的。尽管这会让搜索引擎的索引变得很混乱，但它对用户加载时间和服务器负载都有极大的帮助。也就是说，我的最新作品已经有数千行代码，而且界面非常漂亮，但只使用了一张横幅图片（而且这仅仅是因为这是一张地方的照片）。整个网站目前的加载量约为 50 KB，不包括图片，图片为 350 KB。目前，图片保持高质量，而且相当大。它可以轻松缩减到 250 KB，而且仍然看起来不错。但最好的地方是，无论浏览器缓存如何，它都只加载一次，这得益于全 AJAX 架构。
页面加载所需的时间不是真正的问题，真正的问题是页面交付用户想要的内容所需的时间。举个夸张的例子：如果用户正在寻找“法国度假”，那么旅行网站的主页即使在 60 秒内加载，只要顶部导航栏（显示“法国度假”）在 1 秒内显示出来，这并不重要。
我会尽力尽快交付页面的内容，目标是小于 300 KB。如果一些非必要内容（图片、JS、页脚下的内容，如评论）增加了额外重量，但稍后加载，那也很好。
当然，它不应该大于必要的大小。这不仅是为了你的用户，也是为了你。你也在浪费带宽。你消耗的带宽越多，你就能支持的并发访问者就越少。
我经常在广播中听到人们谈论一个有趣的网站，然后不久他们就宣布它“崩溃”了。
有了 CSS3/HTML5，即“现代网站”，你可能会发现自己需要更少的图形资源来满足网站的审美需求。
我能理解，大多数人生活在发达国家，拥有高速宽带，或者至少在英国，宽带速度越来越快。
不过，值得指出的是，万维网是全球性的，如果你的页面要成为万维网的一部分，你就不能仅仅对 2 MB 的页面置之不理，因为它们在很多国家根本无法正常工作。
一如既往，这一切都取决于你的访问者、你的目标受众、你提供的内容类型——但不要忘记，你很幸运拥有高速宽带。
我想平台很重要，尽管在任何情况下，越轻越好。我认为现在没有人会介意在台式机上加载 1-1.5 MB 的网站。
然而，随着响应式设计热潮的兴起，尤其是对移动设备和移动网络的关注，我开始更详细地审视自己的网站。
即使是图形丰富的网站，你也能从中节省出大量的 KB，这令人惊讶。我为一个相当重要的品牌做的最后一个项目，页面上也有一些大图片，但总共只有不到 350 KB，我对此感到非常自豪。我希望为移动布局进一步精简内容。
具有讽刺意味的是，该项目中最大的文件是 jQuery，大小为 91 KB。这让我开始考虑是否应该寻找一个更轻量级的 JS 库。
说实话，我认为我更多地使用 jQuery 是因为它提供了选择器引擎，而不是其他功能，但当网站的其余部分只有 350 KB 时，91 KB 似乎有点过分了。
如果你压缩了页面，jquery-min 只有 39 KB。
如果你只使用 jQuery 进行选择，那么 sizzle.js（jQuery 的选择器引擎）可能是你的选择。
值得注意的是，如果你屏蔽广告，CSS-Tricks 主页的体积将低于 500k。
根据我的经验，Flash 和高细节广告往往会占用大量的带宽。例如，CSS-Tricks 主页的体积会增加 30%。
…我的答案是，每个页面应该控制在 1MB 以内，对于移动设备，应该控制在 500k 以内。但说实话，这取决于页面的具体用途，如果页面是图片库，那么如果所有图片都加载完，页面体积可能会达到 1-2 MB。我想，最好的做法是尽可能地按需加载内容。
加载所需的内容，以所需的压缩分辨率加载，将脚本和样式表压缩，并缓存所有内容，以降低服务器负载和延迟。
好吧，这很大程度上取决于网站内容，不考虑设计（即页面设计中的 CSS、HTML、脚本和图片）。主要内容决定了大小，所以很难说——包含 6-10 张图片的页面很难达到任何合理的限制（每张图片 50k * 6 = 300k，仅仅是图片就占了这么大），更不用说广告、视频等等…
一个更好的问题是，网站在没有“实际”内容的情况下的大小——仅仅是设计部分，因为其他部分实际上取决于客户希望网站的内容是什么。
即使在这里，正如之前指出的，加载时间才是真正重要的因素，而不是大小。
作为一名开发者，我试图将页面大小限制在 250-350 KB 之内。我认为这应该是最佳的。
我担心你可能通过提供 CSS-Tricks 页面的大小影响了调查结果。
国际网站 = 低于 500kb。
面向美国/欧洲和其他网络连接良好的国家/地区的网站 = 大约 2mb 以上。
这就是我的想法。
越小越好。图片可以优化，CSS/JS 可以压缩，资产可以 gzip 压缩，大型 JS 库可以替换为更小的库。如果一个页面超过 500K，那它就太大了。
我绝对同意 Avi 的观点 ^。我惊讶于有那么多人认为页面大小超过 1 MB 是可以接受的。
你在开玩笑吗？也许是图片库页面。但首页或其他频繁访问的页面？绝不可能。很多人仍然使用 3G 调制解调器甚至更糟糕的卫星互联网——任何超过 350KB 的页面都太大了。
减少图片，有时你可以对 jpg 图片进行更多压缩。这不仅仅是关于整体大小——人们总是过度使用单独的请求。将所有内容使用 CSS 雪碧，并且请将 15 个以上的 JS 文件合并起来。
如果我在 10 秒内无法加载一个网站，我就不想再看它了，即使我使用的是 HughesNet。就这么简单。
这篇文章让我回去检查了我最近完成的两个项目以及正在进行的一个项目。我不知道这个问题的正确答案（如果有的话），但我明白我应该为自己的网站做更多的事情来优化它们。感谢这篇文章。
一切都是为了你的用户。使用 Google Analytics 检查网络速度并阅读这些统计数据。如果你的用户群使用的是慢速连接，或者使用的是移动设备，那么就针对这种情况进行优化。
正如之前有人提到的——很难笼统地谈论这个问题，因为大多数关于交付的决定都取决于你的用户群。如果你要发布一个新网站，并且没有统计数据可供分析，那么可以看看你的竞争对手（那些排名靠前的网站），并以他们的网站为参考。
用户是关键。不要忘记他们，否则你会付出沉重的代价。
在大多数情况下，我努力将页面大小控制在 500kb 以内。
尽可能小——尽可能大！
妙极了！！
我将你的话语视为我的话语。
这正是我在深入思考后想要分享的智慧之言！
Martin，说得太好了！
我对这方面了解不多，但我肯定意识到我的页面很臃肿。这让我感到不舒服。Google 希望我们检查我们的页面，为什么？他们知道，如果用户加载页面需要太长时间，他们就会跳过我的页面。他们还知道，尽管更快速、更高效的设备不断涌现，但互联网整体速度会越来越慢。我记得从 Google 那里读到，未来互联网速度会变得如此之慢，以至于臃肿的页面将无法加载。这就是 Google 希望我们关注加载时间、将臃肿的页面转换为简洁流畅的 HTML 等等的原因。
这让我好奇，如果浏览器现在已经可以处理来自服务器的压缩内容，并且新技术将由此产生，那么臃肿页面的问题将会变得多么重要呢。
我认为这都是相对的，例如，我最近为一个客户做了一个网站，网站大小是 3mb，但加载时间不到 2 秒。大部分内容只在需要的时候才会被调用。加上 CSS3 和 HTML5 的帮助。
这还取决于人口统计，例如，我的客户的客户群不会是发展中国家的人，因为他们销售的产品和服务就是这样。所以，即使在慢速互联网连接下，网站加载时间需要 20-30 秒，他们也很有可能不是他们想要的客户。
但这并不妨碍我想要为了最佳性能进行调整，这只是良好的做法，但你必须知道在哪里划定界限。
Qwik.Vu (http://qwik.vu/) 包含所有内容，大小为 518 kB，而且它的首页非常复杂。
我认为这是一个很好的例子。
在制作网站时，我追求两个目标。一个是文件大小，另一个是请求数量。
你可以做一些事情来减少它们。我喜欢使用 ImageOptim，这是一个可以从 PNG 图片中去除冗余数据的程序。它非常有效。我还会避免使用质量为 60% 或更高的 JPEG 图片。
然后，我会尽可能地缩短代码，并在上传之前压缩文件。我尽量使用较少的字体，并将脚本设置为动态。如果你在首页上，就没有必要加载“联系我们”脚本。
我认为 350-500k 是可以接受的。对于那个说 2mb 很好的家伙，抱歉，你是在用自己的良好网络连接说话，但不是每个人都有。
同意其他人的观点，这取决于很多因素。
* 你的服务器管道和带宽限制
* 你的用户的管道和带宽限制
* 传达信息所需的带宽
* 传达信息所需的设计带宽
我投票给尽可能小。
允许客户自定义/选择他们得到的内容并将其存储在 cookie 中。可以在两端节省带宽。
我说 500k，因为我曾经在爱达荷州一个小镇开发网站……天哪，我们的互联网速度太慢了。
最终，这不仅仅是关于页面大小。它应该是关于你如何优化资源以提高加载效率，需要多少个请求以及文档完成的时间。我在这里写了一篇完整的回应：http://dyn.com/web-development-best-practices-whats-an-ideal-page-weight/
它实际上是关于请求而不是页面大小。在“一个网络”的世界里，我认为目标是 500k 以内，700k 以内是可以接受的。如果这是一个以桌面为主的网站，我认为 1mb 以内是可以接受的。
这确实取决于很多因素。我最近做了一个网站，我用 css3 渐变替换了大量的图片，并且首页只有 200k，包括内联图片资产（我不算它们，因为它们是渐进加载的，与 CSS 图片不同）。YSlow 是处理此类问题的最佳工具，还有 CSS 雪碧。让 IE 用户下载图片，让其他网络用户使用现代 CSS 规则来节省请求！（我还没有测量 IE >9 和 FF 中的页面加载时间，但说实话，如果你使用的是 IE7，你能指望什么呢？）
这显然与你的受众相关，如果你是一个高清视频网站，那么你可以有更大的页面大小，因为你的主要内容是高质量视频，但对于新闻网站来说，你显然希望它更快，否则用户就会去其他地方。
我喜欢凯文·罗斯的foundation.kr新设计，但如果我尝试从安卓手机访问它，它只会把我指向iTunes，因为它甚至没有尝试假装它对移动设备友好。
理想情况下，我和我的团队尽量将页面大小控制在500k以内，包括图片。超过这个大小，我们会使用预加载器。这适用于Flash和JS项目。
这里有一些统计数据。 网页指标：大小和资源数量
它应该最大为450k，并且必须在2秒内加载完成！