I'm building an ad-supported website with publicly accessible financial research reports, especially stock analysis. The site uses server-side rendering and a database, but even visiting the homepage or opening one report can trigger several Worker invocations. I'd like to reduce those requests without rebuilding the entire site whenever reports change. Edge or CDN caching seems like the obvious solution, but I'm wondering what else I should check. Would switching to client-side rendering hurt indexing, since crawlers would need to wait for report data to load from the database, or is SSR still the safer approach for pages that need to rank?
4 Answers
I would not switch important report pages entirely to client-side rendering if search traffic matters. Google can render JavaScript, but it may process those pages later, and many other crawlers do not execute JavaScript reliably. Keep the indexable report content in the initial HTML. The homepage, robots.txt, sitemap, and other mostly static content can be prebuilt or served as static pages, while the dynamic reports are cached SSR responses.
First measure which routes are responsible for the invocations. Static assets, favicons, robots.txt, sitemaps, and requests for missing URLs can add up quickly. Serve those through static hosting or an assets binding so they do not run through the Worker. For report pages, keep SSR and cache the generated HTML at the edge with headers such as public, s-maxage, and stale-while-revalidate. Then repeated visits can be served from cache instead of invoking the Worker every time. When a report changes, purge its cache entry or tag rather than forcing a full site rebuild.
Caching is probably the main solution here. Cloudflare’s edge cache can cache Worker responses, and stale-while-revalidate lets visitors receive the existing version while the cache refreshes in the background. Use a stable, canonical URL for each report so different query strings or URL variations do not create unnecessary cache misses.
A static site or static hosting service works well for the fixed parts of the site, but it does not eliminate the need for dynamic rendering if every report comes from a database. A hybrid setup is usually better: static delivery for the shell and assets, SSR for report pages, and edge caching for the rendered results. Since the reports are financial research and need to rank for stock-related searches, making each report URL directly indexable is reasonable.
That also avoids making the freshness decision too early. You can use a reasonable cache lifetime and invalidate only the reports that actually changed.