对“display:none”是否有合理的限制？预加载？
我正在设计一个单页网站。站点的所有部分都以 DIV 元素的形式弹出，因此它永远不会离开实际的浏览器页面。最初，我使用“display:none”用 css 隐藏了所有部分，并且导航相应地显示和隐藏它们。
现在我开始整理作品集部分，我开始想知道是否最好对每个作品集项目使用 AJAX，因为它们包含较大的图像。对于预加载的合理限制有什么粗略的指南吗？如果所有项目都已预加载，则 HTML 文件看起来会相当巨大。
我意识到这是一个有点普遍的问题，感觉预加载所有内容是一个坏主意，但我不想凭直觉进行。我不太确定当元素设置为“display:none”时用户计算机会占用哪种资源（例如，这是 RAM 问题吗？）。
干杯! :)
I'm designing a single page website. All the sections to the site pop up modally in DIV elements, so it never leaves the actual browser page. Initially I have all the sections hidden with css using "display:none", and the navigation reveals and hides them accordingly.
Now I've come to putting together the portfolio section, I'm starting to wonder whether it would be best to use AJAX for each portfolio item, as they include larger images. Is there any rough guide to what's a sensible limit for preloading? If all the items were preloaded, the HTML file would look quite monstrous.
I realise this is a bit of a general question and it feels like preloading everything is a bad idea but I don't want to go on a hunch. I'm not quite sure what sort of resources are taken up with the user's computer when elements are set to "display:none" (e.g. Is it a RAM issue?).
Cheers! :)
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（3）
正如 @Digbyswift 提到的，拥有一个包含大量元素的大型 HTML 文件会增加页面大小，从而影响整体加载时间。
对于较旧的浏览器，页面上的元素数量会产生更明显的影响，但您必须达到数千个元素的范围才能开始达到上限。
对于现代浏览器，你的元素计数上限没有那么低，所以你应该没问题，但同样，如果你与元素进行大量 JavaScript 交互，它会减慢功能较弱的客户端的速度，例如作为移动设备。
在我看来，您面临的最大的权衡是，通过使用一个更大的页面而不是一堆单独的调用，您可以有效地用单个服务器响应的大小与响应的数量进行交换。需要较小的反应。根据您的具体情况，它可能是一次有益的整体交易，也可能不是。
我想说，您需要测试它所带来的差异，并以此为基础做出决定。会影响这一点的一件事是对响应使用压缩（又名 GZip 或 Deflate）。
另外，对于“作品集”，您提到有很多大图像。就我个人而言，我可能不会在该部分的 HTML 中包含实际的
![]()
As @Digbyswift mentioned, having one large HTML file with lots of elements increases the page size, which has an impact the overall load time.
For older browsers, the number of elements on the page had a _much_more noticeable effect, but you would have to get in to the 10s of thousands of elements range to start hitting the ceiling.
For modern browsers, you don't have as low of an element-count ceiling, so you should be fine there, but again, if you are doing a lot of javascript interaction with the elements, it will slow down less powerful clients, such as mobile devices.
The biggest trade off you are dealing with, in my opinion, is that by having one much larger page instead of a bunch of individual calls, you are effectively trading size of a single server response with the number of smaller responses needed. Depending on your specific case, it may be a beneficial overall trade, or it may not.
I would say that you need to test the differences it makes and base your decision on that. One thing that will affect this are using compression on the responses (aka. GZip or Deflate).
Also, for the "portfolio", you mentioned that there are lots of large images. Personally, I would probably not have the actual
<img />tags in the HTML for that section to prevent the browser from loading all of it initially and instead load the images in as needed by writing the elements in with javascript as those images need to be displayed. There are a number of techniques to do this, any you can add in more smarts around when the images get loaded, but reducing those large server calls will speed up the page a great deal. Likely even to the point that having one massive HTML page won't be a performance hit and will likely make it faster.将所有元素硬编码到 HTML 中的问题主要在于文件的大小以及用户下载该 HTML 页面需要多长时间。这取决于您的受众是谁以及您期望他们如何访问该页面。例如，大型 HTML 页面不适合移动设备。
但是，您需要权衡 AJAX 脚本所需的文件大小是否大于实际的硬编码 HTML。
The issue of hard-coding all the elements into the HTML is predominantly how large the file becomes and therefore how long it would take for a user to download that HTML page. It depends who your audience is and how you are expecting them to access the page. For example, a large HTML page isn't appropriate for mobile devices.
However, you would need to trade off whether the AJAX script required amounts to more file size than the actual hard-coded HTML.
首先，现代浏览器（如 Firefox、Chrome、IE...）拥有巨大的内存。用户可以更轻松地设置它......
在移动浏览器中，他们限制了大约10MB。您可以在此处阅读有关限制内存的更多信息： http:// /www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/
First, there are a huge memory on modern browser (such as Firefox, Chrome, IE,...). Users can set it more and more easily...
In mobile browsers, they limited about 10MB. You can read more about limit memory here: http://www.yuiblog.com/blog/2010/06/28/mobile-browser-cache-limits/