Page speed for ship-side users on satellite connections

Maritime websites are typically built and tested on a fibre connection in a London or Athens design studio. The marketing team approves it on a fibre connection. The Lighthouse score on fibre looks great. Then a chief engineer at sea, on a 2Mbps shared VSAT link, tries to download your spec sheet and gives up after 40 seconds. That’s a sale you didn’t know you lost.

Ship-side users matter. Technical superintendents, chief engineers, port captains, masters and crewing managers are all making purchasing-related decisions from vessels at sea. They visit equipment manufacturer sites to check parts availability, training providers to enrol crew, software vendors to evaluate fleet management tools. If your site is unusable for them, they’ll find the competitor whose isn’t.

What “satellite” actually means in 2025

Three connectivity tiers exist on most fleets:

1. Legacy VSAT. Often 256kbps to 2Mbps shared across the entire vessel including operational systems, with high latency and contention during peak hours. Still common on older tonnage and in routes outside major shipping lanes.

2. Modern VSAT and hybrid. 4 to 20Mbps with better latency. Container lines and tanker majors typically run on this.

3. LEO (Starlink Maritime, OneWeb). 50 to 200Mbps with low latency, increasingly common on newer tonnage, but adoption is uneven. Many vessels run hybrid Starlink plus VSAT, and crew are often capped or rate-limited regardless of pipe.

Designing for the middle tier (2 to 5Mbps with 600ms latency) keeps you accessible to roughly the whole global fleet. Designing for fibre keeps you accessible to your office.

What this means for the build

Aggressive page weight budgets. A homepage under 500KB transferred (excluding hero video, which should be lazy-loaded or replaced with a poster image). Service pages under 800KB. Anything heavier and the page is unusable on a contended VSAT link.

No render-blocking fonts. Self-host woff2, preload the regular weight, use font-display: swap. Avoid loading 14 weights of a variable font when you use three.

No autoplay video. A 6MB hero video that loads automatically will lock the connection on a vessel running other operational traffic. Use a static poster with a click-to-play option.

Lazy load aggressively. Native loading="lazy" on every image below the fold. Defer non-critical JavaScript. Avoid third-party scripts above the fold; chat widgets and consent banners are common offenders.

Minimise round trips. Each round trip on a satellite link can add 600ms latency. A page making 80 requests is fundamentally slower than the same page making 30, regardless of total bytes. Combine, cache, preload critical resources.

Cache hard. Long cache headers on static assets (1 year with versioned filenames). A returning ship-side user shouldn’t be re-downloading your CSS every visit.

Test the way ship-side users browse

Lighthouse on simulated 4G is not enough. Three real-world tests we run on every maritime build:

1. Chrome DevTools throttled to “Slow 3G” with high latency. Crude but useful. If the homepage is unusable, ship-side users will hit the same wall.

2. WebPageTest on an actual remote connection. WebPageTest has test agents in locations like South Africa or the South Pacific that better approximate satellite latency than a London test agent does.

3. Genuine field test. If you have a friendly relationship with a fleet operator, ask them to load your site from a vessel and screen-record the experience. We’ve watched 30 second loads turn into instant feedback that no Lighthouse run would surface.

The point

The buyer at sea is often the most committed buyer you have. They’ve taken time out of a watch to research your product. Build a site that respects their connection and you win that buyer. Build for fibre only and you cede them to whoever did the work.