Redis
Redis caching experience at Legrande Legal includes WordPress object caching alongside a PHP runtime upgrade. The work supports the existing application without changing its editorial ownership or theme attribution.
Where the engineering matters
A cache is useful only when freshness and invalidation match the application. It is one part of the operating environment, alongside runtime compatibility, backups, and the release procedure used to put changes in place.
Work represented in the portfolio
- Redis object caching in the Legrande engagement
- Runtime work around an existing WordPress site
- Release and recovery procedures scoped to the deployment
The Legrande case connects this caching work with the broader runtime upgrade and continued operation of its custom website.
Redis caching experience: planning a similar project
Before adding a cache, identify the application data being reused and when it must change. Separate object caching from the public-page caching handled elsewhere in the request path. Legrande documents Redis within a broader runtime engagement.
For a new project or changes to an existing system, explore ongoing website and software development.
Assess object caching against actual publishing tasks
WordPress’s object cache documentation distinguishes request-local caching from persistent caching and identifies Redis-backed options. Before changing an existing site, confirm which cache layers it already uses. A page cache, an object cache and a browser cache store different things, so a faster repeat page view alone does not explain which change helped.
Choose representative tasks for the review: opening a public page, signing in, editing content and checking the published result. Record a baseline, repeat the same tasks after the change and check that updates remain visible. Also agree how to disable the added cache if application behavior changes unexpectedly. This evaluation would be specific to the new site; the Legrande case documents the earlier runtime engagement.