Timber全局$context的大小是否会对网站运行性能产生影响？

提问内容 #

我正在尝试优化网站性能，想了解这类操作是否会对性能产生影响。
我目前会向$context中添加若干变量，实现代码如下：

public function add_to_context( $context ) {
    $context['query'] = $GLOBALS['wp_query']->query_vars;
    $context['menu'] = new Timber\Menu('main-menu', array( 'depth' => 2 ));
    // 其他自定义变量逻辑
    $context['footer_menu'] = new \Timber\Menu( 'footer-main-menu' );
    $context['footer_support'] = new \Timber\Menu( 'footer-support-menu' );
    $context['footer_legal'] = new \Timber\Menu( 'footer-legal-menu' );
    return $context;
}

性能影响说明 #

这类操作确实会产生额外的性能开销，具体影响程度取决于你的站点配置和缓存策略：

• 每初始化一个Timber\Menu实例，都会触发一次WordPress菜单查询，内部需要执行菜单项读取、权限校验、URL生成、结构组装等逻辑，多个菜单同时初始化的开销会叠加，未做缓存时每次页面请求都会重复执行这些逻辑，如果你的单菜单的菜单项超过几十项，4个菜单加起来会产生明显的查询耗时。
• 如果这些菜单是全站所有页面都要渲染的，那这个开销属于必要支出，不会产生冗余浪费；如果只有部分页面需要用到其中某几个菜单，全局统一初始化就属于冗余开销，会拖慢不需要这些菜单的页面加载速度。

优化方案 #

你可以根据自己的业务场景选择对应的优化方式：

• 按需加载菜单：不要把所有菜单都塞到全局context里，只在对应页面/模板的渲染逻辑中初始化需要用到的菜单，比如三个底部菜单只在页脚模板渲染前初始化即可，不需要在全局add_to_context钩子中统一处理。
• 增加菜单缓存：对于长期不会变动的菜单，可以把初始化后的实例用WordPress原生的transient机制缓存，菜单后台更新时主动清理缓存即可，参考实现如下：

public function add_to_context( $context ) {
    $context['query'] = $GLOBALS['wp_query']->query_vars;
    
    // 缓存主菜单，有效期12小时
    $main_menu = get_transient( 'timber_cache_main_menu' );
    if ( false === $main_menu ) {
        $main_menu = new Timber\Menu('main-menu', array( 'depth' => 2 ));
        set_transient( 'timber_cache_main_menu', $main_menu, 12 * HOUR_IN_SECONDS );
    }
    $context['menu'] = $main_menu;
    
    // 其他底部菜单按同样逻辑加缓存即可
}

• 配合页面静态缓存：如果你的站点已经配置了页面级静态缓存（比如插件生成静态HTML、Redis页面缓存等），菜单初始化的开销只会在缓存生成时执行一次，对普通用户访问的影响几乎可以忽略，不需要额外做改造。

内容的提问来源于stack exchange，提问作者Luka Juras