今天说一个看似和前端没有关系但是却又和我的前端开发工作密不可分的事，那就是单广告位的事情。前面几篇文章我提到过“单广告位请求”这个词，又说了“单广告位是只能投放的前提”。有很多的同事问我为什么这么说，难道不做“单广告位请求”就不能做智能投放了吗？其实在最开始接触到这个名词的时候我提出了这样的疑问：智能投放应该是和用户画像联系比较紧密，只要能拿到cookie，将用户归类，就应该可以已领算法推送更为精准的广告，至于广告是怎么请求数据的？这个问题看似并不是很重要，毕竟我的请求可以打包也可以分散，这只是一个渠道问题，并不能成为一个关键路径。而且每个广告位单独请求数据带来的性能问题也是成倍上升的。但是随着开发过程中的不断深入，我开始从前端的角度发现了“单广告位请求的意义”。
下面我试着从前端的角度上分析一下：
1、业内共识：“单广告位请求”基石的地位已经被国内外各个互联网广告平台验证过了。所以在开发的初期基于这个成型的理论，我并没有走弯路，而是直接展开单广告位请求的实现上。但是单广告位请求的优势确实再后来才慢慢发现的。
2、简化流程、前后解耦：刚刚提到了通常广告数据请求的两种方式：合并请求、单广告位请求。合并请求指的是将页面的广告位需要的信息以页面为单位整体合并请求广告数据，为了能减小请求的开销，会将页面作为参数而不是广告位。服务端将请求（前端合并好的），再拆包（或者解析页面参数），再调取本业的数据（后台自然要有一个页面模板来控制整个页面的广告数据），达成一个包响应给前端，前端收到后在拆包取出数据分别解析展示；而单广告位请求是页面直接以页面和广告位为参数，发送本资源位的数据请求响应的数据也是这个广告位的，后台接口服务，可以直接定位广告位，省去后台服务的请求拆包和数据打包。前端接收到数据后直接渲染这个广告位。
看起来，好像单广告位请求的流程更加简化，是不是性能更高呢？答案恰恰相反，合并请求的性能会更高一些，或者说如果不做智能投放的话，合并请求的性能会更高一点。要想评论两种请求，需要站在不同的业务需求角度来说。
非智能投放适合合并请求：对于每一天，当前页面的每个广告位需要展示的数据是不变的，如果以页面为单位整体请求，返回的整个包也是不变的，毕竟在参数中没有加入“人”这个灵活的因素。也就是说后台利用缓存直接将这个页面的“包”发回去。对于后台服务器的负担可以说是很小的，前端请求只需要在参数中加入页面信息，整个过程最复杂的地方在前端在接收数据的拆包，但是这种消耗分散在无数的客户端浏览器上。而单广告位请求的请求数量直接和广告位数量成正比，增加请求直接意味着增加网络开销，每一个请求都有报文头开销。非智投的情况下，相比于单广告位请求，合并请求的性能可以小很多。
智能投放适合单广告位请求：在智投的情况下，想要直接利用缓存提高响应速度，便不是那么的容易，每个广告位的请求中还夹杂这广告位的信息便不能以页面为单位发出请求，根据用户画像中用户的习惯，每一个广告位数据的计算结果都有着独立的规律。也就是说加入了“人”的因素，缓存快响应的方式变的不太合理。计算广告不得不面对拆包计算，再打包响应。每一个资源位数据的计算时间都不确定，同一时间有多少客户端访问，就意味着服务器需要同时计算多少组数据，而且还要乘以页面中广告为的数量。这种延时不可忽略。而单广告位请求可以直接抛弃包（拆、装）的概念。服务器直接针对一个小计算量的请求，算好了，就直接响应，前端就马上展示。在智投情况下，减小了服务器的压力，简化流程的单广告位请求会更快一些。
3、支撑业务灵活（颗粒度）：
由于智能投放以后，要处理的业务会更灵活，有一些广告的展示不仅仅是页面初始化一次搞定的，可能随着页面的用户的交互，动态的拉取不确定的广告数据，比如load more、加载更多（异步）等。单广告位请求可以只请求增量的数据，而合并请求就不是很适合了。但是在大量请求并发处理上需要前端多下一些功夫。
总结：
以上是我对单广告位的个人理解，主要是从前端的角度出发。说的不对，请斧正。
与这个话题相关的文章还有：《pv与单广告位曝光统计优化》、《巧用域名发散，缓解单广告位并发请求限制》