Должно ли кэширование меню WordPress быть специфичным для каждой страницы?

Введение

При оптимизации больших веб-сайтов WordPress для повышения производительности я всегда обращаю внимание на кэширование определенных частей веб-сайта, в основном (конечно) тех, которые требуют большого количества запросов/вычислений.

Для кэширования меню WordPress я обычно использую функцию, подобную той, которую я опубликовал в качестве ответа здесь.

Эта функция проверяет, существует ли переходный процесс, содержащий HTML-код меню, и, если он существует, доставляет HTML из переходного процесса. Если он не существует, меню строится и устанавливается переходный режим. Чтобы быть чистым, я также подключаюсь к wp_update_nav_menu, чтобы очистить переходный процесс, как только меню будет сохранено, чтобы всегда была доступна последняя версия.

Пока все идет хорошо.

Этот метод работает очень хорошо и дает большой прирост производительности, особенно если меню содержит много записей.

Проблема

Теперь, через несколько месяцев после разработки этого метода, я столкнулся с проблемой и чувствую себя глупо из-за того, что не подумал об этом в первую очередь.

Меню на разных страницах разные

В зависимости от того, какая страница называется, wp_nav_menu предоставляет различный HTML-код. current-menu-item и подобные классы, конечно, применяются к элементам меню.

Итак, проблема в том, как лучше всего кэшировать меню и при этом иметь правильные классы, доступные для каждой конкретной страницы?

Я думал о двух версиях

• добавление классов с помощью jQuery, что приводит к большему вычислению на Клиентская сторона
• кэширование меню для каждого ID отдельно, что приводит к довольно большой загрузке базы данных, если на странице много меню

Однако я склонен использовать второй вариант. У вас есть какие-либо проблемы с кэшированием такого количества HTML в качестве переходных элементов?