Next.js development for Bristol engineering and purpose-led firms

Bristol asks a question about websites that almost nowhere else asks: what does it cost to run.

Part of that is the city's engineering base - aerospace, environmental consultancy, energy - where people are used to thinking about efficiency as a measurable property. Part of it is the concentration of certified and purpose-led businesses, which report on things most companies never look at. Either way, "how many bytes does a visit transfer" is a procurement question here rather than an engineer's private concern.

Page weight as a number somebody reports

The useful thing about this constraint is that it points in the same direction as every other good decision.

A lighter page is faster. Less JavaScript parsed is both less energy on the device and less waiting for the person holding it. Fewer server renders is both lower compute and lower latency. There is no version of this where the sustainable choice and the fast choice disagree, which makes it unusually easy to act on.

What we can report honestly is bytes transferred per visit, requests per page, JavaScript executed, and how often the server has to do work rather than serve something it already had. Those are measurable before and after. What nobody can report honestly is a single gram-of-carbon figure, because that depends on the energy mix of a data centre and a device neither of us controls - so the number we quote is the one we can defend.

In practice the reductions come from the same places every time: images sized for the device rather than for the design file, fonts self-hosted and subset, third-party scripts removed rather than deferred, and components that did not need to be interactive rendered on the server. How images decide performance usually accounts for the largest single reduction.

Telemetry interfaces, and the temptation to make them live

The engineering half of Bristol brings a different problem: the data does not sit still.

Sensor readings, flight test data, environmental measurements, energy figures - these arrive continuously, and the instinct is to build a live dashboard. That instinct is usually wrong, and expensively so. A page holding an open connection and re-rendering on every reading keeps the browser busy permanently in order to display a figure somebody glances at twice an hour.

The better default is to fetch at the rate the number is actually read, and to show when the reading was taken rather than implying it is current. That is honest, it is cheap, and it is consistent with the rest of the argument on this page. When something does need to be genuinely live - an alarm state, a test in progress - it should be one component with a connection rather than a page that never settles.

Hosting inside the UK, when a client requires it

Bristol's aerospace and defence supply chain brings this requirement regularly, and it is better treated as an input than as a surprise.

It means the application runs on infrastructure the client or we control rather than on a platform with its own defaults. Four things change, all of them known: image optimisation needs an answer, revalidation needs a cache shared between replicas, middleware stops running at an edge, and a reverse proxy in the path must not buffer streaming responses. Running Next.js yourself covers each.

Commercially

Scope fixed in writing before work starts, priced per project. The country-level ground - UK data protection, consent, invoicing in pounds - is on the United Kingdom market page.

Invoiced by Codefacture Yazılım A.Ş. in Türkiye, in pounds by bank transfer, with no Turkish VAT because exported services are exempt.