What Our Contact Form Was Downloading: A Measured JavaScript Cleanup

A contact form needs enough information to let a visitor select a service and send an enquiry. While reviewing BringPak's own site on 15 October 2026, we found that the browser was also receiving full service-guide paragraphs. The form used the guide list for names; importing that list also brought along the longer explanations.

We separated the names and slugs into a compact shared catalogue. In a comparison of two local production builds using the same webpack settings, the scripts referenced by the contact HTML became 34,401 uncompressed bytes smaller. The deterministic gzip estimate fell by 11,814 bytes, or 4.65%. This note explains exactly what those numbers measure.

Finding the dependency, rather than guessing from a page score

The investigation started with the public contact JavaScript. Three distinctive phrases from the service guides appeared in a route script even though those paragraphs were not part of the form. Source tracing showed two relevant imports: the form's service choices and the contact validation list both depended on the complete guide array.

This is an easy dependency to overlook. A data file can contain useful names alongside introductions, FAQs and long sections. A browser component that maps that array to display names may still cause the complete data to be included in its build output. The important question is what actually ships, rather than what the component visibly renders.

The change: one small catalogue, shared names

We created a catalogue containing the eight guide names and slugs. The full guides reference those canonical names. Form options, contact preselection and shared validation use the compact catalogue. This keeps the public guide pages available while removing their article bodies from the form's dependency path.

The service choices, order and accepted values stayed the same. A regression check compares the compact catalogue with the actual guide list so an option cannot silently diverge from the page it represents. This was an import and data-organisation change, not a redesign of the enquiry process.

What we measured

For each local production build, we fetched the contact HTML, collected its unique external Next.js script URLs and downloaded those scripts. We added their uncompressed sizes and used the same gzip function with a fixed timestamp to estimate compressed sizes. Both builds referenced 15 script files.

Measurement	Before	After
Referenced script files	15	15
Uncompressed bytes	810,582	776,181
Estimated gzip bytes	253,903	242,089

The three guide phrases were present in the initial script sample and absent after the change. The complete measurements and method are available in the public measurement record (JSON). This record contains build totals and limitations, not customer or enquiry data.

What these results do and do not establish

The result establishes a smaller set of initial HTML-referenced scripts for this local build comparison. It does not include every dynamically loaded or prefetched resource. The gzip figures are deterministic estimates, not the exact bytes a CDN sent to a visitor.

We did not measure a change in field Core Web Vitals, enquiries, sales or search rankings in this comparison. A smaller script can reduce work the visitor's browser has to download and process, but its effect on a particular visit also depends on the connection, cache, device and what the page is doing. A lab loading sample is a separate measurement from a build-size check.

Framework and compiler settings matter as well. Comparing a public Turbopack build with a local webpack build would introduce another variable. We used the same local build settings for the before-and-after totals instead.

Checking that the form still worked

The optimized production build passed TypeScript and the focused lint checks. Tests checked the service catalogue, contact preselection and campaign handling. A browser test followed a labelled service visit into the contact form, filled the form and inspected the outgoing request.

For that browser test, the contact request was intercepted and answered with a synthetic receipt. It checked the request and success interface without creating a real enquiry. Separate route tests used an isolated temporary database. These checks reduce regression risk; they are not records of customer conversions.

A useful question for your own website review

If a small interactive element imports a large data file, ask what part of that file reaches the browser. Service lists, product options and navigation menus can be worth inspecting. Keep the explanation a visitor needs on the page, while separating unrelated data from interactive code.

Ask whoever performs the work to name the page, build settings, included resources and measurement method. A claim such as “the site is faster” is much easier to assess when it is tied to a documented comparison and a check that the customer task still works.

Next.js's official package-bundling guide explains how client dependencies affect shipped code and how to investigate bundles. For a wider review of an existing site, see website maintenance or website redesign planning. Use our monthly website checklist to include the contact journey in routine checks.