A fast website does not just load quickly. It changes how people behave on it. When a page responds instantly, visitors browse deeper, trust more readily and leave less. When it stutters, no amount of good design gets that trust back.
That is why performance is not something we bolt on at the end of a build. It is part of the creative foundation, decided at the same table as the typography, because almost every decision that makes a page slow is made by somebody who is not thinking about speed at the time.
Speed is designed in from the start
Most slow sites were not built slowly on purpose. Speed just was not anyone’s job. We make it the design’s job. Images are sized for the box they sit in and loaded lazily below the fold. Fonts load with font-display: swap so text never waits on a download. Layouts reserve their space up front, so nothing shifts under the reader’s cursor. Animation runs on transform and opacity only, the two properties a browser can move without redoing layout.
None of this is exotic. It is a set of habits, applied on every section, every time, which is exactly why it works. The sites that end up slow are rarely the victims of one catastrophic decision. They are the sum of forty small ones nobody was measuring.
The three numbers that matter
Google publishes thresholds for three Core Web Vitals, and they are a good design brief even setting search aside, because each one describes a different way a page can feel wrong.
Largest Contentful Paint (LCP) measures how long until the main thing on screen has rendered. The target is 2.5 seconds or less at the 75th percentile of real visits. It is usually dominated by one element, most often the hero image or the headline, and it is usually fixed by making that one element cheaper to fetch rather than by optimising the whole page.
Interaction to Next Paint (INP) measures how long the page takes to visibly respond after someone taps or clicks. The target is 200 milliseconds or less. This is a JavaScript problem almost every time: the main thread is busy doing something the visitor did not ask for, so their tap waits in a queue.
Cumulative Layout Shift (CLS) measures how much the content jumps around while it loads. The target is 0.1 or less. It is caused by anything that arrives late and takes up space: images without dimensions, ads, embeds, a banner injected at the top, a web font whose letterforms are wider than the fallback.
Two things about those numbers are worth saying plainly. They are measured on real visitors rather than a lab test, so a perfect score on an office desktop proves very little. And they are a floor rather than a goal. A site that merely passes is not fast, it is acceptable.
Images are usually most of the story
On a typical business website, images account for more transferred bytes than everything else combined, which makes them the first place to look and the easiest place to win.
The rules are boring and they work. Serve modern formats such as WebP or AVIF. Export at the size the layout actually uses rather than the size the camera produced, and provide a srcset so a phone is not handed a 2,000 pixel file for a 400 pixel box. Always set width and height attributes, so the browser can reserve the space before the file arrives. Load everything below the fold lazily, and load the hero image eagerly, because lazy-loading the one image that defines LCP is a common and expensive own goal.
Decorative background images deserve a harder question than they usually get: does this earn its weight on a phone, on a mobile connection, when the reader came for the pricing?
Fonts, and the two ways they cost you
Web fonts are worth having and they are not free. They cost you twice: once in transfer, and once in layout stability when the fallback face is a different width from the real one.
Keep the number of families and weights small, since every extra weight is another file. Self-host or preconnect to the font host so the browser is not discovering a third-party connection halfway through the render. Use font-display: swap so text is readable immediately. Then pick a fallback stack whose metrics are close to the web font, which is the difference between a barely noticeable reflow and a visible jolt.
JavaScript is the expensive part
A kilobyte of JavaScript costs far more than a kilobyte of image, because it has to be parsed, compiled and executed on a device that may be five years old. This is where INP is won or lost.
Three questions cut most of it. Does this need to be JavaScript at all, when native HTML now handles accordions, dialog boxes, lazy loading and form validation? Does it need to run before the page is usable, or can it wait until the component scrolls into view? And is it ours, or is it a third-party script somebody added for a trial that finished two years ago?
Tag managers, chat widgets, heatmap recorders, review badges, social embeds and consent banners each arrive with a reasonable justification and a real cost. The honest approach is to keep a list of every third-party script on the site, who asked for it, and what would break if it went. Most sites cannot answer the second question for at least half of them.
Built to scale, not to be rebuilt
A high-performance site is also one that still performs in a year. We build with modular components and global style rules, so new pages are assembled from proven parts instead of invented from scratch. Adding a service, a case study or a campaign page does not mean calling a developer, and it does not mean a new page arrives with its own private stylesheet and three new scripts.
That is the part most performance advice misses. The initial launch is a snapshot. What decides whether a site is fast in eighteen months is whether the system makes the fast path the easy path for whoever edits it next. It is the same reason we approach web design in Dublin as engineering rather than decoration.
Found by design
Performance and discoverability are the same discipline wearing different hats. Semantic HTML, a logical heading order, real links, and per-page metadata tell search engines exactly what each page is. Accessible markup that works for screen readers and keyboards tends to be precisely the markup crawlers understand best.
Accessibility compliance is not a checkbox for us. It is a performance lever. A page that is light enough to render fast, structured well enough to navigate by keyboard and marked up clearly enough for assistive technology is the same page, and it is the page that ranks.
How to hold the line after launch
Measure real visits rather than lab runs, because the lab is a mid-range phone in perfect conditions and your audience is not. Set a budget in numbers everyone can check, such as a maximum transfer size for a page and a maximum number of third-party scripts, and treat a breach as a bug rather than a discussion. Re-test after every content campaign, since the most common cause of a slow page is not the build but the 4 MB image somebody uploaded straight from a camera.
And test on a real mid-range phone on a real mobile connection at least once. It is a faster source of truth than any report.
