Answer in brief
Site speed usually comes down to four things: images, web fonts, third-party scripts and render-blocking work. Here is what each layer does, how to measure a change without fooling yourself, and what a targeted fix costs.
The short answer: what actually decides how fast a page feels: Four layers decide page speed: images, web fonts,…
Site speed comes down to four things you can point at: images carrying more data than the layout needs, web fonts that hold back the text, third-party scripts added for analytics and chat, and render-blocking work — the styles and scripts a browser refuses to paint without.
Everything else — hosting, caching, protocol, database — matters too, but it belongs to a second layer of the conversation. Look first at what the page downloads and in what order, then at where it fetches those files from and how quickly the server answers.
For an owner deciding whether to hire someone, that is good news. The list is short and checkable. You do not need to understand how a browser works to ask four concrete questions and hear whether the answers are made of facts or of reassurance.
The sections below take each layer in turn: what happens, why a visitor notices it, what is normally done about it, and where a developer's responsibility ends. The technical points follow MDN's performance documentation and the W3C accessibility guidance linked at the end.
Speed as a feeling: what a visitor actually notices
Visitors do not count milliseconds. They register three moments: when something appears on screen at all, when the part they came for appears — a headline, a price, a product photo — and when the page starts answering their taps.
MDN treats this as perceived performance: how fast a page feels depends on what is shown and in which order, not only on total load time. A page can take longer overall and still feel quicker if it delivers meaning in useful instalments.
The practical consequence is that you optimize the path to the first useful screen rather than an average in a report. When the offer someone came for arrives last, speeding up everything around it changes a number without changing the experience.
The reverse holds as well. A page that paints text instantly but ignores a tap for a second feels broken. Responsiveness is part of speed, and it rests on keeping the main thread free rather than on how small your pictures are.
Images: weight, dimensions and format
Images tend to go wrong in one predictable way. A file goes into the layout at its original resolution and is displayed at a fraction of that size. The browser downloads all of it and then scales the result down: bytes paid for, pixels never seen.
Three habits fix that. Serve several sizes through srcset and sizes so a phone receives a phone-sized file. Use current formats such as WebP or AVIF where support allows. And export at the dimensions the container actually needs instead of relying on CSS to shrink things.
Lazy loading deserves its own sentence. The loading="lazy" attribute suits images below the fold, but not the one at the top of the page: defer that and you defer exactly the moment the visitor opened the page for.
Always set width and height, or an aspect ratio. That has nothing to do with file weight and everything to do with letting the browser reserve the space in advance, so the text does not jump when the picture finally arrives.
Fonts: why the text does not appear straight away
A browser does not discover a web font immediately. It has to fetch and parse the CSS first, and only then learns which font file to request. Text set in a linked font therefore tends to arrive later than the markup around it.
What happens during that gap is decided by font-display. Left at its default, a browser may keep the text invisible while it waits. The swap value tells it to show a system fallback right away and substitute later, so the reader gets the words before the styling.
Then there is volume. A site does not need a font file containing every alphabet; subsetting to the characters actually in use cuts genuine weight. A variable font can replace three or four static weights, and preloading one critical file removes the pause on a headline.
The cost of substitution is a shift at the moment the real font lands. You reduce it by choosing a fallback with similar metrics. That is a trade-off rather than a defect: the choice is between invisible text and text that moves slightly.
Third-party scripts: analytics, chat, pixels and widgets
Analytics, advertising pixels, a support chat, a map, a review widget, a tag manager. Each one adds a connection to somebody else's domain and code that runs on the same main thread as your own interface.
The difficulty is not that they exist but that you do not control them. Their size and behaviour are set by the vendor who ships them, and a change made on that side becomes your page's problem the same day.
So keep an inventory: what is loaded, who asked for it, and what it returns. Scripts with no owner inside the company usually survive from a campaign that ended a year ago, and removing them needs no long debate.
Whatever stays can be deferred. Load the chat and the map on a user action rather than on page load. A "Message us" button that pulls its widget only after a click costs less than a widget delivered to everyone who arrives.
Render-blocking work: CSS and synchronous JavaScript
Before painting anything, a browser has to build the style tree. Stylesheets in the head are therefore render-blocking: until they are fetched and parsed, the page stays blank even when the HTML has arrived in full.
Scripts behave similarly but more strictly. A plain script tag stops HTML parsing while it downloads and runs. The defer attribute moves execution to after parsing and preserves order; async runs each file as soon as it is ready, and the order is not guaranteed.
Some styles can leave the critical path through the media attribute: print styles or a narrow breakpoint need not hold up the first screen. The rest is a question of bulk, since one stylesheet for the whole site makes every page wait for rules it will never use.
This is the layer nobody can judge from outside and almost anyone can improve from inside. When a supplier's only answer about speed is "we'll compress the images", they have not looked at what sits between the request and the first pixel.
Layout shifts: the page that jumps under your thumb
A jumping page is not a cosmetic issue. Someone reaches for a button, a banner finishes loading above it, and the thumb lands somewhere else. That is an interface failure, and people remember it more clearly than a second of waiting.
The causes are predictable: images and embeds without declared dimensions, ads of variable height, a font swap with different metrics, and content injected above what is already visible. In every case the remedy is to reserve the space beforehand.
Here speed meets accessibility. The W3C quick reference for WCAG 2.2 includes Reflow (1.4.10), which asks that content stay usable when it is zoomed or shown on a narrow screen, and Pause, Stop, Hide (2.2.2) for moving content.
The shared principle is predictability. Reserving space for media and restraining automatic motion improve the feeling of speed and the accessibility of the page at once: an uncommon case where one edit answers two requirements.
What the server contributes: cache, compression and time to first byte
The server side owns time to first byte: how long the backend takes to assemble a response. A slow database query, a full render on every visit, no caching at all — each of them delays the moment the browser has anything to work with.
Delivery comes next. Compression for text responses, cache headers for static files with versioned names, distribution from a network closer to the visitor. These are configuration decisions rather than rewrites, and they usually land quickly.
Modern protocols remove part of the queue: HTTP/2 and HTTP/3 carry many requests over a single connection. That does not excuse downloading more than you need; it removes some of the waiting that the requests themselves used to create.
Do not confuse the layers. A fast server will not rescue a page that pulls in ten third-party scripts, and a carefully built frontend will not help if the response takes two seconds to appear. Both ends need looking at.
Phones and networks: where the honest test happens
A developer views the site over a wired connection, on a powerful machine, with everything already cached. The visitor arrives on a mid-range phone, over a mobile network, for the first time. Those are two different sites, and the second one counts.
The gap is not only bandwidth. A weaker processor takes longer to execute the same JavaScript, longer to parse the CSS and longer to decode images. What passes unnoticed on a laptop becomes a pause before the screen answers a tap.
So test on a real device with a cold cache: a private window, throttling switched on, a return visit hours later. Device emulation in developer tools is useful, but it models the conditions rather than reproducing them.
One more habit: look at the spread, not the average. If the page opens acceptably for many people and noticeably worse for some, the useful question is who those people are — which device class, which region, which section of the site.
How to measure without fooling yourself
There are two kinds of data. Lab data comes from a controlled run: repeatable, good for before-and-after comparison, but the conditions are the ones you chose. Field data is what actually happened to visitors, noisier and shaped by their own devices.
MDN documents the browser measurement interfaces — from navigation timing through PerformanceObserver — that let a page record when meaningful events occurred. That is what field data rests on: the measurement is taken where the user is sitting.
The working order is simple. Capture a baseline before any edits, on the same pages under the same conditions. Change one layer at a time. Measure again. Otherwise you end up with an improvement and no idea which change produced it.
Agree in advance on what counts as a result. "It feels faster" is not an acceptance criterion. A list of edits, named pages, a repeatable measurement procedure and a before-and-after comparison a third person can read — that is one.
What speed work costs at VITON13
When the problem is local — heavy images, forgotten scripts, a font with no fallback — the Site Fix Pack at $70 fits: up to 5 agreed fixes, a mobile and desktop check, a before/after list at handover, 1 round of revisions, delivered in 1-2 working days.
The Site Fix Pack deliberately excludes new pages, redesign and migrations. It is an instrument for targeted work. If the diagnosis shows the slowness is built into the structure of the site, the conversation moves to building it again rather than patching it.
That is Launch Site at $380: a responsive build, core CMS or data wiring and deployment setup, delivered in 3-5 working days with 2 rounds of revisions before launch. Content and translations are supplied by the client, since we do not write them.
When speed has to stay in order afterwards, Ongoing Dev Support runs at $290/mo: priority updates, a weekly release rhythm and technical maintenance. It works on a monthly cycle, volume is agreed at the start of each cycle, and 30 days notice stops it.
Limits: where speed stops being the answer
Speed removes an obstacle; it does not create demand. If the page fails to explain what you sell and why it is worth the money, instant loading only shows the unconvincing text sooner than before.
Some limits are external. An embedded player, a payment form, a partner's booking widget — you control when they load, not how much they weigh. Sometimes the honest answer is to change the vendor rather than to optimize their code.
Some limits are ours, and it is better to know them in advance. VITON13 does not write a client's content or translations, and does not build native mobile apps. If that is the task, it belongs to another supplier or another contract.
Finally, speed work is never a single event. Every campaign adds a script and every new page adds images. So agree not only on the fixes now, but on who watches the page afterwards and with what rhythm they do it.
Practical checklist
- List every third-party script on the site and name an owner for each one.
- Serve images in several sizes and in a current format.
- Declare width and height, or an aspect ratio, for every image and embed.
- Check that linked fonts use font-display: swap and are subset to the characters you need.
- Take off the critical path any style or script the first screen can do without.
- Measure before and after the edits, on the same pages, on a real phone, with a cold cache.
Questions and answers
What actually slows a website down?
Usually it is four layers: images heavier than the layout needs, web fonts delaying the text, third-party scripts occupying the main thread, and styles or synchronous scripts blocking the render. The server and the protocol form a second layer of the conversation.
What does a targeted speed fix cost?
The Site Fix Pack is $70: up to 5 agreed fixes, a mobile and desktop check, and a before/after list at handover. It is delivered in 1-2 working days and includes 1 round of revisions. New pages, redesign and migrations are not part of this package.
What if the site is slow because of how it is built?
Then the answer is a rebuild. Launch Site is $380: a responsive build, core CMS or data wiring, and deployment setup. It is delivered in 3-5 working days with 2 rounds of revisions before launch. Content and translations are supplied by the client.
Do we need support once the fixes are done?
Ongoing Dev Support is $290/mo: priority updates, a weekly release rhythm and technical maintenance. It runs on a monthly cycle, the volume is agreed at the start of each cycle, and 30 days notice stops it. A new build or a redesign is scoped separately.
What if we need new functionality rather than a fix?
Product Build is $880: feature delivery, state and route logic, testing and hardening. It is delivered in 2-3 weeks with 2 rounds of revisions per delivered feature. Native mobile apps and payment licensing are not included in the package.