文档中的最后一张图片加载失败 - “加载资源失败”

Posted 2023-02-24

【中文标题】文档中的最后一张图片加载失败 - “加载资源失败”

【英文标题】：Last Image in Document Fails to Load - "Failed to Load Resource"

【发布时间】：2011-06-28 13:44:22

【问题描述】：

刷新后网站的初始页面加载出现问题。我使用 Chrome 进行开发，但问题在所有浏览器中都很明显。

我收到消息“正在等待 mysite.com...”，并且加载指示器一直在旋转。这会保持这种状态大约 10 秒，然后 Chrome 放弃并从开发者控制台中告诉我“无法加载资源 'foobah.png'”。图像肯定在所述路径上。有时它加载有时它没有。如果我完全删除对该图像的引用，则错误将落在页面内的不同图像上。这是一个常规但间歇性的故障。

我的网站大量使用 javascript（2500 多行），我怀疑这可能与以下两者有关：

Javascript 加载干扰 图片加载。 发生了一些有趣的事情 图片的缓存。

有人遇到过此类页面加载问题吗？

感谢您提供的任何帮助！

示例网址： http://dev.thebeer.co/imgs/UI/inboxIcon.png

Chrome 开发者工具界面：

更新：

这是来自 firebug 的示例屏幕截图。您可以看到对资源的​​请求不会超时，但需要很长时间才能检索。 失败的文件可能从 CSS 背景图像到普通图像，甚至是字体文件。我认为这个问题比客户端更深。我们也遇到过 Chrome 偶尔出现“以下页面变得无响应。您可以等待它们变得有响应或杀死它们”错误。我们已经剥离了所有 javascript 的页面，它几乎是一个裸壳！跨浏览器继续出现图像加载问题。

更新：

我发现http错误日志中的以下错误似乎与问题有关。有谁知道它们的含义以及如何解决它们？

