Какие способы хранения настроек userа оптимальны (css по большей части)?

Для чистых свойств уж очень много запросов будет скажем 30 блоков по 5-10 шт (150-300) на 1 страницу. конечно значение на запись не постоянное, но вот на чтение будет постоянным.
+ интервальная перезапись свойств + количество запросов на саму страницу с redis (100+-)

Может кончено зря так загоняюсь.

запрос будет только 1
и тот будет кэширован

Дмитрий,
Может я чего-то не понимаю

Дмитрий, Если есть одна страница с кучей полей, то по идее да один, но когда страница на которой выводятся повторяемые группы полей через цикл то каждая группа это отдельные запросы. Во всяком случае query monitor не двусмысленно это показывает.

ppskmg, ну может вы там кэш выключили или как-то своеобразно кастомные поля получаете

вот тут как оно должно работать из коробки
https://wordpress.stackexchange.com/a/177849

Дмитрий, скорее второе, видимо логика плагина такая. или тут иначе не сделать.
структура самого поста такая:
Страница
Кастомное поле
—Группа повторяемых полей
——Поле
——Поле
——Поле и тд.
Кастомное поле

Возможно запросы идут так:
Страница (запрос 1)
Кастомное поле (метаданные из запроса 1)
—Группа повторяемых полей(запрос 2)
——Поле (мета з-с2)
——Поле (мета з-с2)
——Поле и тд. (мета з-с2)
—Группа повторяемых полей(запрос 3)
——Поле (мета з-с3)
——Поле (мета з-с3)
——Поле и тд. (мета з-с3)
и тд.

По вашей ссылке, видимо это тот самый случай

В худшем случае вы вызываете get_post_meta отдельные идентификаторы постов, которые не были получены WordPress ранее. В этом случае каждый вызов get_post_meta приведет к одному запросу.

Возможно каждая группа полей как отдельная запись + какие то ещё запросы с этим связанные

ppskmg, без кода гадать толку мало.

но если
это одна страница is_singular(),
там есть стандартный луп,
все произвольные поля принадлежат ей,
то все запросы будут из кэша