A high-performance website keeps people long enough to read the page, so on our web design projects in Dublin we set a performance budget at the design stage, alongside the typography. Most decisions that slow a page down are made by someone thinking about something else: a background video, a chat widget, a photo uploaded at full size. On ESMA, the home page paints in 0.97 seconds in a desktop test (19 September 2026, ESMA case study).
How we design for speed
Images are sized for the box they sit in and lazy-loaded below the fold. Layouts reserve their space up front, so nothing shifts under the reader. Animation uses transform and opacity, which a browser can animate without recalculating the layout.
The three Core Web Vitals
Google publishes thresholds for three Core Web Vitals, measured at the 75th percentile of real visits (web.dev). Each describes a different way a page can feel wrong.
Largest Contentful Paint (LCP) measures how long the main content takes to render. The target is 2.5 seconds or less. It is usually set by one element, the hero image or the headline, and fixed by making that element cheaper to fetch.
Interaction to Next Paint (INP) measures how long the page takes to respond visibly after a tap or click. The target is 200 milliseconds or less. The cause is almost always JavaScript: the main thread is busy with work the visitor did not ask for, so their tap waits in a queue.
Cumulative Layout Shift (CLS) measures how much content jumps while the page loads. The target is 0.1 or less. Anything that arrives late and takes up space causes it: images without dimensions, ads, embeds, an injected banner, a web font wider than its fallback.
The numbers come from visits by your own users, so a perfect lab score on an office desktop proves little.
Image weight and formats
On a typical business website, images are the largest share of the bytes transferred, so they are the first place to look.
Serve WebP or AVIF. Export at the size the layout uses and provide a srcset, so a phone is not sent a 2,000 pixel file for a 400 pixel box. Always set width and height attributes, so the browser reserves the space before the file arrives. Lazy-load everything below the fold and load the hero image eagerly: lazy-loading the image that defines LCP is a common and expensive mistake.
Ask of every decorative background image whether it is worth its weight on a phone on a mobile connection.
Video deserves the same scrutiny. Show a poster image and load the player only when someone presses play, so a brand film or product video costs the page nothing until it is wanted. Short motion graphics loops are far lighter exported as compressed video than as animated GIFs.
Web fonts
Web fonts cost bytes, and they cost layout stability when the fallback face is a different width. Keep families and weights few, since each weight is another file. Self-host the fonts or preconnect to the font host. Use font-display: swap so text is readable at once, and choose a fallback stack with metrics close to the web font so the swap is barely visible.
JavaScript and third-party scripts
A kilobyte of JavaScript costs more than a kilobyte of image, because it has to be parsed, compiled and run, often on a phone several years old.
Ask three things of every script. Does it need to be JavaScript, when HTML now handles accordions, dialogs, 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 a third-party script added for a trial that ended two years ago?
Tag managers, chat widgets, heatmap recorders, review badges, social embeds and consent banners each arrive with a reason and a cost. Keep a list of every third-party script on the site, who asked for it, and what would break without it.
Keeping a site fast after launch
We build with modular components and global style rules, so a new service page, case study or campaign page is assembled from tested parts and does not arrive with its own stylesheet and three new scripts. What decides the speed eighteen months after launch is whether the system makes the fast path the easy one for whoever edits the site next.
Measure field data from real visits alongside lab runs. Set a budget in numbers everyone can check, such as a maximum page weight and a maximum number of third-party scripts, and treat a breach as a bug. Re-test after every content campaign, since a 4 MB photo uploaded straight from a camera is a frequent cause of a slow page. And test at least once on a mid-range phone on a mobile connection.
Speed, accessibility and search
Semantic HTML, a logical heading order and plain links help search engines, screen readers and load times at once. The same light, server-rendered markup is what AI answer engines read and quote, which is the basis of our AI-ready website development work.