[ Wed Feb 23 06:54:17 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 5871 for worker proxy:reverse
[Wed Feb 23 06:54:17 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 5871 for (*)
[Wed Feb 23 06:54:24 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 5872 for worker proxy:reverse
[Wed Feb 23 06:54:24 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized
[Wed Feb 23 06:54:24 2011] [debug] proxy_util.c(1967): proxy: initialized single connection worker 0 in child 5872 for (*)
[Wed Feb 23 06:59:15 2011] [debug] proxy_util.c(1854): proxy: grabbed scoreboard slot 0 in child 5954 for worker proxy:reverse
[Wed Feb 23 06:59:15 2011] [debug] proxy_util.c(1873): proxy: worker proxy:reverse already initialized

【问题讨论】：

您应该在 Chrome 的“网络”选项卡中获得该 URL 的错误状态代码 - 它在那里显示什么？

我得到响应： Method:GET , Status:Pending , Type:Pending

可能是因为我的服务器没有发送正确的 MIME 类型？

当它失败时，状态应该从pending变为error... mime types 可能是原因，不知道

@pagewii 据我所知，如果您访问该链接并且它的 MIME 类型不正确；您的浏览器应该下载文件而不是显示它。

【参考方案1】：

听起来这是一个相当沉重的网站（2500 多行 js！）。奇怪的是您只在 Chrome 上体验它，但这可能取决于它处理请求的方式。

由于您的静态内容如此繁重，我建议您使用内容交付网络 (CDN)。通过 CDN（和地理位置）传播您的内容可以让用户得到最近的、因此也是最快的服务器的服务。

有许多 CDN 提供商会收取托管您的内容的费用。我使用Amazon S3 存储设施，虽然不是真正的 CDN，但可以帮助我传播我的静态内容，这确实加快了我的网站速度。

此外，使用 Amazon S3，您可以指定存储区域的地理位置，无论是美国还是欧洲等。这个地理位置可能比您现有的 Web 服务器更近，这是一个好处。 S3 还为您提供免费会员资格并进行测试。

希望这会有所帮助。

克里斯。

【讨论】：

我尝试从 Amazon S3 帐户提供我的内容，但加载资源失败错误消失了！杰出的！我想我的服务器没有能力提供我需要的所有静态内容。谢谢老哥！

【参考方案2】：

如果它是特定于 Chrome 的，我会说它可能与 this known bug 有关，但既然你提到它发生在其他浏览器中，你是否从 Safari 的网络开发工具 Firebug 中得到相同的错误，并且/ 或 IE 的开发者工具？

另外，您的网页的总下载时间和数量是多少？我在您的图像中看到似乎有大量文件，并且有些图像需要几秒钟才能加载。可以优化其中的任何一个吗？

帮助解决整个问题的一种方法是创建精灵，或尽可能使用非图像替代品（您可以使用多种 CSS3 技术来替换渐变等），以及使用诸如SmushIt 用于图像和 JS 压缩器和组合器，以减少文件大小和服务器请求。

【讨论】：

恐怕问题不只是特定于 chrome。对于其他浏览器中的某些图像元素，我也经历了很长的等待时间。 Chrome 似乎通过超时和放弃寻找图像来做出不同的响应，而 FF 和 IE 似乎一直在请求它直到它到达（可能需要长达 20 秒）。这些图像的范围从 5kb 的缩略图到 0.5kb 的 UI 图标。

你对你的服务器有什么样的控制？如果可以，请检查您的服务器资源，并确保某些资源没有耗尽资源。如果您没有这种控制（例如共享托管情况），您可能想尝试向您的主机开一张票，看看您的服务器上是否有人在吃资源（或者是否有太多事情发生一般来说，即使没有一个罪魁祸首）。

【参考方案3】：

终于有人和我一起解决了这个问题：

chrome 经典版 - “加载资源失败”

这个问题让开发者抓狂，因为它可能发生在本地，请求数量很少，PNG 很小——但是，如果你在新标签页中打开图片，您的图像将被...很好地加载！

重要提示：chrome 缓存是我经历过的最棘手的一个 - 尝试使用隐私模式禁用/绕过 chrome 的缓存或在资源后面附加一个随机字符串

重要通知 2：有时网络检查器的网络选项卡会导致连接超时 - 这就是您看到“PENDING”状态的原因

我尝试过的解决方案/解决方法：

将您的 chrome 升级到最新版本（通常不走运） 使用图像预加载（有时可以） 使用 data-uri 并将其放入另一个 .css 文件中：http://css-tricks.com/data-uris/

通过一些格式（css 选择器、css 规则顺序和换行），经过反复试验，图像再次加载。 （这个很神奇）

我想知道原始图像的特定位是否卡住了图像渲染器（因为 data-uri 在开始时不起作用）......但是当某些 CSS 样式应用于 PNG 背景块时会出现这个问题 - 特别是当涉及“不透明”时 （或者 PNG 是隐藏的背景）

总结：

以任何方式压缩图像 更改 CSS 选择器（例如在其他元素中应用背景），如果仍然无法加载，则是图像问题 - 尝试更改原始图像的一些位*或使用 data-uri（解决方案 3） 如果 (2) 加载了您的图像，则更改图像加载顺序 - 那么这将是 css 选择器/排序问题

*你可能不相信我编辑图片后，问题出现/消失了。

（如果您跨浏览器等待其他图像的时间很长，很可能是性能问题，但可能不是错误 - 发生了一些阻塞）

【讨论】：

我很难理解你的英语，但我希望你知道如何解决我的问题。失败的图像永远不会一致，有时来自 css background-image 有时是 标记。我的问题也是跨浏览器。这是否意味着我的问题是服务器端问题？

1.抱歉英语不好和 w3c 术语太多 2. 对我来说，问题不是那么一致 - 但是在你不更改你的 css 后它会更加一致......但是，它仍然不一致，特别是有时图像可以加载突然。

3.跨浏览器部分是性能问题 - 可能在服务器端或客户端 javascript。

4.它出现在 css-background 和 中，这就是在这种情况下图像加载失败的原因。

确定性能问题的快速提示：尝试将所有内容（服务器和所有文件）放入您的工作机器中。我发现您的图片加载时间如此之长，甚至返回了 304，这很奇怪。

【参考方案4】：

听起来很随机...在加载时将随机数查询字符串附加到 src。当我为一位老雇主开发自定义弹出框库时，我遇到了这个问题，并且它加载的网站是......非常资源密集型，比方说。出于某种原因，这为我修复了它。 YMMV？

img.src = 'x.gif?r=3192319231938123912';

【讨论】：

如果图片来源于 CSS 文件怎么办？

这根本不是随机的——这是防止浏览器尝试加载图像的缓存版本，而是从服务器加载新版本的常用技巧。如果这有效，则意味着您正在处理缓存问题。

@pagewil 它需要服务器端脚本（响应延迟），或使用 JS 加载背景图像（显示延迟）

@yc 我会建议开发者通过开发者工具关闭缓存 - 这个选项几乎适用于所有浏览器，除了 chrome

@vinicicat 所以你是说我需要延迟服务器响应？是什么原因？这会有助于图像数据的流动吗？

【参考方案5】：

您应该考虑压缩您的脚本文件（minify、gzip 等）。如果您的图片使用不同的主机 (images.yoursite.com)，您将拥有更多的并行连接。

您可以使用异步 javascript 加载 - 就像 Google 在 Google Analytics 文档中建议的那样： $(document).ready(function()

 var ga = document.createElement('script'); ga.type = 'text/javascript'; ga.async = true;

 ga.src = "xpto.js"

 (document.getElementsByTagName('head')[0] || document.getElementsByTagName('body')[0]).appendChild(ga);

);

【参考方案6】：

有几件事可以尝试。要更正 .woff 问题，请将正确的 mimetype 添加到您的服务器设置中：

AddType application/vnd.ms-fontobject .eot AddType application/octet-stream .otf .ttf

接下来，重新创建未加载的 .png 图像。可能是有人将图像保存为 .jpg 或 gif，但随后使用 .png 扩展名重命名该文件 - 从而混淆了浏览器。尝试再次创建该图像并确保它以正确的格式保存。

【讨论】：

你不是只在那个 mime 类型设置上声明了 eot、otf 和 ttf 吗？