如果我是你，我不会走这条路.当然，可以通过减少请求数量来节省协议开销的几个字节，但这很可能最终会导致自欺欺人.

I wouldn't go down this route if I were you. Sure, you may save a few bytes in protocol overhead by reducing the number of requests, but this would more-tha-likely end up being self-defeating.

想象一下这种情况: 一个博客站点，其首页一次包含10篇文章.每篇文章都有与之关联的自己的图像.为了节省一个或两个字节的传输时间，您可以以编程方式创建所有10个商品图像的复合图像.您现在遇到两个问题之一.

Imagine this scenario: A blog site, whose front page has 10 articles at a time. Each article has it's own image associated with it. To save a byte or two of transfer time, you programatically create a composite image of all 10 article images. You now have one of two problems.

1. 每次发表新帖子时，您都必须更新合成图像，因为最近的10张图像将具有一组修改后的内容.
2. 您决定动态地为每个请求创建一个新的组合.

很显然，这里#1是更可取的，并且实现起来并不困难.但是，如果用户搜索所有标有"SQL"字样的帖子怎么办?您不可能已经为该简单查询创建了前10个结果的合成图像，更不用说更复杂的了.另外，如果您要更新或删除图像，该怎么办?再一次，您必须触发合成的后台创建.

Obviously, #1 is preferable here, and would not be difficult to implement. However, what if a user searches for all posts tagged with the word "SQL"? You are unlikely to have a composite image of the first 10 results already created for this simple query, let alone a more complex one. Also, what happens if you want to update or delete an image? Once again you'd have to trigger the background creation of the composite.

RSS聚合器(如Google Reader)怎么样?它没有所需的逻辑来确定合成图像的哪一部分需要显示，并且可能会显示完整图像. (我之所以提到Google Reader，是因为我很少直接访问博客网站，而倾向于信任Reader之类的RSS聚合服务)

How about an RSS aggregator, like Google Reader? It wouldn't have the required logic to figure out which portion of a composite image it would need to display, and would probably display the full image. (I mention Google Reader because I very rarely visit blog sites directly, tending to trust to an RSS aggregation service like Reader)

如果是我，我将不理会单个图像.在现代的连接速度下，额外的带宽开销和服务器上的处理时间之间的权衡不太可能赢得您并获得丰厚的收益.

If it were me, I'd leave the single images alone. With modern connection speeds, the tradeoff between additional bandwidth overhead and on-server processing time is unlikely to win you and great gains.

话虽如此，如果您仍然决定沿这条路线走，我想说GD库是一个很好的起点.

Having said that, if you decide to go down this route anyway, I'd say the GD library is an excellent place to start.