A one-second delay in page load time reduces conversions by 7%. A three-second load time loses over half your visitors. Speed isn’t a nice-to-have — it’s the foundation everything else sits on.
But most advice about web performance focuses on the wrong things. Here’s what actually moves the needle.
The biggest bottleneck: JavaScript
The single largest factor in how fast a website feels is how much JavaScript it ships to the browser. Every kilobyte of JavaScript must be downloaded, parsed, compiled, and executed before the page becomes interactive.
A typical React single-page application ships 200-500KB of JavaScript — often more. That’s before your actual application code. The framework alone takes over a second to become interactive on a mid-range mobile device.
Compare that to a server-rendered page with minimal JavaScript: the HTML arrives ready to use. The browser renders it immediately. Interactive elements can work with a few kilobytes of JavaScript instead of hundreds.
This is why we build with Phoenix LiveView. The server renders HTML and sends it to the browser. Interactivity happens over a WebSocket connection — the browser receives tiny HTML diffs instead of running a full JavaScript application. The result is a site that feels instant.
Images: the low-hanging fruit
Images are typically the heaviest assets on any page. A few unoptimised photos can easily add megabytes to your page weight. The fixes are straightforward:
Use modern formats. WebP is 25-35% smaller than JPEG at equivalent quality. AVIF is even smaller. Both are supported by all modern browsers.
Serve the right size. A 4000px-wide image displayed in a 400px container wastes 90% of the data transferred. Use responsive images with srcset to serve appropriately sized versions.
Lazy load below-the-fold images. Images that aren’t visible when the page first loads should only be fetched when the user scrolls near them. A single loading="lazy" attribute handles this natively.
Set explicit dimensions. Always specify width and height on image elements. This prevents layout shift (CLS) — that jarring movement when images load and push content around.
Fonts: the hidden cost
Custom fonts add character to a site, but they come at a cost. Each font weight is typically 20-50KB. Load four weights of two font families and you’re looking at 200-400KB of font data.
Optimise fonts by:
- Subsetting — remove characters you’ll never use (Cyrillic, Greek, etc.)
-
Using
font-display: swap— shows text in a fallback font immediately, then swaps when the custom font loads - Limiting font weights — do you really need thin, light, regular, medium, semibold, and bold? Two or three weights usually suffice
- Preloading critical fonts — tell the browser to fetch your main font early
Server response time
Before anything else happens, the browser has to receive the first byte of the response from your server. This is called Time to First Byte (TTFB), and it’s influenced by:
- Server location — a server in Europe responds faster to European visitors than a server in the US
- Application performance — how quickly your server generates the response
- Caching — serving cached responses instead of generating them from scratch every time
Modern frameworks like Phoenix handle thousands of requests per second on modest hardware. Combined with a CDN for static assets and server-side caching for dynamic content, TTFB under 100ms is achievable for most sites.
What doesn’t matter as much as you think
Minification. Yes, minify your CSS and JavaScript in production. But the savings are typically 10-20%. If your unminified JavaScript is 500KB, minification gives you 400KB. You still have a performance problem.
HTTP/2 and HTTP/3. These protocols improve loading of many small files in parallel. They help, but they don’t fix a fundamentally heavy page.
CDN for HTML. CDNs are excellent for static assets (images, CSS, JS). For dynamic HTML, the benefit is smaller unless you’re serving a global audience.
How to measure
Use these tools to understand your site’s actual performance:
- Google PageSpeed Insights — the standard benchmark, measures real-world performance data
- WebPageTest — detailed waterfall charts showing exactly what loads when
- Chrome DevTools Network tab — see every request your page makes
- Core Web Vitals in Google Search Console — how real users experience your site
Focus on three numbers: Largest Contentful Paint (LCP) under 2.5 seconds, First Input Delay (FID) under 100ms, and Cumulative Layout Shift (CLS) under 0.1.
Our approach at Linjerum
Performance is a design decision, not an afterthought. We build with Phoenix LiveView, which means minimal JavaScript, server-rendered HTML, and real-time updates over WebSocket. Our sites typically achieve PageSpeed scores above 95 on both mobile and desktop.
Every image is optimised, every font is subsetted, every byte is justified. Because speed isn’t just a technical metric — it’s the first thing your visitors feel.
Questions about your site’s performance? Reach out at support@linjerum.com.