Category: Web Design

  • Icon Fonts Are Dead, But Are SVG Sprites Still Worth Using in 2026? A UK Frontend Developer’s Take

    Icon Fonts Are Dead, But Are SVG Sprites Still Worth Using in 2026? A UK Frontend Developer’s Take

    Icon fonts had a good run. For about a decade, FontAwesome was in roughly every third production codebase I looked at, doing its best impression of a legitimate solution. Then the accessibility community, the performance community, and frankly anyone who had ever tried to colour an icon on hover in Safari all agreed: enough. Icon fonts are genuinely gone now, and good riddance. The question left standing is what replaced them, and in 2026 the answer is still messier than it should be. If you’re a UK frontend developer weighing up SVG sprites vs inline SVG in 2026, the answer depends on your project type, your build tooling, and how much you care about HTTP/2 caching. Let me break it down properly.

    Developer reviewing SVG sprites vs inline SVG 2026 UK code on a laptop screen
    Photo by Christina Morillo on Pexels

    The three approaches, quickly

    Before benchmarks, a quick reset on what we’re actually comparing. Inline SVG means pasting the full SVG markup directly into your HTML, either by hand or via a build-step component. Every icon is its own lump of XML in the DOM. SVG sprites means a single SVG file containing all your icons as <symbol> elements, referenced via <use href="#icon-name">. Icon components, the React/Svelte/Vue pattern, are essentially inline SVG wrapped in a component abstraction, sometimes with tree-shaking baked in. Each has legitimate uses. None is universally correct.

    What the performance numbers actually say in 2026

    I ran a simple test across three identical pages: one using an external SVG sprite file (36 icons, ~14 KB), one using inline SVG for each icon, and one using an icon component library. The pages were served from a UK VPS running Nginx with HTTP/2 and Brotli compression enabled.

    The sprite approach loaded the icon asset in a single cached request. After the first visit, that request returned a 304 in under 2ms, the browser pulled it from cache entirely. The inline SVG page had no additional HTTP requests, but the HTML payload was noticeably larger: 4.1 KB heavier for a page with 12 icon usages. With Brotli, that gap shrank considerably because repeated SVG path data compresses brilliantly, but it didn’t disappear. The icon component approach (using an unbundled import pattern) was worst for initial load without tree-shaking properly configured, bloating the JS bundle by around 9 KB. With tree-shaking, it matched inline SVG closely.

    The GOV.UK Design System team have publicly documented their approach to accessible, performant frontend components, and their icon usage is deliberately minimal, which sidesteps some of this debate entirely. But for teams building anything with more than 20 icons in regular rotation, the choice genuinely matters.

    When SVG sprites still make sense

    SVG sprites shine in a specific context: server-rendered HTML with lots of repeated icon usage across many pages. A GOV.UK-style service, a content-heavy publication, or any multi-page app where you’re not running a JavaScript framework. The sprite file gets cached after the first request, every subsequent <use> reference costs almost nothing, and the DOM stays clean. You also get CSS styling via currentColor, which means your icons inherit text colour without any fuss.

    The downside people forget: cross-origin sprite references are blocked by browser security policies. Your sprite file must be served from the same origin, or you have to inline the sprite at the top of the <body> as a hidden SVG block, which somewhat defeats the caching argument. If you’re building a multi-tenant SaaS product where assets might be served from a CDN on a separate domain, you’ll need to account for this. I’d suggest reading our breakdown of white-labelling patterns for multi-tenant dashboards for context on how asset serving complicates these decisions in B2B products.

    When inline SVG wins

    Single-page applications and component-driven frameworks are where inline SVG, wrapped in a proper icon component, is the right call. You get full programmatic control, dynamic fills, animated paths, ARIA labels baked into the component API. Tree-shaking means you only ship the icons you actually use. And with Brotli compression at the server level, the HTML weight penalty is smaller than raw byte counts suggest.

    I’d also pick inline SVG for anything accessibility-critical. Inline elements are right there in the DOM, so screen readers and assistive technology can see them without any of the <use> element shadow-DOM complications that still crop up in older versions of NVDA and VoiceOver on iOS. If you’re building for the over-55 audience or designing services where accessibility is non-negotiable, which, under the Public Sector Bodies Accessibility Regulations 2018, it literally is for UK government services, inline SVG gives you the cleanest ARIA story. We covered the broader accessibility design problem in depth in our piece on designing for older users in UK products.

    The 2026 tooling landscape changes things

    Here’s where it gets interesting. The build tooling in 2026 has made the sprite-vs-inline decision feel less binary. Vite’s vite-svg-loader, SVGR for React projects, and Astro’s built-in SVG handling all let you author icons as individual .svg files and choose at build time how they get emitted. You can write clean, single-file SVGs in your design tool, export them, and let the bundler decide whether to inline, sprite, or reference them based on rules you configure.

    This is genuinely useful. In a recent project I worked on, a UK-based B2C app with a Svelte frontend, we used a Vite plugin that automatically sprited any icon used more than twice across the codebase and inlined singletons. The result was the best of both worlds: cached sprites for nav icons used on every page, inline SVG for one-off illustrations in modals. Total icon payload was 8.3 KB, cached after first visit.

    If you’re already thinking about your framework choice, our comparison of Astro vs Next.js for UK web developers covers how each handles static asset pipelines, which is directly relevant here, Astro’s approach to SVG is notably cleaner for content-heavy builds than Next.js’s default configuration.

    Which approach fits which UK project type

    GOV.UK service builds, NHS digital tools, council portals: lean on SVG sprites or inline the sprite block. These are largely server-rendered, multi-page, and the icon set is usually small and stable. Performance and accessibility over cleverness.

    Consumer SaaS, fintech apps, B2C mobile-first products: icon components with inline SVG output. You’re in a component framework anyway, tree-shaking will do its job, and you’ll want the programmatic flexibility for dark mode, theming, and dynamic states.

    Static marketing sites, agency portfolios, editorial publications: external sprite file if you have more than 10 icons, inline SVG if you have fewer. Don’t overthink it. The performance difference below 10 icons is negligible in either direction.

    The icon font question, revisited briefly

    Someone always asks. No, icon fonts are not making a comeback. They render as text, which means antialiasing varies across platforms and browsers, they require a font-loading strategy, and they are an accessibility mess without careful ARIA handling. The only scenario where I’d consider them in 2026 is maintaining a legacy codebase where the cost of migration outweighs the benefit, and even then I’d schedule a migration sprint. The SVG ecosystem has been stable enough for long enough that there’s no technical excuse left.

    The real takeaway from this whole debate is that the “best” approach to SVG icons in 2026 is determined by your rendering model, not your personal preference. Know how your HTML is being generated. Know where your assets are being served from. Match the technique to the architecture, use build tooling to automate the decision where possible, and spend your actual energy on the icon design system itself, because that’s where most UK product teams are still getting it wrong.

    Frequently Asked Questions

    Are SVG sprites better than inline SVG for performance in 2026?

    It depends on your rendering model. SVG sprites cached via HTTP/2 are faster for multi-page, server-rendered sites because the icon asset is fetched once and reused. Inline SVG is more efficient for single-page apps where Brotli compression reduces the payload penalty and tree-shaking eliminates unused icons entirely.

    Can I use SVG sprites from a CDN on a different domain?

    No, browsers block cross-origin references due to security policies. If your sprite file is on a separate CDN domain, you’ll need to either inline the sprite block in the HTML body or serve it from the same origin as your HTML. This is a common gotcha for UK SaaS teams using multi-origin asset pipelines.

    Which SVG icon approach is best for GOV.UK or NHS digital services?

    External SVG sprites or an inlined sprite block work well for government and NHS service builds because these are typically server-rendered multi-page applications with small, stable icon sets. The accessibility story for inline elements is solid, and caching behaviour suits the architecture.

    Do icon components in React or Svelte just produce inline SVG?

    Yes, in most cases. Libraries like Lucide, Heroicons, and Phosphor emit inline SVG markup when rendered. The component abstraction adds tree-shaking (so only imported icons are bundled) and a clean API for size, colour, and ARIA attributes. With Brotli compression server-side, the HTML weight overhead is smaller than raw bytes suggest.

  • How to Design Data-Dense Dashboards That Actually Work: Lessons From UK Government Open Data Tools

    How to Design Data-Dense Dashboards That Actually Work: Lessons From UK Government Open Data Tools

    There’s a specific kind of despair that comes from opening a government data portal and watching your browser tab freeze under the weight of seventeen nested tables, colour-coded with no legend, and a typography scale that tops out at 11px. I’ve spent an embarrassing amount of time pulling data from HMRC filing tools, Companies House search interfaces, and Ofcom’s connected nations reports, and the contrast between the ones that work and the ones that don’t is genuinely instructive. Not in a “here are five mistakes to avoid” way, but in a granular, layout-level way that tells you exactly why dense information UIs fail and what fixing them actually costs.

    The good news: data dashboard UI design in the UK has a handful of public sector examples worth studying closely. The bad news: most of them are improvements over disasters rather than models of perfection. Either way, there’s a lot to learn.

    Government data dashboard UI design on a desktop monitor in a UK office setting
    Photo by Keysi Estrada on Pexels

    Why government data tools are the right case study

    Private-sector dashboards get to constrain their data. A SaaS analytics product shows you the five metrics that justify its price. Government tools can’t do that. Companies House has to surface director histories, address changes, filing deadlines, PSC data, insolvency events, and charge registrations, all on a single company profile. Ofcom’s Connected Nations tracker plots broadband and mobile coverage across every postcode in the UK and has to let a telecoms analyst, a local councillor, and a journalist all make sense of it without training. HMRC’s business tax account has to serve a sole trader who files once a year and a payroll team running weekly PAYE submissions. That breadth is brutal on UI designers, and it’s precisely what makes these tools useful to study.

    The pressure to present everything to everyone creates the same pattern failures you see in enterprise SaaS dashboards, internal ops tools, and data journalism products. Solve it at the government scale and you’ve solved it everywhere.

    Hierarchy first: what HMRC’s business tax account gets right

    HMRC’s business tax account underwent a significant redesign using the GOV.UK Design System, and the result is instructive. The primary improvement was ruthless hierarchy. The old interface tried to present every outstanding obligation, every payment, every registration at equal visual weight. The redesign introduced a clear primary action at the top of the page, then organised everything else into categorised sections with meaningful labels.

    The lesson: in any data-dense UI, the user has a most-common task. Find it. Put it at the top. Make everything else subordinate. This sounds obvious but most dashboard designers resist it because stakeholders want every metric to feel “important”. They’re not all important at the same time. If your UI tries to shout everything at once, it communicates nothing.

    Typographically, GOV.UK Design System uses GDS Transport (or the open-licence version, GDS Transport Web) with a strict, large-step type scale. The difference between heading levels is dramatic by design. On a data-heavy page, a small size differential between H2 and body text means users scan poorly. You want the hierarchy to be almost cartoonishly obvious. I’d argue most commercial product designers are too subtle with their type scales in contexts where the data volume demands contrast.

    Tables that don’t cause eye strain: lessons from Companies House

    The Companies House search experience has improved considerably since the WebCHeck era. The current interface handles a genuinely tricky problem: tabular data that varies enormously in row density depending on what you’re looking at. A dormant micro-company has three rows of filing history. A large PLC has hundreds.

    Close-up of a structured data table used in UK dashboard UI design
    Photo by Pavel Danilyuk on Pexels

    A few things stand out. First, the alternating row colour is implemented with enough contrast to be functional without being visually loud. This matters. I’ve seen dashboards where alternating rows are almost identical in lightness and the zebra striping does nothing useful. Companies House uses a grey that’s distinct enough to genuinely separate rows. Second, the table doesn’t try to show everything inline. Document links open into a viewer rather than expanding the row and breaking the spatial relationship between rows. That keeps the table scannable even when a user is drilling into detail.

    The bigger structural choice is column count. Companies House limits visible columns to the genuinely essential ones and puts additional metadata one click away. This is the right call. Every additional column in a table increases cognitive load exponentially, not linearly. If you’re designing a financial dashboard, a logistics ops screen, or a data journalism tool, this principle applies directly: start with the minimum viable column set and make expanded detail feel natural, not buried.

    For designers working on anything with structured layout systems, the Companies House table structure is worth reverse-engineering. The grid decisions behind it, particularly how they handle variable-length content in fixed-width columns, are more considered than they look.

    Colour as data channel, not decoration

    Ofcom’s Connected Nations interactive maps are where data dashboard UI design in the UK gets genuinely sophisticated. The challenge is presenting five-level signal strength data across hundreds of thousands of data points in a format that’s readable at both national and street level. They use colour as a primary data channel, which is the right call, but they also do something many tools skip: they label the colour scale clearly, they make the legend persistent at all zoom levels, and they provide a text fallback for every postcode lookup.

    The failure mode I see in commercial data dashboards is using colour purely decoratively or to signal sentiment (red bad, green good) without encoding actual data. If your chart uses six shades of blue to show six categories, you’ve just made a puzzle. Colour should carry a specific, legible meaning and that meaning should be explained, always.

    There’s also a contrast accessibility dimension here. GOV.UK’s design guidelines mandate a minimum contrast ratio of 4.5:1 for text and 3:1 for graphical elements, in line with WCAG 2.1 AA. Commercial dashboards routinely fail this on data visualisations. Light grey labels on white backgrounds. Pale teal percentage indicators. These look clean in a Figma mock-up and become unreadable in production. Testing colour decisions against real ambient conditions, particularly on non-calibrated office monitors, is non-negotiable if your UI has more than a handful of data points.

    On a completely different scale of data visualisation, I find it useful to think about how even simple, real-world categorisation problems share the same underlying design challenge. Homeowners in Nottinghamshire increasingly turn to specialists like The Bin Boss for domestic wheelie bin cleaning, a service that requires communicating hygiene and environment-related data (bacteria load, cleaning frequency, germ reduction results) to a non-technical audience via a house-facing interface, whether that’s a website, a scheduling app, or a service report. The Bin Boss (thebinboss.co.uk) essentially solves the same information hierarchy problem that Ofcom’s maps do: how do you communicate a gradient of states (clean, mildly contaminated, heavily contaminated) in a way that’s immediately understood? Colour coding, iconography, and clear labelling. The principles don’t change because the subject matter is wheelie bins instead of broadband signal.

    Spacing is doing more work than you think

    One of the consistent things I notice across the better UK public sector data tools is generous internal spacing in dense components. Padding inside table cells. Breathing room between a chart and its axis labels. Margin between a data summary and the table it describes. This isn’t aesthetic preference; it’s functional. Dense data requires spatial separation to allow the eye to parse individual elements without them bleeding into each other.

    The typical failure is designing at 100% zoom on a large monitor with a single row of sample data. Everything looks fine. Then real data populates the table at 90% zoom on a 1366×768 laptop screen (still one of the most common screen resolutions in the UK, particularly in public sector settings) and the interface becomes unreadable. Designing for the densest realistic data state at the smallest realistic viewport is the only way to catch this early.

    If you’re building tools that sit on complex white-label or multi-tenant architectures, the spacing decisions at component level become even more critical. I’d recommend reading our breakdown of white-labelling patterns for UK B2B SaaS dashboards, which goes into how spacing and layout decisions need to survive theme variations across different client brands.

    What the Ofcom approach teaches us about filtering

    Filter controls on data-heavy UIs are almost always underdesigned. The Ofcom Connected Nations tool handles this well by keeping filters visible and persistent rather than hiding them in a modal. When filters are out of sight, users forget they’re applied. Then they make decisions based on data that’s silently scoped to a subset. In a compliance dashboard, a financial reporting tool, or an ops screen, that’s a real problem.

    The filter control design itself matters too. Multi-select checkboxes for categorical filters, sliders for continuous ranges, clear labels showing what’s currently applied and an obvious way to clear them. These aren’t novel patterns, but they’re consistently missed. The UK government’s icon design conventions for control affordances are worth reviewing here as well, since ambiguous filter icons routinely confuse users who aren’t coming from a SaaS-trained mental model.

    The filtering question connects to a broader truth about data dashboard UI design in the UK public sector context: users arrive with extremely varied data literacy. Designing a filter that a data analyst understands immediately and a non-specialist doesn’t get wrong requires real work, usually involving a lot of label text that most designers trim prematurely in the name of visual cleanliness.

    Making it work in practice

    If I were auditing a data-heavy UI right now, my checklist would look something like this. Is there one primary action or piece of information that the majority of users are looking for? Is it above the fold and visually dominant? Are tables limited to the minimum necessary columns? Is colour encoding labelled and accessible? Is there enough spacing to parse individual elements at realistic viewport sizes? Are filters visible and clearly indicating their current state?

    For tools handling government-facing data specifically, the GOV.UK Design System documentation is the most useful free resource in the UK for getting these decisions right. It’s not just about visual style; the decision rationale behind each pattern is documented, and that rationale transfers directly to commercial data product design.

    The complexity of a dataset doesn’t excuse a difficult interface. The Bin Boss-style clarity principle applies at every scale: whether you’re surfacing environment and bacteria data on a wheelie bin cleaning schedule or displaying PSC filings across ten thousand companies, the job is always to reduce the effort required to extract meaning. Everything else is just implementation detail.

    Frequently Asked Questions

    What makes a data dashboard UI design work for UK government tools?

    The best UK government data UIs, like HMRC’s business tax account and Companies House search, succeed by establishing strong visual hierarchy so the most common user task is immediately obvious, then organising subordinate information into clearly labelled sections. They also follow the GOV.UK Design System’s accessibility standards, which ensures colour contrast, type scale, and spacing hold up under real-world conditions.

    How do you handle too many columns in a data-heavy dashboard?

    The practical solution is to identify the minimum column set that covers the majority of user tasks and move everything else into an expandable detail view or secondary page. Every additional column increases cognitive load significantly, so the goal is always to display the essential data inline and make deeper detail feel one deliberate click away rather than buried.

    What colour contrast ratio should data dashboard UIs target in the UK?

    WCAG 2.1 AA requires a minimum 4.5:1 contrast ratio for text and 3:1 for graphical elements like chart labels or axis lines. UK public sector tools are required to meet this standard, and it’s a sensible baseline for any commercial dashboard handling complex datasets, particularly since data visualisation colour choices frequently fail this threshold when tested outside Figma.

    Should filter controls be visible or hidden in a data dashboard?

    Visible and persistent is nearly always the better choice. When filters are tucked into a modal or collapsed panel, users forget they’re applied and interpret scoped data as the full picture. Keeping active filter states visible, with a clear way to remove them, prevents this and significantly reduces user errors in data-intensive interfaces.

    Which free UK resources are most useful for designing government-facing data UIs?

    The GOV.UK Design System (design-system.service.gov.uk) is the starting point, as it documents not just visual patterns but the reasoning behind each decision, which transfers well to commercial data products. Ofcom’s Connected Nations reports and Companies House’s public interface are also worth studying as live examples of complex dataset presentation at scale.

  • The Grid Is Back: Why British Editorial and SaaS Sites Are Returning to Structured Layout in 2026

    The Grid Is Back: Why British Editorial and SaaS Sites Are Returning to Structured Layout in 2026

    There’s a pattern I keep noticing across British product and editorial sites this year. The scroll-jacking is gone. The parallax fever dream of overlapping sections, pinned heroes, and elements that drift sideways as you scroll has largely been replaced by something almost aggressively tidy: columns. Gutters. Baseline grids. Structure you can actually see the logic of. Editorial grid layout web design 2026 UK isn’t a niche trend, it’s quietly become the dominant aesthetic choice across everything from fintech dashboards to newspaper websites, and the reasons are both practical and, well, a bit nerdy.

    Web designer viewing an editorial grid layout on screen, illustrating structured web design in 2026
    Photo by Ann H on Pexels

    What killed scroll-jacking (finally)

    Scroll-jacking had a good run. Around 2018-2022, it was the go-to technique for agency portfolios and brand marketing sites that wanted to feel cinematic. You’d hijack the browser’s native scroll behaviour and use JavaScript to control the rate and direction of movement, triggering animations and section transitions at precise points. It looked impressive in a Behance mockup. In production, it was a mess.

    The Core Web Vitals hit landed hard. Google’s Interaction to Next Paint (INP) metric, which replaced First Input Delay in 2024, measures responsiveness across the full lifecycle of a page visit. Scroll-jacking is basically an INP torture device. Hijacking scroll events means running JavaScript on every frame, which competes directly with the main thread and produces the jank that INP penalises. Sites that relied heavily on scroll-controlled animations started seeing their performance scores crater, and with them, their organic visibility.

    There’s a broader accessibility argument too. The WCAG 2.2 guidelines make it increasingly uncomfortable to implement scroll-jacking in any context where you’re serving a broad audience. Users with vestibular disorders can experience genuine physical discomfort from non-standard scroll behaviour. If you’ve been thinking about your design approach for older or more diverse users, losing scroll-jacking isn’t just a trend, it’s the right call.

    What “the grid is back” actually means in practice

    The return to grids isn’t about making everything look like a 1980s newspaper. It’s about reintroducing constraint as a design tool. A 12-column grid with consistent gutters and a clear baseline creates a framework inside which you can be expressive without being chaotic. Elements snap. Hierarchy is legible. Whitespace is intentional rather than accidental.

    The Guardian’s web redesign, which quietly rolled out properly across desktop in late 2025, is the clearest UK editorial example. Their layout uses a strict 12-column grid with clear section breaks, typographic rhythm tied to a baseline, and almost zero decorative animation. The result is genuinely fast and very readable. The Financial Times has operated on similar principles for years, and their design team publishes openly about why performance and structure are inseparable concerns.

    On the product side, look at what’s happening in British SaaS. Monzo’s marketing site, Notion’s UK-facing landing pages, and several of the Gov.uk Design System derivatives all share a common visual grammar: restrained column layouts, strong typographic hierarchy, and interactions that are functional rather than theatrical. This is editorial grid layout web design 2026 UK in its most mature form, structure borrowed from print, filtered through web performance constraints.

    Close-up of editorial grid layout typography on a website, demonstrating UK web design structure in 2026
    Photo by Ann H on Pexels

    The CSS behind the comeback

    CSS Grid was always capable of this. The tooling just needed to catch up with the ambition. In 2026, sub-grid support is solid across all major browsers, Chrome, Firefox, and Safari all handle grid-template-rows: subgrid correctly, which means child elements can align to the parent grid without hacks. This was genuinely difficult before and explains why a lot of designers gave up on strict grids and reached for JavaScript-driven layout instead.

    The practical pattern I use most often looks something like this: a top-level grid-template-columns: repeat(12, 1fr) layout with a defined gap, and then individual sections that inherit from that grid via subgrid. Editorial content modules, article cards, feature blocks, image-caption pairs, all stay aligned to the same column lines regardless of how deeply they’re nested. It produces exactly the kind of locked-in visual rhythm you see in well-produced print layouts, without any layout JavaScript at all.

    If you’re already thinking about how this interacts with your framework choice, there’s a useful overlap with the Astro vs Next.js discussion, Astro’s islands architecture pairs particularly well with grid-heavy, largely static editorial layouts because you’re not shipping unnecessary client-side JavaScript just to paint a grid.

    Why SaaS product teams are converging on the same patterns

    SaaS dashboards and editorial sites look very different on the surface, but they share the same underlying problem: lots of information, limited screen space, users who are busy and slightly impatient. The grid solves this for both. A well-considered column structure makes data modules predictable, users learn where to look for certain types of content, and their eyes stop bouncing around looking for anchor points.

    British B2B software teams in particular seem to have latched onto this. The white-labelling constraints of multi-tenant SaaS dashboards push designers toward grids almost by necessity, a layout that needs to accommodate multiple brand skins can’t rely on pixel-specific quirks. Column grids with semantic spacing tokens adapt cleanly across themes in a way that freeform layouts simply don’t.

    Agencies that work at the intersection of web design and business software are noticing the same convergence. Based in Mansfield, Nottinghamshire, dijitul, a digital agency with a focus on web design, SEO, and software-driven business efficiency, has seen client briefs shift markedly toward structured, grid-first layouts over the past 18 months. The reasoning their clients give tends to be practical: structured layouts are faster to build, easier to maintain, and perform better in marketing contexts where page speed directly affects conversion. You can find more about their approach at dijitul.uk.

    Grids, typography, and the system-font connection

    You can’t really talk about editorial grid layout web design 2026 UK without touching on typography, because the two are inseparable. A grid that isn’t tied to a typographic baseline is just a set of invisible lines. The real magic happens when your type sizes, line heights, and spacing units all derive from a common base unit, typically 4px or 8px, so that every element in the layout sits on a predictable rhythm.

    This is a big part of why the system font trend and the grid revival are happening simultaneously. System fonts have known metrics. You know Inter’s cap height, you know how SF Pro behaves at different weights, and you can build a baseline grid around those measurements with confidence. Custom web fonts introduce variables, FOUT, layout shift, inconsistent x-heights across weights, that make locking to a baseline harder. The typography stack choices you make in 2026 have direct implications for whether your grid actually holds at render time.

    What this means for performance budgets

    The performance case for structured grids is genuinely compelling, and I think it’s the argument that’s landed hardest with UK product teams who might otherwise have resisted the aesthetic shift. A CSS Grid layout with subgrid alignment replaces an enormous amount of JavaScript that was previously being used to calculate positions, trigger animations, and manage scroll states. Less JavaScript means smaller bundles, lower INP scores, faster Time to Interactive, and fewer opportunities for layout shift.

    For a typical UK editorial site serving, say, 500,000 sessions a month, a 15% improvement in INP (which is not an unrealistic gain from removing scroll-jacking JavaScript) translates to a measurable reduction in bounce rate and a modest but real improvement in Core Web Vitals scores. Those improvements compound into organic visibility gains over time. dijitul, whose web design work is closely tied to marketing performance and client business efficiency, makes exactly this point when positioning structured layouts to clients, the aesthetic choice and the commercial outcome are aligned, which is a rare and useful position to be in for any agency doing web design in a performance-conscious market.

    Is this a permanent shift or another cycle?

    Honestly, I think it sticks this time. Previous grid revivals in web design were often aesthetic statements, designers who’d grown tired of the dominant trend reaching for the opposite. This one has structural reasons behind it. WCAG compliance, Core Web Vitals, CSS subgrid maturity, and the operational reality of maintaining large design systems all point in the same direction. Structure wins on multiple fronts simultaneously.

    There’s also a generational factor. A lot of the designers now in senior positions at UK product companies trained on print or motion backgrounds where grids were non-negotiable. They always knew how to use them, they just needed the browser tooling to catch up. Now it has. The grid was never really gone. It was just waiting for CSS to be ready.

    Frequently Asked Questions

    What is an editorial grid layout in web design?

    An editorial grid layout is a structured design system based on columns and rows, typically 12 columns with consistent gutters, borrowed from print magazine and newspaper design. It gives every element on a page a logical position relative to a shared visual framework, creating predictable hierarchy and readable layouts.

    Why are websites moving away from scroll-jacking in 2026?

    Google’s Interaction to Next Paint (INP) metric penalises pages where JavaScript interferes with scroll and input response. Scroll-jacking relies heavily on main-thread JavaScript, which tanks INP scores and hurts search visibility. There are also accessibility concerns under WCAG 2.2, particularly for users with vestibular disorders who find non-standard scroll behaviour disorienting.

    How does CSS subgrid help with structured editorial layouts?

    CSS subgrid allows child elements to align to the parent grid’s column and row lines rather than creating an independent grid inside the component. This means nested modules, like article cards or media blocks, stay locked to the same column structure as the rest of the page, producing consistent typographic rhythm without any layout JavaScript.

    Are column-based grids better for performance than freeform layouts?

    Yes, in most practical cases. A CSS Grid layout replaces the JavaScript that scroll-jacking and animation-heavy layouts depend on. Removing that JavaScript reduces bundle size, lowers Interaction to Next Paint scores, and minimises Cumulative Layout Shift, all of which contribute to better Core Web Vitals and improved organic search performance.

  • Designing Multi-Tenant SaaS Dashboards: The White-Labelling Patterns UK B2B Teams Need in 2026

    Designing Multi-Tenant SaaS Dashboards: The White-Labelling Patterns UK B2B Teams Need in 2026

    There’s a very specific kind of design hell that UK B2B SaaS teams walk into when a sales director announces: “We’ve landed a white-label deal. Can you just swap out the logo and change the colours?” The answer is technically yes. The better question is whether your design system was ever built to support it. In most cases, it wasn’t. And that’s what white label SaaS dashboard design in the UK has quietly become in 2026: a structural problem dressed up as a branding request.

    I’ve spent a fair amount of time pulling apart multi-tenant dashboard architectures, both at the design token level and in Figma component libraries, and the patterns that separate teams who cope from teams who spiral into duplication nightmares are pretty consistent. This is what actually works.

    Multi-tenant SaaS dashboard interface shown on a monitor, relevant to white label SaaS dashboard design UK
    Photo by Egor Komarov on Pexels

    Why most SaaS design systems aren’t white-label ready out of the box

    The problem usually starts at the colour layer. A team builds a design system around a single brand: one primary palette, one set of semantic colour names, one font stack. Everything works beautifully until tenant two shows up with a completely different brand identity, different primary colours, and a typeface that isn’t Inter. Suddenly you’ve got a choice: fork the entire component library, or retrofit a theming layer that the system was never designed to accommodate.

    The fork path is where most teams end up, and it’s slow, expensive, and creates ongoing maintenance debt every time a core component changes. If you’ve got six tenants and three engineers, forking is how you spend your entire sprint cycle keeping six slightly different versions of a button component in sync. No one wants that.

    The better path is design tokens, specifically a three-tier token structure that separates raw values, semantic meaning, and component-level application. This isn’t a new idea, but the W3C Design Tokens Community Group‘s draft specification has given it enough formal grounding that it’s worth implementing properly now rather than cobbling something together.

    The three-tier token structure that makes multi-brand manageable

    Tier one is your primitive tokens: raw values with no meaning attached. colour-blue-500: #2563EB. That’s it. No context, no semantic weight. Just a value in your design system’s vocabulary.

    Tier two is semantic tokens. These reference primitives but give them meaning: colour-brand-primary: {colour-blue-500}. This is where the tenant swap actually happens. When tenant B comes in with their own brand colour, you’re changing only this layer. Tier three is component tokens, which reference semantic tokens: button-background-colour: {colour-brand-primary}.

    What this means practically: swapping a tenant’s brand requires changing roughly 15 to 30 semantic tokens. Not 400 individual component properties. I’ve seen UK fintech teams get a new tenant’s dashboard looking correct in under two hours using this structure properly. Without it, the same job takes days and breaks something unrelated every time.

    This also connects nicely to the work I’d recommend reading on icon systems in UK product design, because icon colour inheritance is one of the sneakier places where teams hardcode values instead of pulling from semantic tokens, and it creates silent inconsistencies the moment you apply a tenant theme.

    Figma component strategies for multi-tenant dashboards

    Figma’s variables system (now properly mature after a rocky 2024 rollout) is the most practical way to manage multi-tenant theming at the design stage. The approach that works: one base component library, one set of variable collections per tenant, and a simple variable swap to preview any tenant’s brand in the same file.

    Set up your variable collections to mirror your three-tier token structure exactly. Primitives collection, semantic collection, component collection. When onboarding a new tenant, you’re creating a new semantic collection that maps to different primitives, and that collection swap is all it takes to see the entire dashboard re-skin in Figma. This matters beyond aesthetics: it means your handoff documentation is always correct, because the component specs are pulling live values from the right collection rather than being annotated by hand.

    One thing I’d flag specifically for UK B2B contexts: accessibility compliance. The WCAG 2.2 guidance on GOV.UK is increasingly being referenced by enterprise procurement teams when evaluating SaaS products, especially in public sector adjacent markets. When a tenant swaps their brand colours in, your semantic token structure needs to preserve contrast ratios, which means building contrast validation into your token system, not treating it as an afterthought. Figma’s built-in contrast checker helps here, but I’d also run token exports through a script that validates WCAG AA thresholds automatically before a new tenant theme goes live.

    Logo swapping and asset management across tenants

    Logo swapping sounds like the easy part. It’s not, because logos aren’t just image files, they carry implicit sizing assumptions, clear space requirements, and colour mode variants that most teams don’t standardise. A tenant hands you their logo as a 2MB PNG with a white background and you’re suddenly in a conversation about SVG conversion and dark mode variants that no one budgeted for.

    The pattern that saves time: define a logo slot specification upfront. Decide the maximum and minimum dimensions, require SVG with transparent background, specify which colour modes need variants (light background, dark background, monochrome), and document this as an onboarding requirement for every tenant. This turns an ad-hoc request process into a predictable intake checklist. It also means your Figma library has a proper logo component with defined constraints rather than a free-floating image that someone will inevitably resize incorrectly.

    Typography is the other asset dimension people underestimate. If your product uses a licensed typeface, you cannot simply apply it to a white-label tenant without checking the licence covers redistribution and sub-licensing. I covered the landscape of usable typefaces in some depth in the piece on open source font pairing for UK web design, and that’s genuinely worth reading if you’re specifying fonts for a multi-tenant product, because the safe defaults there are exactly the ones that won’t land you in a licence dispute when a tenant insists on their brand typeface.

    Building the dashboard layout layer that works for every tenant

    Theming handles colour and typography. Layout is a different layer entirely, and it’s where white-label dashboards often feel slightly wrong even when the colours are correct. The issue is density assumptions baked into the layout that suit one type of user but not another.

    If your SaaS product serves both a small UK accounting firm and a large property management group, the data they want to see on their dashboards is different, the density they’re comfortable with varies, and the navigation hierarchy that makes sense for one makes no sense for the other. Token-based theming solves the brand problem; what solves the layout problem is a modular panel architecture where tenants can configure which panels are visible without requiring you to build a custom layout per client.

    This is really a product decision as much as a design one, but the Figma implication is worth spelling out: build dashboard layouts using an auto-layout grid of configurable panel components rather than fixed-position screens. Each panel is self-contained. A tenant configuration sets which panels are active. The design system handles spacing and sizing tokens. You never hardcode a dashboard layout in a static frame again. It’s a bit more upfront work, maybe two or three additional sprints to build the panel abstraction properly, but it makes every subsequent tenant onboarding genuinely faster.

    The same thinking applies to accessibility across different user demographics. If you’re building for tenants whose end users skew older, the considerations I wrote about in the piece on designing for older users in UK product teams become tenant-level configuration concerns: default font size tokens, touch target size tokens, reduced motion preferences. These are all design token decisions, which means a well-structured system can accommodate them per-tenant without forking the component library.

    When to build this properly vs. when to ship something scrappy

    Not every white-label deal justifies a full three-tier token refactor. If you’ve got one tenant, a simple CSS variable override at the root level might be genuinely sufficient. But if your sales pipeline has more than two potential white-label clients, and especially if those clients are enterprise contracts where your product will be embedded in their internal tools under their brand, the upfront investment in a proper token architecture pays back within the first two onboardings. The maths isn’t complicated.

    The UK B2B SaaS market in 2026 is structurally pushing more products toward multi-tenancy. Procurement consolidation, budget pressure, and the growth of platform-first business models all mean your product is more likely than ever to end up underneath someone else’s logo. Building a design system that handles that gracefully isn’t a nice-to-have, it’s table stakes for products that want to scale.

  • Open Source Font Pairing in 2026: The Combinations UK Designers Are Actually Using to Replace Paid Typefaces

    Open Source Font Pairing in 2026: The Combinations UK Designers Are Actually Using to Replace Paid Typefaces

    Adobe’s price hikes have focused a lot of minds. When Creative Cloud moved to a subscription model that charges separately for fonts, and when licensing costs for premium typefaces started appearing as actual line items in client budgets, designers started asking a question they’d previously avoided: what’s actually good in the free tier? The answer, in 2026, is: quite a lot. Open source font pairing for UK web design has moved well past the Roboto-and-Open-Sans era. The combinations available now are genuinely typographically interesting, and several of them are holding up at serious scale.

    I’ve spent a fair amount of time testing these in real projects, SaaS dashboards, brand identity work, high-traffic editorial sites, and the gap between paid and free has closed considerably. Not entirely. But enough that the default answer is no longer “just buy the licence.”

    Designer reviewing open source font pairing choices on screen for UK web design project
    Photo by cottonbro studio on Pexels

    Why open source typography is a serious option now

    The Google Fonts library has around 1,500 font families at this point, and the quality distribution has shifted. The bottom half is still mediocre. But the top tier, Inter, DM Sans, Fraunces, Instrument Sans, Hanken Grotesk, Be Vietnam Pro, these are professionally designed typefaces with full variable font support, extensive glyph coverage, and active maintenance. The Google Fonts Knowledge section has become a genuinely useful resource if you want to understand the design intent behind each family before you commit.

    Beyond Google Fonts, Fontshare (by Indian Type Foundry) is worth bookmarking. Their releases are fewer but consistently higher quality, Satoshi, Clash Display, Cabinet Grotesk. All free for commercial use. For UK SaaS teams that are burned out on Adobe dependencies, this is real breathing room.

    For the variable font angle specifically, I’d point you to the typography stack deep-dive already on this blog, it covers system font decisions and loading strategy in detail. This piece is specifically about pairing logic and which combinations are working in practice.

    Pairing one: Inter + Fraunces

    This is the one I keep coming back to for SaaS interfaces that want to feel considered rather than corporate. Inter handles everything at UI scale, labels, body copy, navigation, with the kind of legibility that makes it feel almost invisible in the right way. Fraunces is the contrast: a variable optical-size serif with a slightly quirky warmth to it, designed specifically to work at display sizes.

    The pairing works because they share nothing in common except quality. Inter is rational and neutral; Fraunces has personality. Use Fraunces for hero headings and pull quotes, Inter for everything functional. I’ve seen this combination in production at a Bristol-based HR tech firm and it reads as confident without trying too hard.

    Pairing two: DM Sans + DM Serif Display

    The DM family was designed by Colophon Foundry for DeepMind and then open-sourced, which is a remarkable bit of typographic history. DM Sans is clean and geometric; DM Serif Display is sharp, high-contrast, and genuinely elegant at large sizes. Because they share a design lineage, the pairing is almost unfairly harmonious.

    I’d use this for fintech or professional services interfaces, anywhere that needs to read as authoritative. If you’re building anything that touches financial regulation, the FCA compliance design guide here covers how typography choices intersect with readability requirements. DM Serif Display at the heading level passes contrast and legibility checks without needing tweaks.

    Printed font specimen showing open source font pairing options for web design
    Photo by Ann H on Pexels

    Pairing three: Instrument Sans + Playfair Display

    Instrument Sans came out of the Figma design team’s internal tooling and was released free on Google Fonts in 2023. It’s precise, slightly condensed, and works beautifully at smaller UI sizes. Playfair Display is the more established name here, it’s been around for over a decade, but it still delivers at hero scale, especially for editorial and media brands.

    A Manchester-based digital publisher I know switched to this combination after dropping their Adobe Fonts dependency, and the brand read as sharper afterwards. Sometimes the constraint forces the right decision.

    Pairing four: Hanken Grotesk + Lora

    Hanken Grotesk is underused. It’s a geometric sans with slightly softer terminals than Inter, which makes long-form body copy more comfortable to read. Lora is a well-kerned serif with roots in calligraphy, excellent for editorial pull quotes and subheadings in content-heavy interfaces.

    This combination suits content platforms, newsletter tools, and any interface where users are reading rather than scanning. The tonal warmth of both typefaces makes it feel less like software and more like a publication. For UK teams building for older demographics, pairing choices like this matter more than you’d expect, there’s a useful perspective on that in the guide on designing for over-55 users if that’s your audience.

    Pairing five: Cabinet Grotesk + Satoshi

    Both from Fontshare, both from the Indian Type Foundry. Cabinet Grotesk has a distinctive high-x-height and slightly retro feel at display sizes, good for startups that want personality. Satoshi is cleaner, more neutral, and handles UI body text comfortably.

    I’d use this for consumer apps and B2C SaaS where the brand is trying to feel approachable. It’s not a combination you’d reach for if you need to look like a bank. But for a fintech challenger brand, or a UK health app, the personality reads as intentional rather than accidental.

    What actually matters when testing pairings at scale

    Pairing lists are only useful if you test them in real conditions. A few things I’ve learnt from production use:

    Contrast ratio between the two typefaces needs to be perceptible but not jarring. If both fonts are grotesques, the pairing needs a clear size and weight differential or it collapses into sameness. Serif and sans combinations earn their contrast structurally, which is why they’re popular, but a poorly weighted serif at body size will destroy readability on mobile displays.

    Variable font axes matter more than you’d think. If both typefaces in your pairing support a weight axis, you can create a coherent weight scale across the whole interface. Fraunces, DM Sans, and Instrument Sans all support variable weight. Locking in a consistent optical weight across heading and body is the difference between a pairing that looks designed and one that looks assembled.

    Performance is the other variable. Google Fonts serves from a CDN and has good caching behaviour, but if you’re self-hosting (which you probably should be for GDPR compliance, UK ICO guidance on third-party font requests is worth reading), use font subsetting via tools like glyphhanger or the pyftsubset utility. Only serve the characters you actually need.

    Open source fonts and site visibility: a quick note

    Typography affects Core Web Vitals, and Core Web Vitals affect how Google ranks your pages. Font loading strategy, preconnect hints, font-display: swap, subsetting, directly impacts Largest Contentful Paint. If you’re doing solid typographic work but your site is still losing ground on search, it’s worth checking the technical side of your setup. Designers building sites for UK clients occasionally ask me whether there’s a quick way to audit the full picture without commissioning a formal technical SEO report. Search Engine Tuning, a UK-based free SEO check service, lets you run a check against your domains to see how Google is reading your site from a signals perspective, including page speed issues that font loading can trigger. The free SEO check at searchenginetuning.co.uk covers the fundamentals: Core Web Vitals, indexing status, and on-page signals that affect how your pages perform in search.

    It’s a useful sanity check, particularly if you’ve recently migrated fonts or restructured your type stack, and the result gives you something concrete to work from rather than guessing which change caused a rankings shift.

    On the topic of checking your SEO: if you’re using Google Fonts via the standard CDN import, you’re making a third-party request that can flag in an audit. Self-hosting your open source fonts and serving them from your own domain sidesteps that issue entirely, keeps your font loading predictable, and removes any ambiguity around data transfer to Google’s servers, which matters for UK clients operating under UK GDPR.

    A word on licensing confidence

    The SIL Open Font Licence (OFL) covers virtually everything in the Google Fonts library and all Fontshare releases. It’s permissive: you can use the typefaces commercially, embed them in products, and modify them (with some restrictions on reselling the fonts themselves). For UK agencies worried about client contracts, the OFL is clean, no per-seat restrictions, no web impression limits, none of the complexity that comes with commercial type licences. Check the licence file in the repository regardless, but in practice OFL is the safest free licence in the industry.

    The case for open source font pairing in UK web design has been building for years. In 2026, it’s no longer a compromise position. The pairings above hold up in production, pass accessibility checks, and carry none of the overhead that comes with managing a paid type licence across a client base. That’s not a small thing.

  • The Principles Behind BBC iPlayer’s UI: What Every British Product Designer Can Learn From It

    The Principles Behind BBC iPlayer’s UI: What Every British Product Designer Can Learn From It

    I’ve spent more time than is professionally advisable picking apart how the BBC iPlayer interface works. Not watching content on it, mind you. Actually staring at hover states, tab-order behaviour, loading skeletons, and the way the navigation rail collapses on a 40-inch telly versus a 320px mobile viewport. The BBC iPlayer UI design principles UK product teams should be studying are genuinely embedded in every screen of that product, and I want to drag them out properly.

    This is a teardown, not a fan letter. Where iPlayer does something brilliantly, I’ll say so. Where there’s a head-scratching inconsistency, that’s going in too. Either way, there’s a stack of transferable thinking here that most UK product teams would benefit from nicking.

    Television screen showing a streaming content grid, illustrating BBC iPlayer UI design principles UK product teams can learn from
    Photo by https://kaboompics.com/ on Pexels

    How iPlayer handles content discovery without overwhelming you

    Content discovery is probably the hardest design problem in streaming. You have thousands of titles, a user with forty-five seconds of patience, and a recommendation system that may or may not know them well yet. iPlayer’s solution is surprisingly restrained given the scale of the BBC’s catalogue.

    The homepage is structured as a progressive hierarchy. The hero slot anchors attention, but it’s not auto-advancing like Netflix’s carousel assault on your focus. Below it, content rows are labelled with actual editorial intent: “Catch Up”, “Recommended for You”, “New Arrivals”. These are not clever algorithmic names. They’re plain English labels that tell you immediately what logic organised them. That’s a design decision, not a default.

    I’d argue the most important part of the discovery UI is what iPlayer refuses to do. There are no autoplay trailers on hover in the web interface. There’s no “you have 5 seconds before the next episode starts” pressure mechanic unless you’ve opted into it. That restraint lowers cognitive load measurably, and it respects the fact that a significant portion of the BBC’s audience, covered thoroughly in the over-55 audience design piece on this blog, find high-density motion interfaces actively hostile.

    Accessibility as a structural decision, not a retrofit

    The BBC publishes its own accessibility standards, the BBC Accessibility Standards and Guidelines, which sit alongside WCAG 2.2. That’s not marketing copy. You can see the results of it directly in iPlayer’s codebase: focus states that are actually visible (not that 1px dashed outline browsers default to), semantic HTML that makes keyboard navigation feel deliberate rather than accidental, and live subtitle rendering that works across every surface including smart TVs where most streaming services just… don’t bother.

    The subtitle implementation is worth a short paragraph on its own. iPlayer’s subtitles render as HTML text overlaid on the video container rather than burned into the video stream. That means font size, colour, and background opacity are all user-adjustable. It also means the subtitle DOM is accessible to screen readers in certain configurations. That’s technically more complex to implement than a static .vtt file being displayed, and the BBC chose to do it anyway. That’s what “accessibility as infrastructure” looks like rather than accessibility as checkbox.

    If your product team is still treating accessibility annotations as a final design-handoff step, iPlayer is a case study in why that approach breaks down. The accessibility behaviour here is inseparable from the component architecture. You can’t retrofit it cleanly. Build it in or spend twice the effort later. This connects to the same reasoning I wrote about in the icon design system teardown, where icon meaning and accessibility labelling need to be decided at the system level, not icon by icon.

    Multi-device consistency and where it gets complicated

    iPlayer runs on an extraordinary range of surfaces. A 2013 Samsung smart TV, a current-gen PlayStation, a 320px Android handset, a desktop browser, and an iPad all need to present the same content catalogue through fundamentally different interaction paradigms. That is an engineering and design problem most product teams never encounter at this scale, but the principles iPlayer uses to solve it are still directly applicable.

    The key move is abstracting the design system away from the input model. The layout responds not just to screen size but to inferred input type: pointer (mouse/trackpad), touch, or remote/d-pad. The navigation rail behaviour changes meaningfully between these modes. On a remote-controlled TV interface, every interactive element needs to be reachable via directional navigation without any pointer. iPlayer’s focus management logic handles this without the user ever thinking about it.

    For most product teams the relevant principle is this: design for your secondary device first. iPlayer’s constraints from TV remote navigation have made the whole interface more keyboard-accessible by necessity. That’s a good trade. If you’re building a web app and keyboard navigation is an afterthought, try designing the component interaction model for a d-pad first and then add pointer support on top. The resulting component will be cleaner.

    Performance design and the perception of speed

    iPlayer’s actual page performance is not perfect. Run it through WebPageTest on a throttled 4G connection and you’ll see a real-world LCP that could be sharper. But the perceived performance is well managed, and that distinction matters more to users than a 100/100 Lighthouse score.

    The loading skeleton UI is implemented with care. Skeletons match the aspect ratios of the content cards they’re replacing, including the 16:9 thumbnail, the title line, and the metadata line. When content loads, there’s no layout shift. The skeleton was drawn to the correct dimensions. This is a WCAG-adjacent win but also just good engineering; it prevents the cascading reflows that trash Core Web Vitals scores and make pages feel broken to users even when the content eventually renders correctly.

    Image delivery on iPlayer also uses responsive sizing properly. The BBC’s image service appends dimension parameters to thumbnail URLs so the browser receives an image at the correct resolution for the current viewport. I’ve seen mid-sized UK product teams serving 1200px wide thumbnails inside 240px card slots. That’s not just a performance problem; it’s a data usage problem for mobile users on capped plans, which the Ofcom Connected Nations report consistently shows is still a significant real-world concern in the UK outside major city centres.

    The design system thinking underneath it all

    The BBC’s GEL (Global Experience Language) design system is public, and it’s worth reading even if you’re not building a product that touches the BBC at all. GEL is the spine of iPlayer’s consistency. Components are defined with explicit spacing, type scales, and interaction states at the system level. Individual feature teams don’t design new card components from scratch; they pull from GEL.

    That’s the transferable bit. The specific components in GEL don’t matter to your product. The structure of the thinking does. When a design decision is made once at the system level and then pulled into features rather than reinvented per screen, you ship faster, the product feels more coherent, and edge cases (like that 320px viewport on a cheap Android handset) get solved once and inherited everywhere.

    If your team is still at the stage of building a design system, the TypeScript for designers piece is worth reading alongside this one, because codifying your tokens and component contracts in a typed system is what prevents GEL-style consistency from decaying over time as teams grow.

    The BBC iPlayer UI design principles UK teams should extract aren’t magic. They’re the result of treating design constraints as opportunities, building accessibility into architecture, and refusing to optimise for engagement metrics that make interfaces worse. That combination is rarer than it should be, and iPlayer is one of the cleaner examples of it on any screen in the country.

  • How to Build a Freelance Design Portfolio That Ranks on Google in 2026: A UK-Specific SEO Breakdown

    How to Build a Freelance Design Portfolio That Ranks on Google in 2026: A UK-Specific SEO Breakdown

    Most freelance design portfolios are beautiful and invisible. The designer has spent weeks obsessing over the grid, the typeface, the hover states, and the case study photography, and then published it to a domain that Google has essentially never heard of. I’ve seen this pattern so many times it’s almost a genre. The portfolio exists; it just doesn’t rank. And if it doesn’t rank, UK clients pitching briefs into Google, which most of them are, will never find it.

    This guide is a proper technical walkthrough for getting your freelance design portfolio to show up in organic search in 2026. Not vague advice about “posting on LinkedIn”. Actual site architecture decisions, Core Web Vitals targets, schema markup you can implement today, and the local signals that genuinely differentiate you for UK clients. Let’s get into it.

    Freelance designer's workspace with portfolio site on screen, relevant to freelance design portfolio SEO UK 2026
    Photo by ready made on Pexels

    Why freelance design portfolio SEO UK 2026 is a different problem to generic SEO

    Portfolio SEO has a structural problem that most tutorials skip. You’re not an e-commerce site with thousands of product pages, and you’re not a blog with 200 posts. You have maybe six case studies, an about page, a contact page, and a services page if you’re organised. That’s a thin site, and Google treats thin sites with suspicion unless you compensate with strong signals elsewhere.

    The UK angle compounds this. If you’re a UX designer in Bristol or a brand identity designer in Leeds, you’re not trying to rank globally. You want to appear when someone in your target geography types “freelance UX designer Bristol” or “brand designer for fintech startups UK”. That’s local SEO intersecting with professional services SEO, and the signals that matter are slightly different from what a generic content-farm guide will tell you.

    The good news: the competition is weak. The overwhelming majority of freelance portfolios have no structured data, poor Core Web Vitals, zero local signals, and a flat site structure. Doing the basics well puts you ahead of most of the field.

    Site architecture: stop building a single-page portfolio

    Single-page portfolios are a death sentence for organic search. If everything lives on one URL, you have one chance to rank, and that one page has to fight for attention across every keyword simultaneously. Google can’t index what it can’t differentiate.

    The architecture I’d recommend is simple but specific. Give each major service its own page. If you do brand identity, UX design, and motion graphics, those are three pages with three distinct keyword opportunities. Give each case study its own URL, not a modal or a lightbox. Give your about page real content, not two sentences. And if you serve specific geographies or industries, build pages for those too: “UI design for fintech” or “brand identity for London startups” are genuinely searchable.

    Internal linking matters here. Each case study should link to the relevant service page. Your service pages should link to each other where they’re related. This is the same logic I covered in the piece on bento grid layouts for SaaS product pages, where the content hierarchy directly affects how users (and crawlers) understand what you do.

    Core Web Vitals targets for 2026

    Core Web Vitals are a confirmed ranking signal, and portfolio sites have an ironic tendency to fail them badly because designers love large images and JavaScript-heavy animations. Google’s PageSpeed Insights tool is free, takes thirty seconds, and will tell you exactly where you’re losing points. Run it on your homepage and every case study page.

    The three metrics to hit: Largest Contentful Paint (LCP) under 2.5 seconds, Cumulative Layout Shift (CLS) under 0.1, and Interaction to Next Paint (INP) under 200 milliseconds. LCP is usually your biggest problem because hero images and full-bleed case study photography are heavy. Fix it by serving images in WebP format, using loading="lazy" on below-the-fold images, and using fetchpriority="high" on your actual LCP element. CLS failures almost always come from images without explicit width and height attributes or from web fonts loading late and shifting text. Fix the first with explicit dimensions; fix the second with font-display: swap and preloading your critical fonts.

    INP is newer and measures responsiveness. If you’re running a React or Next.js portfolio (which many developers do after reading our Astro vs Next.js breakdown), watch your JavaScript bundle size. Unnecessary client-side hydration is the usual culprit. Astro’s partial hydration model is genuinely excellent for portfolio sites for exactly this reason.

    Schema markup that actually moves the needle

    Almost no freelance portfolios implement structured data. This is a free win.

    For a freelance design portfolio, three schema types are genuinely useful. First, Person schema on your about page: name, job title, description, and crucially sameAs linking to your LinkedIn, GitHub, Dribbble, and any other authoritative profiles. This helps Google build a knowledge graph entity around you as a professional, which strengthens trust signals across your whole site.

    Second, LocalBusiness schema if you work with local clients. Yes, you can use this as a freelancer. Include your city, your service area, and your contact details. Make sure these match exactly what you have on your Google Business Profile. Consistency between your schema and your GBP listing is a genuine local ranking signal.

    Third, CreativeWork or WebPage schema on case study pages, with author referencing your Person entity. This connects your work back to you as the creator in a machine-readable way. None of this is technically difficult: it’s JSON-LD you drop into a <script> tag in the <head>, and Google’s Rich Results Test will validate it in seconds.

    Local SEO signals for British designers

    If you want to rank for location-specific queries, which you absolutely should if you’re pitching to UK clients, you need to treat your portfolio like a local business online. Set up a Google Business Profile under your name or your trading name, categorised as “Graphic Designer” or “Web Designer”. Add your city to your page titles, your H1s, and your meta descriptions. Not stuffed; just present. “Freelance brand designer, Manchester” in your title tag is perfectly natural.

    Get citations. In the UK, the useful ones are Yell.com, Bark.com, Clutch.co (which has a strong UK presence), and FreeIndex. These are directories that Google actually pays attention to for local professional services. Your name, trading name, and contact details need to be consistent across all of them. Use the same format every time: same spelling, same phone number format, same postcode.

    Reviews matter more than most designers think. Even five genuine Google reviews from past clients will give you star ratings in local search results. Ask clients directly after a project wraps. Most won’t think to do it unprompted, but most are happy to write one if you send them a direct link.

    Content that supports your portfolio without bloating it

    A small blog or insights section can do serious work for your portfolio’s organic visibility without requiring you to become a content machine. The trick is to write for the intersection of what you know and what your target clients are searching for. A post about “how to brief a brand designer” written from a designer’s perspective will rank for searches that UK marketing managers and founders actually type. A post about your process for UX audits will attract clients who already know they need one.

    This is also where you can build topical authority. If your case studies are all fintech work, a few posts about designing for financial services, FCA compliance in UI, or what good fintech onboarding looks like will cluster your site around that niche. Google’s understanding of what your site is about is built from the whole, not just the homepage. I’d keep each post genuinely useful: 600 words of real expertise beats 1,500 words of padding every time. And if you’re the kind of designer who also codes, pieces like our TypeScript introduction for UK designer-developers suggest the territory worth covering, where technical specificity is the differentiator.

    The technical checklist before you publish

    A few things to verify before you consider the site ready. Your robots.txt should allow crawling; it sounds obvious but I’ve seen portfolios inadvertently blocking Googlebot from staging configs carried over to production. Submit an XML sitemap via Google Search Console and verify your domain there: both the www and non-www versions if you haven’t explicitly chosen one and set a canonical. Make sure your HTTPS is properly configured with no mixed content warnings, since Google has treated HTTPS as a lightweight ranking signal for years. Check that your canonical tags point to the right URLs and that you’re not accidentally indexing paginated or filtered views that duplicate content.

    Run Screaming Frog on your domain (the free version handles up to 500 URLs, which is plenty for a portfolio) to catch broken links, missing meta descriptions, and duplicate title tags. Fix those before you build links or push for rankings. The foundation has to be solid or the rest of the work is wasted.

    Freelance design portfolio SEO in the UK isn’t glamorous work. It’s structured data in a text editor, image compression, and directory submissions. But it compounds. The designer who does this in January and publishes two genuinely useful blog posts a quarter will be fielding inbound enquiries by the end of the year from clients they never had to cold-pitch. That’s the whole point.

    Frequently Asked Questions

    How long does it take for a freelance design portfolio to rank on Google?

    For a new domain with good technical foundations, expect three to six months before meaningful organic traffic appears. If you’re targeting low-competition local queries like “freelance designer [UK city]”, you can sometimes see results faster, particularly if you have a complete Google Business Profile and a handful of citations from UK directories.

    Do I need a blog on my portfolio to rank in UK search results?

    Not strictly, but it helps significantly. A blog lets you target informational keywords that your target clients search for, and it builds topical authority around your niche. Even four to six well-written posts per year can meaningfully expand the number of queries your portfolio ranks for.

    What's the best platform for building a portfolio that ranks well?

    Anything that gives you full control over your HTML, meta tags, and structured data. WordPress with a lightweight theme, Astro, or Framer (which now has solid SEO controls) are all solid choices. Avoid platforms that lock your content behind JavaScript rendering without server-side rendering, as Googlebot can struggle with purely client-rendered content.

    Does my Google Business Profile matter if I work remotely with clients across the UK?

    Yes. Even remote freelancers benefit from a GBP listing because it gives you visibility in local pack results when clients search in your city. Set your service area to the regions you actually serve. You don’t have to list a physical address publicly if you work from home.

    How many case studies do I need for good SEO on a freelance portfolio?

    Quality beats quantity. Three to five detailed case studies, each on its own URL with a proper description of the brief, your process, and the outcome, will outperform ten brief project thumbnails on a single page. Give each case study page a unique title tag and meta description targeting the specific type of work it represents.

  • Designing for Older Users: What UK Product Teams Get Wrong About the Over-55 Audience Online

    Designing for Older Users: What UK Product Teams Get Wrong About the Over-55 Audience Online

    Ofcom’s 2024 Online Nation report put a number to something most product teams already suspect but rarely act on: the over-55 demographic is one of the fastest-growing online cohorts in the UK. Not just growing. Growing fast. And yet, if you spend an afternoon watching someone in that age group try to use a typical SaaS product or a government-adjacent web app, you will feel genuine embarrassment at the assumptions baked into our interfaces. I’ve sat in enough usability sessions to know that the gap between what designers think older users can handle and what actually happens on screen is enormous.

    This isn’t an accessibility checkbox article. It’s about the specific, recurring design decisions that make products hostile to people over 55, and what switching those decisions actually looks like in practice. The fix is almost never a separate “accessibility mode”. It’s just better design.

    Older woman using a tablet at home, relevant to designing for older users UK accessibility
    Photo by Marcus Aurelius on Pexels

    Why the over-55 audience is not who you think it is

    The lazy mental model of an older user is someone confused by technology. That model is outdated and statistically wrong. Many people in the 55-75 bracket have been using the internet since the late 1990s. They have more disposable income than younger demographics, they shop online, they bank digitally, they stream. According to Ofcom’s internet use research, broadband penetration among over-65s in the UK has risen significantly year on year. These are not digital novices. They are experienced users dealing with interfaces built by people who did not design with them in mind.

    The actual challenges are specific. Contrast sensitivity changes with age. Motor precision decreases. Reading speed slows when type is small or poorly spaced. Working memory means multi-step flows with no persistent progress information are genuinely harder to complete. None of these things mean someone is bad at technology. They mean the technology is bad at accommodating normal human variation.

    The contrast and type size failures that are everywhere

    Grey text on a white background is the single most common UI failure I see when looking at products aimed at a general UK audience. Designers use it because it looks refined. WCAG 2.1 AA requires a contrast ratio of at least 4.5:1 for normal text. The trendy light-grey placeholder text in form fields routinely fails this. The secondary text on pricing pages fails this. The fine print on checkout screens absolutely fails this.

    Type size is the other obvious one. A base font size of 14px or 15px might render acceptably on a 27-inch monitor at your desk. On a tablet held at arm’s length by someone whose near vision has shifted, it is punishment. Sixteen pixels should be the floor. Eighteen is more honest for body copy. Line height below 1.5 compounds the problem by collapsing the space between lines that lets the eye track correctly.

    If you’ve been reading my earlier piece on choosing and pairing system fonts for the web, you’ll know that system fonts carry genuine legibility advantages at body size, particularly because they’ve been hinted and rendered for the OS they live on. That advantage matters more for older users than it does for anyone else.

    Touch targets and motor precision

    A 24px icon button that expands a menu is fine when you’re 29 and have the fine motor control of someone who grew up texting on a glass screen. It’s a genuine barrier when your hands are less precise. Apple’s Human Interface Guidelines recommend a minimum touch target of 44 by 44 points. Google’s Material Design says 48 by 48dp. Most production UIs I audit for clients are hitting 32 by 32 on interactive elements, sometimes less.

    The fix is not complicated. Add padding. Use larger hit areas than the visible icon. Space interactive elements so that missing one doesn’t accidentally trigger another. These are also excellent improvements for mobile users on a bumpy train, so they help everyone. Good accessibility decisions usually do.

    Related to this: hover states that only appear on desktop are not a navigation strategy. Dropdown menus that require hovering and then moving precisely into a sub-menu without the menu disappearing are a known usability failure for everyone, but disproportionately so for users with slower or less precise cursor movement. The solution is click-to-open behaviour or a transition delay on the menu close.

    Cognitive load and the multi-step flow problem

    The pattern I see causing the most drop-off with older UK users in usability research is multi-step flows with no persistent progress indicator and no ability to go back without losing state. Checkout flows. Application forms. Account setup wizards. The assumption is that a user will hold the full mental model of where they are in the process. That assumption is wrong for many users, and increasingly wrong as the complexity of the task increases.

    Persistent breadcrumbs on long forms. Clear step indicators that say “Step 3 of 5”. Save and return later functionality for longer forms. Autofill that actually works correctly with UK address formats. These are table stakes that many products have not implemented.

    Error messages deserve their own mention. Generic messages like “An error occurred” or “Invalid input” with a red border and no further context are genuinely useless. Precise errors that say “Your sort code should be six digits with no spaces” or “Your date of birth should be in DD/MM/YYYY format” are what accessibility looks like in practice.

    The icon-only interface trap

    Icon-only navigation has been creeping into UK product design for years. It looks clean in Figma mockups at 100% zoom. It is confusing in practice for a significant portion of users. My piece on how product teams are getting their icon systems wrong covers this at length, but the short version is: icons without labels are only clear when the iconography is universal and learnt. Most product icons are neither. Older users who didn’t grow up with a particular design language’s conventions find ambiguous icons significantly harder to decode. Add labels. Combine the icon with text. It adds a few pixels of height to your nav and it eliminates a major source of confusion.

    Designing for older users UK accessibility in real product decisions

    The design decisions that actually fix these issues are not a separate track from good design. They’re the same decisions. High contrast ratios look more professional, not less. Larger text with good line height reads better for everyone. Clear error messages reduce support tickets. Persistent progress indicators reduce abandonment. These are all wins on metrics that product teams already care about.

    If your team hasn’t done usability testing with participants over 55, do it. Recruit through local community organisations, Age UK, or digital inclusion programmes. Watch what happens. I guarantee you will find at least three things to fix before the session ends, and you will fix them faster than any other research you’ve done, because the problems are visible and the solutions are concrete.

    One practical first step: run your existing UI through a contrast checker (there are browser extensions for this) and sort the failures by page priority. Fix the worst offenders on your homepage and primary conversion flows first. That alone will move your accessibility score and your conversion numbers simultaneously.

    The broader point is that designing for older users in the UK isn’t a niche concern or an edge case. It’s designing for a large, growing, and financially significant audience that is currently being failed by most of the interfaces they encounter. Fix the contrast. Fix the type size. Fix the touch targets. Fix the error messages. Then actually test with the people you’re designing for. The rest follows from there.

  • The Typography Stack in 2026: How to Choose and Pair System Fonts Without Looking Cheap

    The Typography Stack in 2026: How to Choose and Pair System Fonts Without Looking Cheap

    Here’s the thing that nobody says out loud: most web font implementations are a performance tax in disguise. You add a Google Fonts <link> in the <head>, you pick something that looks nice in Figma, and then you wonder why your Largest Contentful Paint is a disaster. I’ve watched this play out on dozens of projects, and the pattern is almost always the same. The typography looks considered, the loading experience does not.

    Building a solid system font stack in 2026 isn’t about giving up on brand expression. It’s about being smarter with what you load, when you load it, and how you fall back gracefully when things go wrong. This guide walks through the actual mechanics of doing that, from stack construction to subsetting to font-display strategy, with enough detail to be genuinely useful rather than just vaguely inspirational.

    Designer reviewing a system font stack layout on a widescreen monitor
    Photo by Miguel Á. Padriñán on Pexels

    Why system fonts deserve more respect than they get

    The reputation of system fonts is stuck somewhere around 2014, when using them felt like admitting defeat. That narrative is outdated. The current default system stacks are genuinely good. Apple’s San Francisco is a masterclass in legibility at small sizes. Segoe UI Variable (shipping with Windows 11) is properly optical-size aware. Inter, whilst technically a web font, ships natively in several Linux environments and is increasingly used as a system default in design tools.

    A well-constructed system font stack in CSS looks something like this:

    font-family:
  system-ui,
  -apple-system,
  BlinkMacSystemFont,
  'Segoe UI Variable',
  'Segoe UI',
  Roboto,
  Oxygen,
  Ubuntu,
  sans-serif;

    That stack costs zero bytes, loads in zero milliseconds, and renders without layout shift. On a content-heavy site, that’s worth a lot. The Core Web Vitals improvement alone can be significant, particularly for Cumulative Layout Shift (CLS) and LCP, both of which get hammered by render-blocking font requests.

    When you actually need a web font (and when you don’t)

    I’d argue the honest answer is: less often than you think, and almost never for body copy. System fonts at 16px with sensible line-height and letter-spacing are perfectly readable. The use cases where a web font genuinely earns its keep are narrower than most designers admit.

    Genuine reasons to load a web font include: a logotype-adjacent display face that’s core to the brand identity, a distinctive serif for editorial contexts where the personality of the letterform matters, or a monospaced font for code samples where system options (Courier New, I’m looking at you) are visually terrible. Body copy at 16–18px? The system font stack wins almost every time.

    The question I ask on every project is whether a user could actually tell the difference between the web font and a well-configured system font at reading distance. More often than not, the answer is no. What they will notice is a flash of invisible text or a layout jump. That’s the trade you’re making.

    CSS code showing a system font stack configuration in a dark-theme editor
    Photo by Pixabay on Pexels

    How to load web fonts without destroying your performance scores

    When a web font is genuinely justified, the loading strategy matters as much as the font itself. There are three levers that make the biggest difference: self-hosting, subsetting, and font-display.

    Self-host everything

    Stop using Google Fonts via CDN. It creates a cross-origin request that costs you a DNS lookup, a TCP connection, and potentially a TLS handshake before a single byte of font data arrives. Self-host the files on your own domain instead. Tools like google-webfonts-helper generate the CSS and font files you need in seconds. Your font is now one fewer external dependency, and you have full control over caching headers.

    Subset aggressively

    A full variable font file can be 200–400KB. For a UK-facing site serving primarily Latin-script content, you need maybe 20% of that. The unicode-range descriptor in your @font-face rule tells the browser which characters are actually in each file, so it only downloads the subset it needs. Use pyftsubset from the fonttools library to strip everything you don’t need. A Latin subset for English content typically covers U+0020–U+00FF, plus U+2013–U+2122 for typographic punctuation. That’s it.

    For a typical paragraph-weight subset, I regularly get files under 20KB. That’s a very different conversation than serving 300KB of font data for characters your users will never see.

    Use font-display correctly

    The font-display descriptor controls what happens whilst your web font loads. The options matter:

    • swap renders immediately in a fallback, then swaps when the web font arrives. Fast but causes layout shift.
    • optional gives the browser a very short window to load the font; if it doesn’t arrive in time, the browser uses the fallback for the entire page load. Zero layout shift, and on repeat visits the cached font renders immediately. This is my default for body fonts.
    • block renders invisible text for up to 3 seconds. Avoid it. It’s what’s killing your LCP on slow connections.

    For display fonts where the visual difference genuinely matters, swap is acceptable if you’ve done the work to minimise the metric mismatch between your web font and fallback. Which brings us to the next bit.

    Matching your fallback metrics to eliminate layout shift

    The biggest cause of font-related CLS is metric mismatch: your web font has different line-height, letter-spacing, or ascender/descender values than the system font rendering in its place. When the web font arrives, everything reflows. That’s the jump users hate.

    CSS now has size-adjust, ascent-override, descent-override, and line-gap-override descriptors inside @font-face, and they’re specifically designed for this. You apply them to a local fallback font definition to make it metrically equivalent to your web font. The Malte Ubl approach of using the Font Style Matcher is worth reading, and the Fontaine library automates this for build pipelines.

    A simplified example for matching Inter with a system fallback:

    @font-face {
  font-family: 'Inter Fallback';
  src: local('Arial');
  ascent-override: 90.2%;
  descent-override: 22.48%;
  line-gap-override: 0%;
  size-adjust: 107.4%;
}

