Interaction brief · Stockholm
Stockholm: the metric that is not load time
This audience judges a product page by how quickly it responds to a tap, which is a different number from how quickly it appeared.
The short answer
In Stockholm the number worth arguing about is interaction to next paint, not load time. Two hundred milliseconds is the good threshold, and it is mostly decided by JavaScript running on the visitor's phone rather than by anything a server does. A site that paints in a second and then ignores the first tap for half of one reads as broken to an audience this fluent.
The server still owns a piece of it. First byte from a warm LiteSpeed cache leaves the whole rest of the budget for your own code, NVMe keeps the uncached paths honest, and per-site PHP switching means the API behind the product page is not held back by a legacy dependency somewhere else on the account.
By the HostingFast team · Reviewed 12 August 2026
24/7
Engineers on shift
1-click
WordPress in one click
Free
SSL certificates
Daily
Backup cadence
Per head, no European city has produced more billion-dollar technology companies. Payments, streaming, gaming and fintech all came out of these islands, in a market that went mobile and effectively cashless while the rest of the continent was still discussing it.
So the reader here already knows what a waterfall is. This page covers which of the three vitals actually bites on a Swedish product site, where the milliseconds are going, what the origin contributes, and how to hold the number after launch.
Interaction to next paint, and what causes it
Interaction to next paint measures the gap between a tap and something visibly changing. Two hundred milliseconds is the threshold to beat, and the cause is nearly always the main thread being busy: a bundle that hydrates the entire page, a consent banner that blocks, an analytics tag that runs on every scroll event. None of that is hosting, and pretending otherwise wastes your afternoon.
Read the field figure in PageSpeed Insights rather than the lab score, because interaction is by definition something a real person does and a simulated run cannot. Then use the browser's performance panel on a throttled profile and look for long tasks. The offender is usually one script you inherited rather than the framework you chose.
The third-party tax, counted honestly
Tag managers, session recorders, chat widgets, three analytics vendors because three teams each asked for one: on a typical Swedish startup landing page that stack outweighs the application it is measuring. Every one of them is a DNS lookup, a handshake and a block of main-thread work you do not control and cannot profile properly.
Audit it once a quarter with the network panel filtered to third-party origins, and delete rather than defer wherever the owner cannot say what the data is used for. This is the single highest-yield performance work available to most product teams, and it costs nothing but an argument.
What the origin is responsible for
Sweden sits in the Western and Northern Europe band we publish for the London origin at 10 to 35 milliseconds of round trip, and a cached page crosses that once. Our part of the budget is first byte: NVMe storage under a LiteSpeed cache built into the server, so the marketing pages are served without PHP running, and per-site PHP switching so the parts that must run are on a current version.
Where the origin does show up is the uncached path — sign-up, dashboard, anything authenticated. Those make the full trip on every request, and if that is where your product actually lives then it deserves measuring separately from the landing page that gets all the attention.
Holding the number after launch
Performance is not a project, it is a regression risk. Put the two figures — field LCP and field INP for your busiest template — somewhere the team sees them, and re-read them after every release rather than after every complaint. Field data lags a deployment by weeks, so say which number you are quoting when somebody disputes it.
On the platform side the tools are ordinary and available: staging copies to prove a change first, daily backups to undo one, SSH with Git and Composer for the deploy, and real cron rather than a web-triggered imitation for the jobs that must run whether or not anybody visits.
What we own, and what you do
The origin's job is a fast first byte and honest uncached paths: NVMe storage, a LiteSpeed cache in the server, current PHP per site, and Node.js, Python or Ruby where an application needs them.
The rest of the number belongs to your bundle, and we would rather say so than sell you a plan that cannot fix it.
- Server-level caching for a first byte you can measure
- Node.js, Python and Ruby on the developer tiers
- Real cron, not a web-triggered imitation of one
- .se registered and renewed on the hosting account
Why HostingFast
Standard on every plan
First byte out of the way
A LiteSpeed cache inside the server means the marketing pages answer without PHP running, leaving the rest of the budget for your own code.
Current PHP, per site
Version switching is per site from the panel, so a legacy service does not pin the rest of the account to an old runtime.
Runtimes beyond PHP
Node.js, Python and Ruby deploy natively on the developer-focused plans, with PostgreSQL alongside MySQL.
Deploys from the command line
SSH with Git and Composer as standard, and real cron for the jobs that must run whether or not a visitor triggers them.
A place to prove a release
Staging copies mean a bundle change is measured on a duplicate before the field data starts telling everyone about it.
Support that talks in layers
Engineers on shift around the clock, first reply inside two hours and inside one when a site is down, able to say which layer is responsible.
Quick Start
From order to online
- 1
Read the field data
PageSpeed Insights on the busiest template, Core Web Vitals block at the top, both LCP and INP. Lab scores flatter; field data does not.
- 2
Cut the third parties
Filter the network panel to third-party origins and remove anything whose owner cannot name the decision it informs. Re-measure a fortnight later.
- 3
Move the origin, then compare
Free migration with the old site serving throughout, DNS on your sign-off, and the same two field figures read again once they catch up.
Built In
Loaded onto every plan
- LiteSpeed caching inside the server rather than added by plugin
- Per-site PHP version switching from the control panel
- Node.js, Python and Ruby deployable on the developer plans
- PostgreSQL alongside MySQL where the application wants it
- SSH, Git and Composer available from the first day
- Real cron jobs rather than a web-triggered imitation
- Staging copies for proving a release before it ships
- Daily backups with self-service restores from the panel
- Every plan sits on NVMe, including the smallest one
- Free SSL on every plan, reissued before it can lapse
Frequently Asked
What people ask us most often
Our lab score is ninety-something and users still say it feels slow. Which is lying?
Neither, but they measure different things. A lab run simulates one load on one machine; the field data in PageSpeed Insights comes from real Chrome users on real phones and includes what happens after the page appears. Interaction to next paint lives almost entirely in that second half, which is why a high lab score and an unresponsive page routinely coexist.
How much of interaction time can a hosting company actually influence?
Honestly, a minority of it. First byte and the speed of any uncached API call behind the interaction are ours; the main-thread work that follows a tap is your bundle and runs on the visitor's device. We would rather be clear about the split than sell an upgrade that cannot move the number you are looking at.
We run a Node service beside the WordPress marketing site. Is that supported?
Yes, on the developer-focused plans: Node.js, Python and Ruby deploy natively, PostgreSQL sits alongside MySQL, and SSH with Git and Composer is there from day one. Keep the marketing site cacheable and let the service be the uncached part, which is the arrangement that measures best in practice.
Which pages should we actually be watching?
The busiest template rather than the homepage, plus the one authenticated screen your users spend the most time on. Homepages get optimised because they get looked at; the money is usually elsewhere. Pick two URLs, record field LCP and field INP for both, and re-read them after every release rather than after every complaint.
Keep reading
Hosting in Sweden
Rates in SEK, which domain endings we can register there, and how the tax works out.
Web Hosting in Leeds
Leeds, and the same vitals conversation with a shorter round trip.
Web Hosting in Milan
Milan, where the identical budget is spent almost entirely on photography.
How to Test Your Website Speed
The walkthrough for taking these measurements yourself, with the panel open beside it.
Domain Names
Registering and pointing the .se, on the same account as the hosting.
WordPress Hosting
WordPress with LiteSpeed caching, staging copies and daily backups managed for you.
Changing hosts? Run through our checklist first.
A straightforward sequence for a switch your visitors never feel: which files move first, how to shift email across without losing a single message, the right moment to repoint DNS, and the two mistakes behind almost all the downtime we get asked to rescue.
Fix the tap, not just the paint.
A first byte from cache, current runtimes per site, and shell access to deploy and measure with.
View Domain Names plans