I'm building an SEO-focused website that uses server-side rendering and a database to display financial research reports. Even loading the homepage or opening a single report can trigger several Worker invocations. I'd like to reduce those requests without rebuilding the entire site whenever a report changes. CDN or edge caching seems like the obvious solution, but I'm wondering whether there are other effective approaches.
I've also considered switching some pages to client-side rendering, but I'm concerned that search engines might not index reports properly if the content has to be fetched from the database in the browser. Is that a legitimate concern, or is client-side rendering reliable enough for pages that need to rank in search results?
4 Answers
First measure which routes are responsible for the invocations. Static assets, favicons, robots.txt, sitemaps, and requests for nonexistent URLs can easily outnumber actual page renders. Move static files to a static asset setup so they don’t pass through the Worker.
For the reports, keep SSR and cache the generated HTML at the edge with headers such as public, s-maxage, and stale-while-revalidate. Then repeated requests for the same report can be served from cache without waking the Worker every time. When a report changes, purge its cache key or tag instead of waiting for the normal expiration time.
I would avoid switching every indexable report to client-side rendering. Major search engines can render JavaScript, but that often happens in a later processing stage and may introduce delays; some other crawlers may not render it at all. If individual stock reports need to rank for searches, server-rendered or pre-rendered HTML is safer.
A hybrid setup could work well: use static generation or cached SSR for the public report pages, and client-side rendering for interactive features that don’t need to be indexed. You don’t necessarily need to rebuild the entire site whenever data changes if the rendered pages are cached and selectively invalidated.
The reports are for financial research, especially individual stocks, so having each report indexable is important rather than only optimizing the landing page.
Caching is probably the best fit here. You can use response headers or the platform’s edge cache so each report URL is cached for a chosen period. Stale-while-revalidate is useful because visitors receive the cached version immediately while the edge refreshes it in the background.
You can also make the homepage, robots.txt, sitemap, and other mostly static pages fully static. The report pages can remain dynamically generated while still benefiting from edge caching.
Static generation is another option if reports don’t change constantly. Generate or refresh only the affected report instead of rebuilding the whole site. If reports update frequently, cached SSR with a short TTL and targeted invalidation gives you a similar result while keeping the database-backed content dynamic.
That makes sense. I hadn’t considered that assets and crawler requests might be a larger part of the total than the page renders themselves.