Question

现在（V8）Chrome和（SpiderMonkey）Firefox的JS Dom遍历相对较快：有没有理由不通过javascript动态加载网站内容？

我正在考虑在显示加载栏时使用Javascript请求大文件（图像等）。有没有理由不动态加载大型JS / JPG文件？

我经常不经常看到它，并希望这样做并不是一个大错误。

Answer 1

这取决于它是客户端还是服务器端，类似于node.js。

如果它是客户端，取决于同时进行多少次双向请求调用，它可以在访问者的计算机上使用很多RAM。

您基本上将图像/数据/流处理大量卸载到用户的计算机/平板电脑/手机与服务器之间。

Answer 2

如果您特别担心图像，有很多方法可以推迟加载，直到需要图像为止。您可以避免加载源，直到图像在视图中。例如，使用微小的透明图像作为源，并将真实源存储在数据属性中：

<img src='data:image/gif;base64,R0lGODlhAQABAAAAACH5BAEKAAEALAAAAAABAAEAAAICTAEAOw==' data-src='/path/to/real/image.jpg' />

然后使用jQuery inview插件加载屏幕上显示的图像：https://github.com/protonet/jquery.inview

$('img').on('inview', function(e, isInView) {
  if ( ! isInView ) return;

  $(this)
    .unbind('inview')
    .attr( 'src', $(this).data('src') );
});

我不知道你为什么要推迟javascript;如果你有数百千字节的javascript文件，那么你可能做错了。

Answer 3

另一个是延迟。我们习惯于能够ping世界的另一端，并且能够很快收到响应。我在600毫秒的avg上得到了一个ping响应。

C:\Users\enhzflep>ping www.stackoverflow.com

Pinging stackoverflow.com [198.252.206.140] with 32 bytes of data:
Reply from 198.252.206.140: bytes=32 time=809ms TTL=38
Reply from 198.252.206.140: bytes=32 time=501ms TTL=38
Reply from 198.252.206.140: bytes=32 time=493ms TTL=38
Reply from 198.252.206.140: bytes=32 time=630ms TTL=36

通过卫星连接，您可以查看一秒钟 - 这意味着您希望尽可能批量处理您的请求。即使页面为200字节，AJAX内容为200字节，您也会看到超过2秒的页面加载时间。听起来很有趣吗？

有没有理由不动态加载网站内容

3 个答案: