更多生产情况下， 静态资源是放在单独的服务器或其他第三方服务器。那么如何利用 Server Push 将静态资源推送给客户端？
HTTP/2 的Server Push还能在哪些方面发挥作用？
就我的理解而言，没有办法，也没有必要。既然静态资源放在第三方服务器上，那么和第三方服务器建立连接的过程不可避免。这种情况下主要的时间消耗产生于和第三方服务器建立连接的过程中。server push的意义不大。
但是！第三方服务器是可以使用server push一次性将要需要加载的内容推送给客户端的。其它意义在于动态内容的推送，例如“你有新的私信”，“你的答案有新的评论”等等
关于评论中提到的 websocket 的问题，这里摘录一段 websocket 和 http2 的关系的说明。（其实是 SPDY，不过 http2 是基于 SPDY 的）
- 补充关系，二者侧重点不同。SPDY更侧重于给Web页面的加载提速，而WebSocket更强调为Web应用提供一种双向的通讯机制以及API。
- 竞争关系，二者解决的问题有交集，比如在服务器推送上SPDY和WebSocket都提供了方案。
- 承载关系，试想，如果SPDY的标准化早于WebSocket，WebSocket完全可以侧重于API，利用SPDY的帧机制和多路复用机制实现该API。
Google提出草案，说WebSocket可以跑在SPDY之上。WebSocket的连接建立在SPDY的流之上，将WebSocket的帧映射到SPDY的帧上。- 融合关系，如微软在HTTP Speed+Mobility中所做的。
服务端只能根据客户端请求返回额外的 Push 流，Push 流和正常的响应流需要在同一个 TCP 连接中，所以一般要求要 Push 的资源和主页面由同一个服务端输出。
HTTP/2 中的 Server Push 被设计为替代 HTTP/1.x 中为了节省连接数所引入的「资源 inline」方案。因为 inline 无法被缓存，会导致第二次访问浪费了流量，多页面之间的公共资源被 inline 后也无法利用缓存；图片 base64 后还会变大 1/3。这些问题，可以通过将 inline 资源写入用户的 localStorage，并通过 Cookie 标记用户当前版本，达到优化第二次访问页面体积的效果。
详细可以查看我的这篇文章《HTTP/2 与 WEB 性能优化（一）》。
另外 HTTP/2 的 Server Push 主要目的是为了减少时延，服务端要推送资源时，会发送一个 PUSH_PROMISE 帧，然后接着发出 HEADER 和 DATA 帧，客户端如果发现服务端要推送的资源本地有缓存，可以返回一个 RST_STREAM 终止流，节省传输。这个过程可能会造成一定程度的流量浪费，但是时延还是减少了。
这部分内容，可以查看我的这篇文章《HTTP/2 中的 Server Push 讨论》。这里有 H2O 的作者 Kazuho Oku，aria2 的作者 Tatsuhiro Tsujikawa，以及《High-Performance Browser Networking》的作者 Ilya Grigorik 关于 Server Push 的讨论。