Blog Sections Open
Caching Pages Selectively When GET Parameters Are Present
Not every GET parameter deserves its own cache file. Search terms in particular usually create noisy, low-value cache variants that are better left uncached.
Once a project begins to vary output by $_GET, caching policy becomes more important. The old question behind this topic was straightforward: if search pages depend on query parameters, should those pages be cached at all?
The Short Answer
Usually no. Search result pages are a bad fit for broad GET-based caching because every unique query can produce another cached variant, and most of those variants will never be requested again.
A Better Rule
- leave search pages uncached
- cache only GET parameters that represent stable, reusable page states
- prefer an allowlist over a blanket “cache everything with GET” rule
Good Candidates for Cached GET States
- language switches
- catalog filters with a small number of combinations
- sorting modes that are reused often
Poor Candidates
- full-text search terms
- tracking parameters
- one-off ad landing query strings
The old forum suggestion was sensible: cache settings should ideally support either an allowlist or a denylist for parameters. That is still the cleanest way to keep cache growth under control while preserving performance where caching actually helps.
Shrinking an Oversized `modx_session` Table
What to check when the session table becomes enormous: retention, bot load, session handler choices, and safe cleanup options.
Speeding Up Search on Large Evolution CMS Sites
How one large-site AjaxSearch setup was improved by narrowing whereSearch and moving TV lookup into withTvs instead of scanning every TV field.