问题 A 部分 ▉（100 赏金，已授予）
主要问题是如何使该网站加载速度更快。首先我们需要阅读这些瀑布。感谢大家对瀑布读数分析的建议。从这里显示的各种瀑布图可以明显看出主要瓶颈：PHP 生成的缩略图。 David 建议的从 CDN 加载的无协议 jquery 得到了我的赏金，尽管它使我的网站总体速度仅提高了 3%，并且没有解决网站的主要瓶颈。是时候澄清我的问题了，还有另一个赏金：
问题 B 部分 ▉（100 赏金，已授予）
现在新的重点是解决 6 张 jpg 图像所存在的问题，该问题导致大部分加载延迟。这 6 张图片是 PHP 生成的缩略图，很小，只有 3~5 kb，但加载速度相对非常。请注意各个图表上的“第一个字节的时间”。问题仍未解决，但 James 获得了赏金，他修复了 RedBot 下划线 的标头错误：“If-Modified-Since 条件请求返回未更改的完整内容。”。
问题 C 部分 ▉（250 赏金，已授予）
不幸的是，即使修复了 REdbot.org 标头错误，由 PHP 生成的图像引起的延迟仍然没有受到影响。这些 3~5Kb 的小缩略图到底在想什么？所有这些标头信息都可以将火箭发送到月球并返回。关于这个瓶颈的任何建议都非常感谢并被视为可能的答案，因为我已经被这个瓶颈问题困扰了七个月了。
[我网站上的一些背景信息：CSS 位于顶部。底部的 JS（Jquery、JQuery UI、购买菜单 awm/menu.js 引擎、选项卡 js 引擎、视频 swfobject.js）第二个图像上的黑线显示启动加载内容的内容。愤怒的机器人是我的宠物“ZAM”。他是无害的，而且常常更快乐。]
加载瀑布：按时间顺序 | http://webpagetest.org
并行域分组 | http://webpagetest.org
站点性能瀑布 | http://site-perf.com
Pingdom 工具瀑布 | http://tools.pingdom.com
GTmetrix 瀑布 | http://gtmetrix.com
Question Part A ▉ (100 bountys, awarded)
Main question was how to make this site, load faster. First we needed to read these waterfalls. Thanks all for your suggestions on the waterfall readout analysis. Evident from the various waterfall graphs shown here is the main bottleneck: the PHP-generated thumbnails. The protocol-less jquery loading from CDN advised by David got my bounty, albeit making my site only 3% faster overall, and while not answering the site's main bottleneck. Time for for clarification of my question, and, another bounty:
Question Part B ▉ (100 bountys, awarded)
The new focus was now to solve the problem that the 6 jpg images had, which are causing the most of the loading-delay. These 6 images are PHP-generated thumbnails, tiny and only 3~5 kb, but loading relatively very slowly. Notice the "time to first byte" on the various graphs. The problem remained unsolved, but a bounty went to James, who fixed the header error that RedBot underlined: "An If-Modified-Since conditional request returned the full content unchanged.".
Question Part C ▉ (250 bountys, awarded)
Unfortunately, after even REdbot.org header error was fixed, the delay caused by the PHP-generated images remained untouched. What on earth are these tiny puny 3~5Kb thumbnails thinking? All that header information can send a rocket to moon and back. Any suggestions on this bottleneck is much appreciated and treated as possible answer, since I am stuck at this bottleneckish problem for already seven months now.
[Some background info on my site: CSS is at the top. JS at the bottom (Jquery,JQuery UI, bought menu awm/menu.js engines, tabs js engine, video swfobject.js) The black lines on the second image show whats initiating what to load. The angry robot is my pet "ZAM". He is harmless and often happier.]
Load Waterfall: Chronological | http://webpagetest.org
Parallel Domains Grouped | http://webpagetest.org
Site-Perf Waterfall | http://site-perf.com
Pingdom Tools Waterfall | http://tools.pingdom.com
GTmetrix Waterfall | http://gtmetrix.com
发布评论
评论（19）
首先，使用这些多个域需要进行多次 DNS 查找。您最好将许多这些图像组合成一个精灵< /a> 而不是分散请求。
其次，当我加载您的页面时，我在 all.js 上看到大部分阻塞（~1.25 秒）。我发现这是从（旧版本的）jQuery 开始的。您应该从 Google CDN 引用该内容，不仅要 减少加载时间，但是可能完全避免对其进行 HTTP 请求。
具体来说，可以在这些 URL 中引用最新的 jQuery 和 jQuery UI 库（请参阅 这篇文章（如果您有兴趣为什么我省略了
http:）：如果您使用的是默认 jQuery UI 主题之一，您还可以拉取其来自 Google CDN 的 CSS 和图像。
通过优化 jQuery 托管，您还应该将
awmlib2.js和tooltiplib.js合并到一个文件中。如果你解决这些问题，你应该会看到显着的进步。
First, using those multiple domains requires several DNS lookups. You'd be better off combining many of those images into a sprite instead of spreading the requests.
Second, when I load your page, I see most of the blocking (~1.25s) on all.js. I see that begins with (an old version of) jQuery. You should reference that from the Google CDN, to not only decrease load time, but potentially avoid an HTTP request for it entirely.
Specifically, the most current jQuery and jQuery UI libraries can be referenced at these URLs (see this post if you're interested why I omitted the
http:):If you're using one of the default jQuery UI themes, you can also pull its CSS and images off the Google CDN.
With the jQuery hosting optimized, you should also combine
awmlib2.jsandtooltiplib.jsinto a single file.If you address those things, you should see a significant improvement.
几天前我遇到了类似的问题&我找到了 head.js。
它是一个 Javascript 插件，允许您并行加载所有 JS 文件。
希望有帮助。
I had a similar problem a few days ago & i found head.js.
It's a Javascript Plugin which allows you to load all JS files paralell.
Hope that helps.
我远不是专家，但是......
关于这一点：
“If-Modified-Since 条件请求返回的完整内容未更改。”
和我的评论。
用于生成缩略图的代码应检查以下内容：
如果其中任何一个为 false，则无论如何都应该生成并返回缩略图。如果它们都为 true，则应进行以下检查：
如果其中任何一个为 false，则应返回缓存的缩略图。
如果这两个条件都成立，则应返回 304 http 状态。我不确定是否需要，但我个人还返回了 Cache-Control、Expires 和 Last-Modified 标头以及 304。
关于 GZipping，我被告知不需要 GZip 图像，因此请忽略它我的评论的一部分。
编辑：我没有注意到您对帖子的添加。
我还确信您的代码需要检查 HTTP_IF_MODIFIED_SINCE 标头并对其做出反应。仅设置这些标头，您的 .htaccess 文件将无法提供所需的结果。
我认为你需要这样的东西：
I am far from an expert but...
In regards to this:
"An If-Modified-Since conditional request returned the full content unchanged."
and my comments.
The code used to generate the Thumbnails should be checking for the following:
If either of these are false the thumbnail should be generated and returned no matter what. If they are both true then the following check should be made:
If either of these are false the cached thumbnail should be returned.
If both of these are true then a 304 http status should be returned. I'm not sure if its required but I also personally return the Cache-Control, Expires and Last-Modified headers along with the 304.
In regards to GZipping, I've been informed that there is no need to GZip images so ignore that part of my comment.
Edit: I didn't notice your addition to your post.
I'm also sure that your code needs to check for the HTTP_IF_MODIFIED_SINCE header and react to it. Just setting these headers and your .htaccess file won't provide the required result.
I think you need something like this:
哇，使用该图像很难解释事情。但是在这里，有些尝试：
Wow, it's hard to explain things using that image.. But here, some tries:
只是一个简单的猜测，因为这种分析需要大量 A/B 测试：您的 .ch 域似乎很难到达（第一个字节到达之前的长绿色带）。
这意味着 .ch 网站的托管质量很差，或者您的 ISP 没有通往该网站的良好路由。
鉴于这些图表，这可以解释性能的巨大影响。
顺便说一句，有一个很酷的工具 cuzillion 可以帮助您根据资源的顺序来整理事情加载中。
Just a simple guess because this kind of analysis requires a lot of A/B testing: your .ch domain seems to be hard to reach (long, green bands before the first byte arrives).
This would mean that either the .ch website is poorly hosted or that you ISP does not have a good route to them.
Given the diagrams, this could explain a big performance hit.
On a side note, there is this cool tool cuzillion that could help you sort out things depending on your ordering of ressource loading.
尝试在您的网站/页面上运行 Y!Slow 和 Page Speed 测试，并按照指南找出可能的性能瓶颈。一旦您在 Y!Slow 或 Page Speed 中得分较高，您应该会获得巨大的性能提升。
这些测试将告诉您出了什么问题以及需要更改什么。
Try running Y!Slow and Page Speed tests on your site/page, and follow the guidelines to sort out possible performance bottlenecks. You should be getting huge performance gains once you score higher in Y!Slow or Page Speed.
These tests will tell you what's wrong and what to change.
那么您的 PHP 脚本会在每次页面加载时生成缩略图？首先，如果缩略图的图像不经常更改，您是否可以设置一个缓存，以便不必在每次页面加载时解析它们？其次，您的 PHP 脚本是否使用诸如
imagecopyresampled()之类的东西来创建缩略图？这是一个不平凡的缩减采样，PHP 脚本在完成缩减之前不会返回任何内容。使用imagecopymerged()会降低图像质量，但会加快处理速度。你们减少了多少？这些缩略图是原始图像大小的 5% 还是 50%？原始图像的较大尺寸可能会导致速度变慢，因为 PHP 脚本必须先将原始图像放入内存中，然后才能缩小它并输出较小的缩略图。So your PHP script is generating the thumbnails on every page load? First off, if the images that are being thumbnailed are not changing that often, could you set up a cache such that they don't have to be parsed each time the page loads? Secondly, is your PHP script using something like
imagecopyresampled()to create the thumbnails? That's a non-trivial downsample and the PHP script won't return anything until its done shrinking things down. Usingimagecopymerged()instead will reduce the quality of the image, but speed up the process. And how much of a reduction are you doing? Are these thumbnails 5% the size of the original image or 50%? A greater size of the original image likely is leading to a slowdown since the PHP script has to get the original image in memory before it can shrink it and output a smaller thumbnail.我找到了你们网站的 URL，并从主页上检查了一个单独的 jpg 文件。
虽然现在加载时间是合理的（161 毫秒），但它等待了 126 毫秒，这太长了。
您最后修改的标头均设置为 Sat, 01 Jan 2011 12:00:00 GMT，这看起来太“圆”，不可能是真正的生成日期;-)
由于 Cache-control 是“public, max-age=14515200” ”，任意最后修改的标头都可能在 168 天后导致问题。
无论如何，这并不是延误的真正原因。
当缩略图已经存在时，您必须检查缩略图生成器会做什么，以及什么可能会消耗大量时间来检查和交付图片。
您可以安装 xdebug 来分析脚本并查看瓶颈所在。
也许整个事情都使用一个框架或连接到一些数据库，但没有任何作用。我在某些服务器上看到 mysql_connect() 非常慢，主要是因为它们使用 TCP 而不是套接字连接，有时还存在一些 DNS 问题。
我知道您无法在这里发布您的付费生成器，但恐怕有太多可能的问题......
I've found the URL of your website and checked an individual jpg file from the homepage.
While the loading time is reasonable now (161ms), it's waiting for 126ms, which is far too much.
Your last-modified headers are all set to Sat, 01 Jan 2011 12:00:00 GMT, which looks too "round" to be the real date of generation ;-)
Since Cache-control is "public, max-age=14515200", arbitrary last-modified headers will could cause problem after 168 days.
Anyway, this is not the real reason for delays.
You have to check what your thumbnail generator do when the thumbnail already exists and what could consume so much time checking and delivering the picture.
You could install xdebug to profile the script and see where the bottlenecks are.
Maybe the whole thing uses a framework or connects to some database for nothing. I've seen very slow mysql_connect() on some servers, mostly because they were connecting using TCP and not socket, sometimes with some DNS issues.
I understand you can't post your paid generator here but I'm afraid there are too many possible issues...
如果没有真正充分的理由（通常没有），您的图像不应调用 PHP 解释器。
为您的 Web 服务器创建一个重写规则，如果在文件系统上找到图像，则直接提供该图像。如果不是，请重定向到 PHP 脚本以生成图像。编辑图像时，更改图像文件名以强制拥有缓存版本的用户获取新编辑的图像。
如果它不起作用，至少你现在会发现它与图像的创建和检查方式没有任何关系。
If there isn't a really good reason (usually there isn't) your images shouldn't invoke the PHP interpreter.
Create a rewrite rule for your web server that servers the image directly if it is found on the file system. If it's not, redirect to your PHP script to generate the image. When you edit the image, change the images filename to force users that have a cached version to fetch the newly edited image.
If it doesn't work at least you will now it doesn't have anything to do with the way the images are created and checked.
研究 PHP 对会话数据的使用。也许（只是也许），图像生成 PHP 脚本正在等待获取会话数据的锁定，该锁定由仍在渲染的主页或其他图像渲染脚本锁定。这将使所有 JavaScript/浏览器优化几乎无关紧要，因为浏览器正在等待服务器。
PHP 会锁定每个正在运行的脚本的会话数据，从会话处理开始的那一刻到脚本完成的那一刻，或者调用 session_write_close() 时。这有效地序列化了事物。查看有关会话的 PHP 页面，尤其是注释，例如这个。
Investigate PHP's usage of session data. Maybe (just maybe), the image-generating PHP script is waiting to get a lock on the session data, which is locked by the still-rendering main page or other image-rendering scripts. This would make all the JavaScript/browser optimizations almost irrelevant, since the browser's waiting for the server.
PHP locks the session data for every script running, from the moment the session handling starts, to the moment the script finishes, or when session_write_close() is called. This effectively serializes things. Check out the PHP page on sessions, especially the comments, like this one.
这只是一个疯狂的猜测，因为我还没有看过你的代码，但我怀疑会话可能在这里发挥作用，以下内容来自
session_write_close()：就像我说的，我不知道你的代码在做什么，但这些图表看起来非常可疑。当我编写了一个多部分文件服务函数时，我遇到了类似的问题我也有同样的问题。当提供大文件时，我无法使用多部分功能，也无法打开另一个页面，直到下载完成。 调用
session_write_close()已修复我的问题。This is just a wild guess since I haven't looked at your code but I suspect sessions may be playing a role here, the following is from the PHP Manual entry on
session_write_close():Like I said, I don't know what your code is doing but those graphs seem oddly suspicious. I had a similar issue when I coded a multipart file serving function and I had the same problem. When serving a large file I couldn't get the multipart functionality to work nor could I open another page until the download was completed. Calling
session_write_close()fixed both my problems.您是否尝试过用常规图像替换 php 生成的缩略图，看看是否有任何差异？
问题可能出在
- php 代码中的错误导致每次服务器调用时重新生成缩略图
- 与时钟问题相关的代码延迟（ sleep()？）
- 硬盘问题导致非常糟糕的竞争条件，因为所有缩略图都是同时加载/生成的。
Have you tried replacing the php generated thumnails by regular images to see if there is any difference ?
The problem could be around
- a bug in your php code leading to a regeneration of the thumbnail upon each server invocation
- a delay in your code ( sleep()?) associated with a clock problem
- a hardrive issue causing a very bad race condition since all the thumbnails get loaded/generated at the same time.
我认为您必须尝试一下TinySRC，而不是使用缩略图生成器脚本和云托管的缩略图生成。
它有一个非常简单易用的 API，您可以使用：-
http://i.tinysrc.mobi/ [高度] / [宽度] /http://domain.tld/path_to_img.jpg
[宽度]（可选） :-
这是以像素为单位的宽度（它覆盖自适应或系列大小）。如果以“-”或“x”为前缀，它将从确定的大小中减去或缩小到确定的大小的百分比。
[高度]（可选）：-
如果宽度也存在，则这是以像素为单位的高度。它还会覆盖自适应或家庭大小，并且可以以“-”或“x”为前缀。
您可以在此处查看 API 摘要
常见问题解答
tinySrc 需要花多少钱？ 什么
都没有。
我什么时候可以开始使用tinySrc？
现在。
服务的可靠性如何？
我们对tinySrc服务不做任何保证。然而，它运行在主要的分布式云基础设施上，因此它在全球范围内提供高可用性。它应该足以满足您的所有需求。
速度有多快？
tinySrc 在内存和我们的数据存储中缓存调整大小的图像长达 24 小时，并且它不会每次都获取您的原始图像。从用户的角度来看，这使得服务速度极快。 （并减少服务器负载作为一个很好的副作用。）
祝你好运。只是一个建议，因为你没有向我们展示代码：p
I think instead of using that thumbnail-generator script you must give TinySRC a try for rapid fast and cloud-hosted thumbnail generation.
It has a very simple and easy to use API, you can use like:-
http://i.tinysrc.mobi/ [height] / [width] /http://domain.tld/path_to_img.jpg
[width] (optional):-
This is a width in pixels (which overrides the adaptive- or family-sizing). If prefixed with ‘-’ or ‘x’, it will subtract from, or shrink to a percentage of, the determined size.
[height] (optional):-
This is a height in pixels, if width is also present. It also overrides adaptive- or family-sizing and can be prefixed with ‘-’ or ‘x’.
You can check the API summary here
FAQ
What does tinySrc cost me?
Nothing.
When can I start using tinySrc?
Now.
How reliable is the service?
We make no guarantees about the tinySrc service. However, it runs on a major, distributed cloud infrastructure, so it provides high availability worldwide. It should be sufficient for all your needs.
How fast is it?
tinySrc caches resized images in memory and in our datastore for up to 24 hours, and it will not fetch your original image each time. This makes the services blazingly fast from the user’s perspective. (And reduces your server load as a nice side-effect.)
Good Luck. Just a suggestion, since u ain't showing us the code :p
由于某些浏览器每个域仅下载 2 个并行下载，您是否无法将其他域添加到 将请求分片到两到三个不同的主机名上。例如 1.imagecdn.com 2.imagecdn.com
As some browsers only download 2 parallels downloads per domain, could you not add additional domains to shard the requests over two to three different hostnames. e.g. 1.imagecdn.com 2.imagecdn.com
首先，正如 James 所说，您需要适当地处理
If-Modified-Since请求等。该错误指出：“当我询问您的服务器自上次以来该图像是否被修改时，它会发送整个图像而不是简单的是/否”。连接和第一个字节之间的时间通常是 PHP 脚本运行所需的时间。很明显，当该脚本开始运行时，发生了一些事情。
通过应用程序生成正确的标头有点棘手，而且它们可能会被服务器覆盖。而且您会受到滥用，因为任何发送一些无缓存请求标头的人都会导致您的缩略图生成器持续运行（并增加负载）。因此，如果可能的话，尝试保存这些生成的拇指，直接从页面调用保存的图像并从
.htaccess管理标题。在这种情况下，如果您的服务器配置正确，您甚至不需要.htaccess中的任何内容。除此之外，您还可以在 如何以正确的方式建立网站，例如将资源拆分为无 cookie 的子域等。但无论如何，3k 图像不应该占用加载一秒钟，与图表中的其他项目相比，这一点很明显。您应该在优化之前尝试发现问题。
First of all, you need to handle
If-Modified-Sincerequests and such appropriately, as James said. That error states that: "When I ask your server if that image is modified since the last time, it sends the whole image instead of a simple yes/no".The time between the connection and the first byte is generally the time your PHP script takes to run. It is apparent that something is happening when that script starts to run.
Generating proper headers through the application is a bit tricky, plus they may get overwritten by the server. And you are exposed to abuse as anyone sending some no-cache request headers will cause your thumbnail generator to run continuously (and raise loads). So, if possible, try to save those generated thumbs, call the saved images directly from your pages and manage headers from
.htaccess. In this case, you wouldn't even need anything in your.htaccessif your server is configured properly.Other than these, you can apply some of the bright optimization ideas from the performance parts of this overall nice SO question on how to do websites the right way, like splitting your resources into cookieless subdomains, etc. But at any rate, a 3k image shouldn't take a second to load, this is apparent when compared to other items in the graphs. You should try to spot the problem before optimizing.
您是否尝试过在 NGINX Webserver 下设置多个子域，专门用于提供图像和样式表等静态数据？ 本主题中可能已经找到了一些有用的内容。
Have you tried to set up several subdomains under NGINX webserver specially for serving static data like images and stylesheets? Something helpful could be already found in this topic.
关于延迟的缩略图，请尝试在最后一次调用 flush()缩略图生成脚本中的“http://es2.php.net/manual/en/function.header.php” rel="nofollow">header() 。完成后，重新生成瀑布图并查看延迟现在是否出现在正文而不是标题上。如果是这样，您需要仔细研究生成和/或输出图像数据的逻辑。
处理缩略图的脚本应该使用某种缓存，这样它对您所提供的图像执行的任何操作只会在绝对必要时才会发生。看起来每次提供缩略图时都会发生一些昂贵的操作，这会延迟脚本的任何输出（包括标题）。
Regarding the delayed thumbnails, try putting a call to flush() immediately after the last call to header() in your thumbnail generation script. Once done, regenerate your waterfall graph and see if the delay is now on the body instead of the headers. If so you need to take a long look at the logic that generates and/or outputs the image data.
The script that handles the thumbnails should hopefully use some sort of caching so that whatever actions it takes on the images you're serving will only happen when absolutely necessary. It looks like some expensive operation is taking place every time you serve the thumbnails which is delaying any output (including the headers) from the script.
大多数缓慢问题是您的 TTFB（第一个字节的时间）太高。如果不熟悉服务器配置文件、代码和底层硬件，这是一个很难解决的问题，但我可以看到它在每个请求中都很猖獗。你有太多的绿色条（坏）和很少的蓝色条（好）。您可能想停止优化前端，因为我相信您在该领域已经做了很多工作。尽管有一句格言“80%-90%最终用户响应时间花费在前端”，我相信你的响应时间发生在后端。
TTFB 是后端内容、服务器内容、输出和握手之前的预处理。
计算代码执行时间以查找缓慢的内容，例如缓慢的数据库查询、进入和退出函数/方法的时间以查找缓慢的函数。如果您使用 php，请尝试 Firephp。有时，它是在启动或初始化期间运行一两个缓慢的查询，例如提取会话信息或检查身份验证等等。优化查询可以带来一些良好的性能提升。有时代码使用 php prepend 或 spl autoload 运行，因此它们可以在所有内容上运行。其他时候，可能是错误配置了 apache conf 并进行了调整，从而挽救了局面。
寻找低效循环。查找因磁盘驱动器故障或磁盘空间使用率过高而导致的缓存获取调用缓慢或 I/O 操作缓慢的情况。查找内存使用情况以及正在使用什么以及在何处使用。仅使用来自世界各地不同位置而非同一位置的第一个视图，对单个图像或文件运行 10 次重复测试。并阅读您的访问和错误日志，太多开发人员忽略它们并仅依赖于输出的屏幕错误。如果您的网络托管服务商有支持，请向他们寻求帮助，如果他们不提供帮助，也许无论如何都会礼貌地向他们寻求帮助，这不会有什么坏处。
您可以尝试 DNS 预取来对抗许多域和资源，http://html5boilerplate.com/docs/DNS -Prefetching/
你自己的服务器是一个好的/像样的服务器吗？有时更好的服务器可以解决很多问题。我是 '硬件的粉丝便宜，程序员贵'的心态，如果你有机会和钱升级一台服务器。和/或使用 CDN，例如 maxcdn 或 cloudflare 或类似的。
祝你好运！
（附注：我不在这些公司工作。另外，上面的 cloudflare 链接会认为 TTFB 并不那么重要，我把它放在那里，这样你就可以再看一遍。）
The majority of the slow issue is your TTFB (Time to first byte) being too high. This is a hard one to tackle without getting intimate with your server config files, code and underlying hardware, but I can see it's rampant on every request. You got too much green bars (bad) and very little blue bars (good). You might want to stop optimizing the frontend for a bit, as I believe you've done much in that area. Despite the adage that "80%-90% of the end-user response time is spent on the frontend", I believe yours is occuring in the backend.
TTFB is backend stuff, server stuff, pre-processing prior to output and handshaking.
Time your code execution to find slow stuff like slow database queries, time entering and exiting functions/methods to find slow functions. If you use php, try Firephp. Sometimes it is one or two slow queries being run during startup or initializtion like pulling session info or checking authentication and what not. Optimizing queries can lead to some good perf gains. Sometimes code is run using php prepend or spl autoload so they run on everything. Other times it can be mal configured apache conf and tweaking that saves the day.
Look for inefficient loops. Look for slow fetching calls of caches or slow i/o operations caused by faulty disk drives or high disk space usage. Look for memory usages and what's being used and where. Run a webpagetest repeated test of 10 runs on a single image or file using only first view from different locations around the world and not the same location. And read your access and error logs, too many developers ignore them and rely only on outputted onscreen errors. If your web host has support, ask them for help, if they don't maybe politely ask them for help anyway, it won't hurt.
You can try DNS Prefetching to combat the many domains and resources, http://html5boilerplate.com/docs/DNS-Prefetching/
Is the server your own a good/decent server? Sometimes a better server can solve a lot of problems. I am a fan of the 'hardware is cheap, programmers are expensive' mentality, if you have the chance and the money upgrade a server. And/Or use a CDN like maxcdn or cloudflare or similar.
Good Luck!
(p.s. i don't work for any of these companies. Also the cloudflare link above will argue that TTFB is not that important, I threw that in there so you can get another take.)
抱歉，您提供的数据很少。而且您已经提出了一些好的建议。
您如何提供这些图像？如果您通过 PHP 流式传输这些内容，那么您就是在做一件非常糟糕的事情，即使它们已经生成了。
切勿使用 PHP 传输图像。无论您如何使用它，它都会减慢您的服务器速度。
将它们放在可访问的文件夹中，并使用有意义的 URI。然后使用真实的 URI 直接调用它们。
如果您需要动态生成，则应将 .htaccess 放入图像目录中，仅当请求图像丢失时，该目录才会重定向到生成器 php 脚本。 （这称为按需缓存策略）。
这样做将一次性修复 php 会话、浏览器代理、缓存、ETAGS 等问题。
如果配置正确，WP-Supercache 使用此策略。
我前段时间写过这个（ http://code. google.com/p/cache-on-request/source/detail?r=8 ），最后的修订已损坏，但我想 8 或更少应该可以工作，您可以获取 .htaccess 作为示例测试一下（尽管有比我以前使用的方法更好的方法来配置 .htaccess）。
我在这篇博文中描述了该策略（ http://www.stefanoforenza.com/need-for -缓存/）。它可能写得不好，但它可能有助于澄清问题。
进一步阅读：http://meta.wikimedia.org/wiki/404_handler_caching
Sorry to say, you provide to few data. And you already had some good suggestions.
How are you serving those images ? If you're streaming those via PHP you're doing a very bad thing, even if they are already generated.
NEVER STREAM IMAGES WITH PHP. It will slow down your server, no matter the way you use it.
Put them in a accessible folder, with a meaningful URI. Then call them directly with their real URI.
If you need on the fly generation you should put an .htaccess in the images directory which redirects to a generator php-script only if the request image is missing. (this is called cache-on-request strategy).
Doing that will fix php session, browser-proxy, caching, ETAGS, whatever all at once.
WP-Supercache uses this strategy, if properly configured.
I wrote this some time ago ( http://code.google.com/p/cache-on-request/source/detail?r=8 ), last revisions are broken, but I guess 8 or less should work and you can grab the .htaccess as an example just to test things out (although there are better ways to configure the .htaccess than the way I used to).
I described that strategy in this blog post ( http://www.stefanoforenza.com/need-for-cache/ ). It is probably badly written but it may help clarifying things up.
Further reading: http://meta.wikimedia.org/wiki/404_handler_caching