Static Site Generators in Production

Handling Form Submissions on a Static Site

The first time a static site needs a contact form, the absence of a server becomes concrete: an HTML form has to post somewhere. The options range from one attribute on the form element to a small function you own, and each makes different trade-offs on spam, privacy, cost, reliability and — frequently overlooked — the weight it adds to the page. Many teams reach for an embedded widget from a form service and ship 150 KB of JavaScript to render three input fields.

This guide compares four approaches on the same contact form, measured for page weight, spam received and operating cost over a month, and gives a decision rule. It is part of Serverless Functions for Static Sites.

Prerequisites

  • A static site and a clear list of what the form collects and where submissions should go.
  • An understanding of any data-protection obligations for the data collected — names and email addresses are personal data in most jurisdictions.
  • For the function option, a host that runs functions: Cloudflare, Netlify, Vercel or equivalent.

The Form Itself

Whatever handles it, the form should be ordinary HTML that works without JavaScript:

<form method="post" action="/api/contact" class="contact-form">
  <label for="name">Name</label>
  <input id="name" name="name" required maxlength="100" autocomplete="name">
  <label for="email">Email</label>
  <input id="email" name="email" type="email" required maxlength="200" autocomplete="email">
  <label for="message">Message</label>
  <textarea id="message" name="message" required maxlength="5000" rows="6"></textarea>
  <div class="hp" aria-hidden="true"><label>Leave this empty <input name="website" tabindex="-1" autocomplete="off"></label></div>
  <input type="hidden" name="ts" value="">
  <button type="submit">Send</button>
</form>
<script>document.querySelector('[name=ts]').value = Date.now();</script>

The website field is a honeypot hidden with CSS; people never fill it, many bots do. The ts field records when the page loaded, so the handler can reject submissions made faster than a human could type. Both are invisible to readers and cost nothing.

Four Approaches

1. Host-native forms (Netlify Forms). Add data-netlify="true" and a name to the form; Netlify detects it at build time and captures submissions, with spam filtering and email notifications. Zero code, zero JavaScript, generous free tier. Tied to Netlify.

2. Hosted form services with an action URL. Services such as Formspree or Basin give you an endpoint to use as the form action. Plain HTML, no script required, submissions forwarded by email or webhook. Your readers' data passes through a third party.

3. Embedded form widgets. Tools that render the form themselves via a script or iframe. Quick to set up and rich in features (conditional fields, file upload, analytics), but heavy and often a source of layout shift — see Fixing CLS from Late-Loading Embeds.

4. Your own function. A handler at /api/contact validates the fields, applies spam checks, stores or forwards the submission and redirects to a thank-you page. Full control over data, validation and destination; a few dozen lines to maintain. Built end to end in Adding a Contact Form with Cloudflare Workers.

Where submissions go under each approach Four paths from the same HTML form. Host-native forms post to the host, which stores and emails. A hosted service action URL posts to a third party that forwards by email or webhook. An embedded widget replaces the form with a third-party iframe or script that posts to the vendor. Your own function posts to your endpoint, which validates and forwards to storage or email you choose. Same form, four destinations <form> plain HTML 1 · host captures 2 · service action URL 3 · vendor widget 4 · your function host dashboard + email third party → email / webhook vendor script + vendor storage your validation → your destination
Only the widget replaces your markup; the other three keep the form as HTML you control.

Measured Comparison

The same contact form was deployed four ways on a documentation site for four weeks each, with similar traffic (about 11,000 contact-page views per period). Page metrics are Lighthouse 12 mobile medians; spam is submissions a person had to discard.

MeasureNetlify FormsService action URLEmbedded widgetOwn function (Worker)
JavaScript added to page0 KB0 KB148 KB0.2 KB
Contact page LCP1.2 s1.2 s2.7 s1.2 s
CLS0.000.000.190.00
Legitimate submissions61584963
Spam reaching the inbox142252
Monthly cost at this volume00–10 USD0–29 USD~0 (free tier)
Data leaves your infrastructurehost onlyyesyesno
Page cost and spam by approach Two charts. Contact page LCP was 1.2 seconds for host forms, service URL and own function, and 2.7 seconds for the embedded widget. Spam reaching the inbox per four weeks was 14 for host forms, 22 for the service URL, 5 for the widget and 2 for the own function with honeypot, timing and Turnstile. What each approach costs the page, and what gets through LCP (s) 1.2 1.2 2.7 1.2 spam in inbox / 4 weeks 14 22 5 2 host service widget function host service widget function
The widget blocked spam well but doubled LCP; the function matched the best spam result with no page cost.

The widget's spam performance came from a visible CAPTCHA, which also plausibly explains its lower count of legitimate submissions: 49 against 58–63 for the other approaches over similar traffic. The function combined honeypot, timing, validation and an invisible Turnstile challenge to reach two spam messages in four weeks without asking readers to solve anything.

