Hire a web designer: what performance-aware buyers should check first

When you hire a web designer, you are not just buying visual taste — you are buying a set of decisions that will either help or hurt your site's search rankings, loading speed, and conversion rate for the next two to three years. Most buyers evaluate portfolios on aesthetics alone and end up with a beautiful site that scores 38 on PageSpeed Insights.

What "web designer" actually means in 2026

The job title is genuinely ambiguous, and that ambiguity costs clients money. There are at least three distinct profiles hiding behind it:

Visual designer only. They produce Figma files. They do not touch code. You will need a separate developer to build what they hand off, and the visual-to-code handoff is where performance problems usually begin — oversized images, fonts loaded synchronously, animations that block the main thread.

Designer who codes. They can build in HTML/CSS, maybe light JavaScript or a page builder (Webflow, Framer). They can ship a site without a separate developer, but they are unlikely to think in terms of React Server Components, edge caching, or INP budgets.

Design-capable developer. They work in Next.js or a comparable framework, hold strong enough visual judgment to produce a coherent design system, and make performance decisions during build rather than patching them afterward. This profile is rarer and charges accordingly — but for content-heavy or e-commerce sites, it is almost always the right choice.

Before you post a job description or send an enquiry, decide which profile your project actually needs. A brochure site for a local service business does not need a design-capable developer. A SaaS marketing site with a blog, personalised content, and organic search goals almost certainly does.

Portfolio signals that matter beyond looks

Ask every candidate to share three to five live URLs they have shipped, not Behance screenshots or Figma prototypes. Then do this with each URL:

1. Run it through PageSpeed Insights. Note the LCP, INP, and CLS scores on mobile. A good site should hit LCP under 2.5 s, INP under 200 ms, and CLS under 0.1. These are Google's "good" thresholds, not aspirational targets.
2. Open the Network tab in DevTools and reload with cache disabled. Note total image weight. Anything above 1 MB on a content page is a red flag.
3. Check whether images are served as WebP or AVIF, not just JPEG. This is a basic signal that whoever built the site was paying attention to asset delivery.
4. Look at the font loading strategy. If you see a flash of invisible text or a significant layout shift as fonts load, that is a CLS and LCP problem baked into the design.

You do not need to be technical to run these checks. PageSpeed Insights gives you a score and explains every failure in plain language.

Performance questions to ask before you hire

These questions are not trick questions — they are calibration questions. A candidate who cannot answer them is probably not the right fit for a site where search performance matters.

"How do you handle images in your builds?" The answer should mention responsive sizing, modern formats (WebP/AVIF), and lazy loading below the fold. Bonus if they mention width and height attributes or aspect-ratio CSS to prevent layout shift.

"What's your approach to font loading?" They should mention font-display: swap or optional, preloading critical fonts, and hosting fonts locally rather than relying on a Google Fonts request that adds a DNS lookup.

"How do you test performance before handing off?" Lighthouse in CI, PageSpeed Insights, or a tool like WebPageTest. If the answer is "I just eyeball it," that tells you everything.

"Have you ever had to fix a Core Web Vitals issue after launch?" This is the most revealing question. Everyone makes mistakes; what you want to know is whether they understand the cause-and-effect well enough to diagnose and fix problems.

"What does your staging and handoff process look like?" A professional will have a staging URL with password protection, a clear review cycle, and written documentation of any third-party scripts or services the site depends on. Someone who sends you a zip file of HTML is not set up for a collaborative, revision-based process.

Red flags worth walking away from

Portfolio only exists as screenshots. If there are no live URLs, you cannot verify performance, accessibility, or that the work is theirs at all.

Guaranteed first-page Google rankings. No designer, developer, or SEO consultant can guarantee this. Anyone who says so is either ignorant or deliberately misleading you.

"I'll handle the SEO too" with no specifics. SEO in 2026 is a combination of content strategy, technical implementation (Core Web Vitals, structured data, sitemaps, robots.txt), and link building. One person doing all of it well is unusual. Ask them to be specific about which part they handle.

No discovery or scoping phase. A designer who quotes a fixed price from a one-paragraph brief without asking questions will either overpromise or underdeliver. Scoping exists to protect both sides.

Reluctance to share CMS credentials or source code at handoff. You should own everything: the code repository, the CMS, the DNS, the hosting account. Any arrangement where the designer retains control over your site after payment is a structural risk.

Matching the profile to your actual project

If you are rebuilding a marketing site with a headless CMS, blog, and structured data requirements, hire the design-capable developer profile and expect to pay senior developer rates — typically $4,000–$15,000+ for a project, depending on scope and location. The premium pays for itself in reduced rework after launch.

If you are building a standalone Figma design to hand to an existing development team, a visual designer is the right hire and you should evaluate them purely on craft, communication style, and component organisation quality in Figma.

If you need a quick brochure site with no complex CMS requirements, a designer-who-codes on Webflow or Framer is often the most efficient path — just verify their Core Web Vitals scores on existing work before you commit.

The decision is not about prestige or rates. It is about matching the capability to the deliverable your site actually needs.