Jamstack low-traffic site: drawing the line between pre-rendered pages and billed serverless functions
0 reputation · 02 Aug 2024, 11:36 UTC
0 reputation · 02 Aug 2024, 11:36 UTC
I'm planning a low-traffic content site on a Jamstack architecture: pages pre-rendered at build time, served from a CDN, with serverless or edge functions reserved for genuinely dynamic behavior. The goal is to keep monthly cost near the hosting platform's free or lowest tier.
The unresolved decision is where to draw the boundary. Several planned features sit in a gray area: a contact form, site search, and a small members-only section. Each could be implemented as a billed function invocation, handled client-side, or pushed to build time, and the choice changes both the cost profile and the architecture. Build frequency is also a factor, since content updates a few times per week and I'm unsure whether incremental builds or on-demand revalidation are worth the platform lock-in compared with full rebuilds.
Assume a current-generation static hosting platform with metered build minutes, bandwidth, and function invocations; exact limits need checking against current pricing pages.
Which of these features (form, search, gated content) genuinely require server-side functions rather than client-side or build-time handling? How should I estimate invocation volume for a low-traffic site before committing to a platform? Is on-demand revalidation worth the vendor lock-in at this scale?
31775 reputation · 02 Aug 2024, 12:32 UTC
For a low-traffic site, the goal is to shift as much logic as possible to the build phase or the client's browser to avoid metered serverless invocations. Of your three planned features, only gated content genuinely requires server-side logic for security.
| Feature | Recommended Approach | Cost Impact |
|---|---|---|
| Contact Form | Form-as-a-Service (e.g., Netlify Forms, Formspree) | Zero to low (usually free tier) |
| Site Search | Client-side JSON index or free-tier external API | Zero (client-side) or low (API) |
| Gated Content | Serverless Function / Edge Middleware | Metered per request |
search.json file at build time containing titles, slugs, and excerpts. Use a client-side library (like Fuse.js) to query this file. This moves the computation to the user's device.To estimate costs before committing, use a conservative formula based on user behavior rather than raw traffic:
Monthly Invocations = (Monthly Unique Visitors × Avg. Sessions per Visitor) × (Probability of accessing gated area × Requests per gated session)
For a low-traffic site, this usually falls well within the free tiers (often 100k to 1M requests/month) of modern platforms. The primary risk is not organic traffic, but bot scraping or DDoS attacks, which can exhaust free quotas quickly.
On-demand revalidation (ISR) is generally not worth the lock-in for content updated a few times per week. Full rebuilds are more portable and ensure a consistent state across the entire site.
Recommendation: Stick to full rebuilds. If build times exceed your platform's free minutes, optimize your build pipeline (e.g., by caching dependencies) before moving to a vendor-specific revalidation strategy.
search.json. If it exceeds 100KB, it may negatively impact Largest Contentful Paint (LCP).Note: To refine the gated content recommendation, are you using a third-party Auth provider (like Auth0 or Clerk) or a custom database?
Use comments to ask for clarification. Post a solution as an answer.
No question comments on this page.