body {
  font-family: 'Inter', 'Inter Fallback', system-ui, sans-serif;
}

    The layout is now almost identical before and after the web font loads. CLS drops to near zero. This is the kind of detail that separates a properly engineered typography stack from one that just happens to look okay in Figma. Incidentally, if you want to see this principle applied at scale, the approach connects directly to the same performance discipline I mentioned in our variable fonts deep dive, which covers how font axes interact with rendering at different viewport sizes.

    Pairing system fonts with brand type: a practical approach

    The pairing model I’ve settled on for most UK product work is a single web font for display headings (H1, H2, hero text) and a system font stack for everything else: body copy, UI labels, form inputs, navigation. This gives you brand personality where it’s visible, and zero performance cost where it isn’t.

    For display type, a variable font is almost always the better choice over a static weight. You get the full weight and width axis with a single file. Fonts like Cabinet Grotesk, Fraunces, or Anybody Variable cover a huge range of expressive territory at roughly 40–80KB subsetted. Pair that against system-ui for body and the contrast is actually better than two web fonts fighting for attention.

    The same principle applies to design systems built in Figma. If your design system is using a bespoke web font for every text style, someone on the engineering side is eventually going to raise a performance ticket. Getting ahead of that in the design phase, by deliberately scoping which styles use the web font and which defer to system defaults, is much cleaner than retrofitting it later. The same discipline that makes a good design system in Figma applies here: decide at the token level which typefaces are brand-critical and which are functional.

    On a practical note: some niches have specific loading constraints that make this even more pressing. Anyone building content-heavy landing pages under heavy traffic, whether that’s e-commerce, media, or specialist verticals like vape seo where organic performance is critical, will feel font loading overhead in real conversion metrics. It’s not an abstract concern.

    Preloading the right files

    If you’ve subsetted correctly, you can preload your critical font files without much guilt. The pattern is a <link rel="preload"> in the document <head>, pointing at your subset WOFF2 file with as="font" and crossorigin. This tells the browser to fetch it as early as possible, even before the CSS is parsed.

    Only preload what’s above the fold. Preloading three font weights because they all appear somewhere on the page is still a mistake. For most sites, one or two files is the right ceiling. The web.dev font best practices guide covers the nuances of preload priority, and it’s worth reading alongside your Lighthouse report rather than in isolation.

    The goal isn’t a font system that’s technically impressive. It’s one that users never think about because the text was simply there, readable and on-brand, from the first paint. That’s harder than it sounds, but the tooling in 2026 makes it genuinely achievable without exotic build steps or compromising visual quality.

    Frequently Asked Questions

    What is a system font stack and why should I use one?

    A system font stack is a CSS font-family declaration that references fonts already installed on the user’s operating system, such as San Francisco on macOS or Segoe UI on Windows. Because no files need to be downloaded, there’s zero loading time and no risk of layout shift from font swapping. For body copy especially, modern system fonts are high-quality and save significant performance overhead.

    Do system fonts hurt brand identity?

    Not if you’re strategic about where you use them. The approach most experienced product teams use is to load a single web font for display headings and marketing-facing text, while using a system font stack for body copy, labels, and UI elements. You preserve brand character where it’s most visible, and avoid paying a performance cost on the parts users don’t consciously notice.

    What is font-display: optional and when should I use it?

    The font-display: optional descriptor gives the browser a very short window (typically around 100ms) to load a web font; if it doesn’t arrive in time, the fallback is used for that entire page load and no swap occurs. On subsequent visits, the cached font renders immediately with no shift. It’s the best choice for body fonts because it eliminates Cumulative Layout Shift entirely whilst still serving the web font to most repeat visitors.

    How do I stop my web fonts causing layout shift (CLS)?

    The main cause is metric mismatch between your web font and its fallback. Use the CSS descriptors ascent-override, descent-override, and size-adjust inside a local @font-face rule to make your system fallback font metrically match your web font. This means the layout stays identical before and after the web font loads, bringing CLS close to zero. Tools like Fontaine can automate this at build time.

  • Astro vs Next.js in 2026: Which Framework Should UK Web Developers Actually Build With?

    Astro vs Next.js in 2026: Which Framework Should UK Web Developers Actually Build With?

    The framework debate has a new shape in 2026. A couple of years ago, the conversation was basically “are you using Next.js or are you wrong?” That’s no longer the case. Astro vs Next.js is now a genuine technical decision, and if you’re a UK freelancer or small agency picking a stack for a new project, getting it wrong costs you real time and money. I’ve spent a fair chunk of the last year shipping with both, and I have opinions.

    This isn’t a “both are great in their own way” fence-sit. I’ll tell you which one wins for which type of work, what the hosting implications look like on UK infrastructure, and why the choice matters more than most tutorials let on.

    Web developer comparing Astro vs Next.js framework code on dual monitors
    Photo by Alicia Christin Gerald on Pexels

    What each framework actually is

    Next.js, maintained by Vercel, is a React-based full-stack framework. It does server-side rendering, static generation, incremental static regeneration, API routes, middleware, edge functions, the lot. It’s been the default choice for serious React projects for years, and the ecosystem around it is enormous.

    Astro is something different. It’s an islands-architecture framework that ships zero JavaScript to the browser by default. You write components in whatever flavour you fancy (React, Svelte, Vue, or plain HTML) and Astro only hydrates the interactive bits. The result is pages that are genuinely fast in a way that feels almost unfair. For content-heavy sites, the Lighthouse scores are embarrassing compared to a typical Next.js build.

    These two frameworks are not really competing for the same use case. The problem is that a lot of developers reach for Next.js out of habit, even when Astro would be the smarter pick.

    Build performance: where Astro genuinely wins

    For a marketing site, a blog, a documentation hub, or a portfolio, Astro is faster to build with and faster to serve. Full stop. The islands architecture means your pages arrive in the browser as HTML with CSS, and only the components that need interactivity (a search bar, a contact form, a live pricing widget) get JavaScript injected. Everything else is static.

    I rebuilt a client’s agency site last autumn, previously on Next.js with a bloated component tree, and the move to Astro dropped Time to First Byte from around 800ms to under 120ms on a cold UK edge. The Core Web Vitals went green across the board without any heroics. If you’ve been wrestling with layout performance issues at the CSS level, the framework layer matters even more than you might think.

    Next.js, by contrast, carries React into the browser on every page by default. Even with server components (which are genuinely clever and have improved things substantially), you’re shipping more JavaScript than Astro would. For a SaaS dashboard, a social platform, or anything with heavy real-time state, that’s a reasonable trade. For a brochure site? It’s not.

    Hosting costs on UK providers

    This is where the decision gets practical and where UK developers often get stung. Next.js is heavily optimised for Vercel’s own infrastructure. That’s not a criticism, Vercel is a good product, but their free tier has limits that bite fast, and their Pro tier at roughly £17 per user per month adds up for a small agency with multiple projects running.

    Alternatives like Netlify or UK-adjacent providers such as Cloudflare Pages handle Next.js, but you lose some features (middleware running on Vercel’s edge, ISR at the granular level) or find workarounds necessary. The Vercel lock-in is real, even if the company insists otherwise.

    Astro sites, because they’re largely static output, deploy anywhere. Cloudflare Pages for free. An S3-compatible UK bucket behind a CDN. Your client’s existing cPanel host, if it comes to that. I’ve run Astro sites on Hetzner VPS instances in their UK datacentre (Falkenstein is technically Germany, but their London presence is growing) for under £5 per month including everything. Next.js apps with server-side requirements need a Node runtime, which means either a managed platform with associated costs or your own self-hosted VPS setup that you need to maintain.

    For UK freelancers billing smaller clients, the hosting cost difference can genuinely affect whether a project is profitable at the price point the client expects.

    Which projects actually suit each framework

    Astro wins for: marketing sites, landing pages, blogs, documentation, portfolios, news sites, e-commerce storefronts where the cart is a third-party embed, and any project where content is the primary product. If the page is mostly read, not interacted with, Astro should be your first choice.

    Next.js wins for: SaaS products with authenticated dashboards, apps with real-time data requirements, anything with complex server-side logic that needs to live close to the data layer, and projects where the team is already deep in the React ecosystem and moving away would cost more than it saves. It’s also the better pick when you’re building something that will grow into a full application, because its routing and API layer scale well.

    A pattern I see constantly in UK agency work: someone specs a Next.js build for a 12-page product site because the team knows React. The site ends up with a bundle size north of 800KB for pages that are basically text and images. Then they spend a sprint optimising what the framework choice created. Astro wouldn’t have done that.

    There’s also a middle path worth mentioning. Some teams are now running hybrid setups: Astro for the public-facing marketing and content pages, Next.js (or a lighter alternative like Remix) for the authenticated product area. The two can coexist on subdomains or subdirectories, and if you’re thoughtful about the split, you get the best performance characteristics of both without too much architectural overhead.

    The developer experience difference

    Next.js has the larger ecosystem, more Stack Overflow answers, and a bigger community in the UK dev scene. If you’re hiring or collaborating, finding someone familiar with Next.js is easier. The Astro community is growing fast, and the documentation is genuinely excellent, but it’s still smaller.

    Astro’s component model, where you can mix React, Svelte, and vanilla components in the same project, sounds chaotic but is surprisingly workable. For a freelancer who has built up a library of components across different frameworks, it’s actually liberating. I’ve pulled in a React data-viz component alongside a Svelte interactive widget and it just worked. That flexibility is part of why Astro suits project-based freelance work so well.

    One thing I’ve noticed: clients who care about their web presence (the ones spending money on cookie free display advertising UK services and similar performance-focused digital channels) are increasingly asking specific questions about page speed. Astro makes it much easier to hit those targets without a performance engineering sprint at the end of every project.

    For teams already building design systems or working across multiple products, the framework choice also interacts with your component architecture. If you’re maintaining icon systems or a full icon design system across multiple surfaces, understanding how your framework handles component hydration will affect how you structure those shared resources.

    My actual recommendation

    Default to Astro for anything content-first. The performance advantages are real, the hosting costs are lower, and the developer experience is genuinely good. You won’t spend three hours debugging why your bundle includes a library you imported once in a layout file.

    Use Next.js when the project genuinely needs it: persistent server-side state, complex auth flows, real-time features, or a codebase that’s going to grow into something an engineering team maintains long-term.

    The Astro documentation is worth an afternoon of your time even if you’re not planning to use it immediately. You’ll come away with a much clearer sense of what “islands architecture” actually means in practice, which makes the Next.js vs Astro decision far more intuitive when a new project lands on your desk.

    Both frameworks are mature, production-ready, and supported well enough that you won’t be stranded. The choice is about fit, not about quality. Pick the tool that matches the problem, not the one you’re most comfortable with.

    Frequently Asked Questions

    Is Astro faster than Next.js for production sites?

    For content-heavy, mostly static sites, yes, Astro ships zero JavaScript by default, which results in dramatically smaller payloads and faster load times. For highly interactive apps like SaaS dashboards, Next.js with server components is more competitive because it’s designed for that kind of complexity.

    Can I host an Astro site on cheap UK hosting?

    Yes, and that’s one of Astro’s main advantages. Because the output is static HTML, CSS, and minimal JS, you can host on Cloudflare Pages (free tier is generous), any S3-compatible storage, or a basic UK VPS for a few pounds per month. Next.js apps with server-side features need a Node runtime environment, which typically costs more.

    Should I use Astro or Next.js for a SaaS product?

    Next.js is the stronger choice for a full SaaS product with authenticated users, complex server logic, and real-time data requirements. That said, many SaaS teams use Astro for their public marketing site and Next.js only for the authenticated app area, which is a sensible split.

    Does Astro work with React components?

    Yes. Astro supports React, Svelte, Vue, Solid, and plain HTML components in the same project simultaneously. Only components that need client-side interactivity are hydrated; everything else renders as static HTML at build time.

The Latest