Performance: Caching strategy for public pages #60
Description
Summary
The public-facing pages have no visible caching strategy. As data grows, queries for the homepage (worth watching, recent signals, upcoming/recent meetings) and topic pages (appearances, status events, continuity) could become expensive.
Current State
- Solid Cache is configured in the stack but no explicit caching is implemented in controllers or views
- Homepage builds multiple complex queries: active topics with upcoming meetings, topics with recent continuity events, meetings grouped by week
- Topic show page queries appearances, status events, and summaries
- Meeting show page queries documents, topic summaries, and agenda items
- pgvector similarity searches for topic matching could be expensive under load
Proposed Approach
Fragment Caching
- Cache "Worth Watching" and "Recent Signals" cards on homepage (invalidate when topic continuity updates run)
- Cache topic timeline sections on topic show page
- Cache meeting summary sections on meeting show page
Russian Doll Caching
- Meeting cards within week groups (cache key includes
meeting.updated_at) - Topic cards within lifecycle groups (cache key includes
topic.updated_at) - Summary content blocks (cache key includes
summary.updated_at)
Query Optimization
- Review N+1 queries with
bulletgem or manual inspection - Add counter caches where appropriate (e.g.,
topics.appearances_count) - Consider materialized views for homepage aggregations if query complexity warrants it
pgvector Index Tuning
- Review
ivfflatvshnswindex performance for knowledge chunk similarity search - Tune
listsparameter based on data volume - Consider approximate nearest neighbor settings
Measurement
Before optimizing:
- Add request timing to key pages
- Profile with
rack-mini-profilerin development - Identify actual bottlenecks before applying caching
Priority
Low until traffic increases — premature optimization isn't warranted, but the strategy should be documented so it can be applied when needed.