Designing a portfolio that loads fast

Portfolios are built around big, beautiful visuals, and big visuals are exactly what makes a page slow. The good news is that speed and good design are not opposites. Most of the weight on a typical portfolio comes from a handful of decisions, and each of them can be improved without changing how the page looks. A visitor decides within seconds whether to stay, so how quickly your work appears is part of the design.

Images are usually the problem

If a page feels slow, start with the images. A few rules cover most cases:

• Use modern formats like AVIF or WebP instead of large PNG or JPEG files.
• Export images at the size they are shown, and offer smaller versions for phones.
• Set width and height so the browser can reserve space before the image arrives.
• Lazy-load images below the fold, but load the main image at the top right away.

<img
	src="/images/hero.avif"
	width="1600"
	height="900"
	alt="Project overview"
	fetchpriority="high"
/>

In SvelteKit, the enhanced image plugin can generate the formats and sizes for you at build time, so you write one tag and get the optimized versions automatically.

Fonts: few files, swapped early

Fonts are the second most common source of delay. Every extra family and weight is another file the browser has to download before text looks right. Prefer a variable font, which packs many weights into one file, host it yourself, and tell the browser to show text immediately with a fallback while the font loads.

@font-face {
	font-family: "Source Sans 3";
	src: url("/fonts/source-sans-3.woff2") format("woff2");
	font-weight: 200 900;
	font-display: swap;
}

The woff2 format is much smaller than TTF, and font-display: swap means visitors can start reading right away. Two families, one for headings and one for body text, is enough for almost any design.

Layout shift is a design bug

You have seen it: you start reading, an image loads above the text, and everything jumps down. This is called layout shift, and it feels broken even when the page is fast. It is also easy to prevent. Give images and videos their dimensions, use the CSS aspect-ratio property for containers that hold media, and reserve space for anything that loads later, like embeds.

Google’s Core Web Vitals put numbers on this. They are a useful way to know whether a page is fast enough:

Ship less JavaScript

Most portfolio pages are mostly text and images, so they should not need much JavaScript. Pre-render pages at build time, hydrate only the parts that are interactive, and prefer CSS for hover effects and transitions. Before you add a large library for one small effect, check whether a few lines of CSS can do the same job.

The fastest code is the code you never send to the browser.

Measure, then decide

Guessing is the slowest way to optimize. Run Lighthouse or PageSpeed Insights on your pages, and test on a mid-range phone with a throttled connection, because your laptop on fast Wi-Fi hides most problems. A short checklist helps:

1. Check the largest image on each page and make sure it is optimized.
2. Count your font files and remove any weight you do not use.
3. Look for anything that moves while the page loads.
4. Check how much JavaScript the page downloads.
5. Test again on a phone after every change.

A fast portfolio does not have to be a plain one. Treat performance as part of the design brief from the start, and the work you show will look better too, because it appears the moment someone clicks.