Spam Defences in Order of Cost

Layer defences from free and invisible to costly and visible, stopping when spam is low enough:

  1. Honeypot field — catches naive bots. Free, invisible.
  2. Minimum time-to-submit (reject under 3 seconds) — catches scripted posts. Free, invisible.
  3. Server-side validation — length limits, email syntax, reject messages that are only links. Free, invisible.
  4. Rate limiting per IP (for example five per hour) — stops floods. Free on most platforms.
  5. Invisible challenge (Cloudflare Turnstile, hCaptcha passive) — stops headless browsers. Free or cheap, usually invisible.
  6. Visible CAPTCHA — last resort; costs real submissions.

On the function version, layers 1–3 alone stopped 94% of spam attempts; Turnstile stopped most of the rest.

Spam attempts remaining after each defence layer A funnel of 1,240 spam attempts over four weeks. The honeypot leaves 410. The minimum time check leaves 160. Server-side validation leaves 74. Rate limiting leaves 58. The invisible Turnstile challenge leaves 2 that reached the inbox. 1,240 spam attempts, six cheap filters attempts · 1,240 after honeypot · 410 after time check · 160 validation · 74 rate limit · 58 Turnstile · 2
Every layer is invisible to readers; the visible CAPTCHA the widget used was never needed.

Log what each layer rejects, with counts rather than contents. When spam changes shape — and it does, every few months — the counts show which layer stopped catching it, which is far faster to act on than reading rejected messages.

Privacy and Data Handling

A form collects personal data, and each approach puts it in a different place. Host-native forms store submissions in the host's dashboard; service action URLs and widgets send them to a third party, which becomes a processor you must list in your privacy notice and possibly sign a data-processing agreement with. Your own function can forward to a destination you already control — a ticketing system, an inbox, a database in a specific region — and nowhere else. Whatever the approach, set a retention period and delete old submissions; a contact form that silently accumulates years of names and emails is a liability. Add a short line under the form saying where the data goes and how long it is kept.

Accessibility and Feedback

A form that works for everyone needs a little more than inputs. Every field needs a visible <label> tied by for/id, not just a placeholder. Errors returned by the server should come back on a page that repeats the reader's input and names the problem next to the field, with the first error focused and an aria-live summary at the top. The success page should say what happens next — "we reply within two working days" — rather than just "thanks". With JavaScript enhancement, keep the same behaviour: announce success or errors in a live region and move focus sensibly. On this site, adding field-level error messages cut abandoned submissions (a validation error followed by no retry) from 18% to 6%.

Choosing

  • On Netlify, with a simple contact form: use Netlify Forms. It is the least work and adds nothing to the page.
  • On another host, low volume, no strong privacy requirements: a service action URL on a plain HTML form.
  • You need control over data location, validation or destination, or spam is a problem: your own function.
  • You need conditional logic, file uploads and a form builder non-developers can edit: a widget, loaded on click or below the fold, with space reserved to avoid layout shift.

Pitfalls & Rollback

  • Forms that need JavaScript to submit. Keep method and action on the form so it works when scripts fail.
  • Client-side validation only. Always validate on the server; client checks are a convenience.
  • Widgets above the fold. They delay LCP and shift layout. Load them lazily or not at all.
  • Real submissions from previews. Preview deploys run the same form; route them to a test inbox.
  • Rollback: the form's action attribute is the switch. Pointing it back at the previous handler reverts the change on the next deploy.

Conclusion

A static site can accept form submissions without a server and without a heavy widget. Host-native forms are the simplest; a service action URL is portable; your own function gives full control over data and spam. On one documentation site, the function approach matched the best spam result — two messages in four weeks — while adding no JavaScript and keeping LCP at 1.2 seconds, where an embedded widget had pushed it to 2.7.

FAQ

What is the simplest way to add a form to a static site?

Use your host's built-in form handling if it has one, such as Netlify Forms, which captures submissions from a normal HTML form with one attribute. It needs no code and no third-party script, and it is enough for most contact forms.

Do embedded form widgets hurt performance?

Often. Many hosted form widgets inject an iframe or a script bundle of 100 KB or more, which delays rendering and can shift layout. A plain HTML form posting to an endpoint adds no JavaScript at all.

How do I stop spam without a CAPTCHA?

Combine a hidden honeypot field, a minimum time between page load and submission, server-side validation, and rate limiting per IP. Add an invisible challenge such as Cloudflare Turnstile only if spam still gets through.

Where should submissions be stored?

Somewhere your team already works and that meets your data-protection obligations: an email inbox for low volume, a ticketing system for support, or a database in the right region for anything that needs retention rules. Avoid storing personal data in services you have not reviewed.