在你回复之前，是的，我已经读过这篇文章。
我问题的区别在于，我不是在寻找最佳实践或互联网速度方面的考虑，而是实际的最大浏览器（或每个浏览器，如果你希望或必须具体）在崩溃之前可以处理，以及 php 引擎在崩溃之前可以处理的文件有多大。
原因是我正在为我工作的一家公司构建一个在线工作申请，并且我有很多必要的JavaScript验证（尽管，我将我可以放在外部js文件中）以防止垃圾邮件和滥用。我还将PHP与JavaScript交织在一起，以测试PHP是否处于活动状态，如果不是，则回退到JavaScript函数。我也有jQuery，MooTools等等。更不用说所有必需的问题，文本框，下拉列表，单选按钮，复选框和文本区域。
问题是我只完成了在线申请的一个部分，我的文件已经是 32 KB。考虑到我所做的工作量，以及我还有什么要做，我可以看到这个html/php（.php）文件很容易达到200KB +
所以我需要知道典型的HTML浏览器和服务器端PHP引擎的真正最大限制。
提前感谢，
-詹姆斯
我无法预见现代浏览器或服务器会分别在 200KB 的 HTML 或 PHP 上"窒息"。大型PHP应用程序接近兆字节，我见过带有兆字节标记的页面。
这里的问题是更多的代码组织。如果你把这么多代码放在一个文件中，可能是有问题。考虑使用像 PHP 的 include（） 函数这样原始的东西来拆分你的代码，或者像在众多 MVC 框架之一上编写代码这样相对革命性的东西来拆分你的代码。
这完全取决于浏览网站的计算机。在相当现代的PC上，您应该能够在浏览器遇到问题之前让您的脚本吐出几兆字节，而这些通常只是呈现页面的延迟。
在以前的工作中，我正在研究一台单核1.lownumber GHz Celeron机器[比你想象的要近]，它有WinXP和1.5GB的RAM。我正在实施一种垃圾邮件过滤产品，该产品不是为处理 10，000+ 域而设计的，因此，吐出标记超过 8MB 的页面。浏览器收到页面很好，没有抛出任何错误，但花了几分钟才显示页面。
大约一年后，当我得到一台新的双核Win7机器时，延迟甚至几乎不明显。
也就是说，每页 400KB 的数据并不可怕，但也不是那么好。我更关心的是放置在服务器上以生成如此多标记的负载，以及放置在网络上以交付标记的负载。您应该考虑减少每个请求 [分页，AJAX] 发送的数据量的方法，并重新评估用户在每个请求中真正需要看到的数据量。
-> 这是重要的一点。
不要依赖Javascript来防止垃圾邮件/滥用/无效数据和其他数据。它只能使人提供更愉快的用户体验。就是这样。
使用 PHP 脚本等来确保在服务器上存储适当的数据。
这是你的资产，人们也可以关闭/解雇JavaScript。
-> 您的服务器端对点击次数存在争议。只需监控流量