我有几个场景，我最终需要在几个月内考虑一下。只是把问题抛到那里，以便我可以在同一时间仔细考虑讨论。
我在我的应用程序堆栈中使用Zend Framework。我正在使用APC进行服务器缓存（而不是memcache，因为我不相信memcache为我提供了任何好处，即使我的应用程序是分发的。）
我的应用程序已经构建为在没有JavaScript的情况下工作，然后为了支持JavaScript，我将页面分解并呈现JavaScript友好版本。
如果您分析一个简单的页面，其中80％可能是核心功能，可以为每个用户缓存。然后20％的是为该用户定制的。例如，我可能想要显示
这两个“小部件”将特定于每个用户。我正在考虑将ESI用于这些组件，但后来我认为任何/我的Zend Framework应用程序中最耗费的方面是引导和分派过程。因此，如果我的应用程序目前需要80毫秒没有缓存。就像在引导程序和插件钩子上花费90％的相对时间一样，如果我使用ESI来加载这两个“小部件”，那么我是否会有效地为每个页面添加负载？因为我将为每个缓存页面启动另一个80ms请求。
在这种情况下，您是否建议只通过JavaScript加载自定义小部件/片段，可以在加载初始页面后将其拉出。这样做的明显好处是，只有一个请求被缓存，然后在提供初始页面（缓存）后，在单个请求中提取任何自定义的内容。
如果我正在寻找最佳性能，这似乎是更好的解决方案？
答案 0 :(得分：1)
您可以构建第二个简单应用程序，该应用程序基于ajax调用从缓存中读取，如果信息尚未缓存，则仅引导程序。然后可以将响应添加到缓存中，以便进一步调用不会加载您的zend项目。这是一个正常的过程，但也需要编程高速缓存失效。你已经在使用适合这种情况的apc了。显然它不适用于最后5个观看或类似的内容。
答案 1 :(得分：0)
使用ESI的清漆无法帮助您减少页面加载时间，因为已知80ms已经很好（人类用户在1到500毫秒之间不会有任何差别......）
它可以帮助您避免重负载时服务器压力，这对于ESI和AJAX也一样。
如果您的优先级是尽可能快地显示主页面，那么AJAX是最好的方式，因为ESI会在发送整个页面之前等待子请求响应。
如果您仍然希望您的应用与非JS兼容，您可以过滤过滤器用户代理以尽可能使用JS，如果没有，则可以使用ESI，但这种技巧很容易变脏...