Speed is usually treated as an engineering task, which is why it tends to be dealt with too late. By the time anyone measures how fast a page is, many of the decisions that made it slow were made months earlier, in a design file, by someone who was never told they were making them.
Google's free PageSpeed Insights (opens in a new tab) will load any public page and list what slows it down. A large share of what it reports is not a coding mistake. It is a design decision, carried through to the finished page.
The decisions that set the limit
Three things, chosen early, decide most of what a page can ever weigh.
The big image at the top
A photograph across the full width of the top of a page is the largest thing on it, and usually the thing the browser waits for before it counts the page as loaded. Whether that image is a photograph, an illustration or a flat colour was a design decision, and it affects the load time more than anything an engineer will do afterwards.
The typefaces
Every additional typeface, and every extra boldness of it, is a file that has to arrive before text can be drawn in the right shape. Two families at three weights each is a decision that costs real time on a slow connection. Nobody frames it that way in the review, where it is a decision about tone.
Whether the first screen depends on data
A layout where the top of the page is a personal greeting cannot appear until the site has looked up who you are. A layout where the top is the same for everyone, with the personal part further down, can appear at once. That is a choice about the layout, made in a design file, and it decides whether the page can be prepared in advance at all.
These do not get raised as performance questions during design, because performance is not on the agenda until later. That is the real problem, and it is a version of the same gap I have written about in design handoff: the design arrives complete, and the limits that should have shaped it show up afterwards as bug reports.
A jumping page is a design bug
Layout shift is the name for a page that moves while it loads: you go to tap something and it jumps away. Of everything in a speed report, it is the one most clearly not an engineering problem. A page that moves as it loads may not be slow, but it is frustrating to use, and it is often part of what people mean when they say a site feels cheap.
The cause is nearly always the same: something arrived whose size was not reserved. An image without a known size. Text first drawn in a stand-in typeface and then redrawn, wider, in the real one. A banner pushed in above the content. An advert. A part of the page that shows nothing and then suddenly shows something.
Every one of those is fixable by knowing the size in advance, and knowing the size in advance is something design decides. If a card can be 180 or 260 pixels tall depending on the length of a title, that variation was specified, and it will cost something when the page loads.
A common version of this is images hosted on another site. Copy them onto your own site in advance and measure them, so the page has the real dimensions and can reserve the exact space before the file arrives. This is a routine fix rather than a clever one, and without it the grid rearranges itself while someone is looking at it.
Reserve space for anything that can be absent
A section that is empty and takes no room, and then fills and takes 200 pixels, is the same bug as an image without a size. If a section can be empty, decide how tall it is when empty, and decide it in the design rather than discovering it on the live site.
Skeletons, and when they mislead
Skeleton screens, the grey blocks in the shape of the content that you see while a page loads, have become the default answer to "what do we show while loading", and they are often the wrong one.
A skeleton is a promise about shape. It says: content is coming, it will look roughly like this, and it will land here. When that promise is accurate it works well, because the eye settles into the layout before the content arrives and nothing jumps when it does.
When the promise is wrong, it is worse than a spinning wheel. Three skeleton rows followed by seven real rows makes the page jump at exactly the moment the content arrives. Skeleton rows followed by "nothing here yet" is misleading: the page suggested that content was coming and then showed that there is none.
Two rules have kept this accurate for me.
Only use a skeleton when you know the shape
If the number of items is unknown, the shape is unknown, and a skeleton can only guess at it.
Do not use a skeleton for anything fast
My rule of thumb: when content arrives within about 300 milliseconds, a skeleton is a brief flash that looks like a glitch, and showing nothing is calmer than showing something twice.
So a spinning wheel is not a lazy choice. For a wait of unknown length and unknown shape, it is the accurate one.
How fast a page feels is what people notice
Measured speed and felt speed often differ, and where they disagree, the feeling is what people report.
A page that shows its structure in 300 milliseconds and fills in the content over the next 400 feels faster than a page that shows nothing for 500 and then appears complete, even though the second finished first. Something happened, in response to something they did, quickly. That is what makes it feel fast.
Which leads to the most useful design decision on the list: make the static part of the page independent of the slow part. The header, the menu, the layout, the headings and anything that does not have to be fetched from elsewhere should be able to appear immediately. If they have to wait for the same thing as the slow part, the whole page waits on the slowest thing in it, and that is a layout decision, not a technical one.
The same logic applies to interaction. A button that responds the instant you press it and checks with the server a moment later feels immediate. A button that waits for the server before showing it was pressed can feel broken even when the delay is short, and on a mobile connection it often is not short. Whether an action can respond before it is confirmed is a design question about what happens when it fails, and it has to be answered in the design, because the screen for when it fails is a screen somebody has to draw.
Images are most of the weight, and most of the fix
If a page is heavy, meaning large in file size, it is usually because of its images rather than its code.
The parts that belong to design rather than engineering:
Whether the image needs to be there
The most effective way to make an image smaller is to remove it, and a decorative photograph that carries no information is the easiest thing on the page to remove.
How large it actually appears
An image shown at 400 pixels wide does not need a 2000 pixel file. Many live sites send images far larger than the space they appear in, nearly always because nobody specified the size the image is shown at.
Whether it is visible without scrolling
Everything further down can load later, when someone scrolls to it, and cost nothing up front. Everything above must arrive first. That boundary is drawn in the layout.
Photograph or illustration
A flat illustration compresses to a fraction of the size of a photograph. That is a stylistic choice with a weight attached, and the weight is rarely part of the conversation.
Making it visible early enough to matter
What changes the outcome is not a particular tool. It is putting the number somewhere a designer sees it while there is still time to act on it.
A limit stated in the terms of the work helps more than a score. Google publishes target values for its Core Web Vitals (opens in a new tab), its three measures of loading, responsiveness and layout shift: the largest image or block of text on the first screen should appear within 2.5 seconds, for example. A team can turn that into limits a designer can design against: the main content appears on an ordinary phone within that time, the images you see without scrolling stay under a size the team agrees on, nothing moves once the page has appeared. A score out of a hundred, delivered after the design was handed over, is a grade on work already finished.
And the measurement has to happen in the conditions people actually use. A design reviewed on a fast laptop over office wifi has been reviewed under conditions most users do not share. Browsers can simulate a slow mobile connection (Chrome's developer tools have a setting for it). Try it once on a page you just approved, and the things to change become obvious.
The part that is hard to accept
Performance work is mostly removing things, and removing things is not what design reviews reward. A page with one typeface, no big photograph at the top and no entrance animation loads quickly and can look as though nobody tried.
I do not think the answer is to strip everything back. It is that the cost should be visible at the moment of choosing, so that a second typeface or a full-width photograph is something you decided to spend on, rather than something that showed up in a report as somebody else's problem. Every performance decision worth making is a trade-off, and it is only a real trade-off if you can see the cost when you make it.