We use the phrase high-performance website a lot, and so does everyone else. On most homepages it means a template with a speed badge, a Lighthouse screenshot in the seventies, or a claim that the site is "optimised" with no account of for what. That is not what we mean. The word has started to describe the opposite of the thing.
A high-performance website does three jobs at once. It makes a clear case in the first viewport. It loads and responds like a product rather than a brochure. And it can be found by the systems that now decide who gets the click. Miss any one of those and you have a pretty site, or a fast site, or a findable site. You do not have a high-performance one.
It is not a Lighthouse screenshot
Lighthouse is a lab tool. It is useful, and it is very good at making people feel panicked or smug about a number a real visitor never sees. We have written about what Core Web Vitals actually change. The short version: field data matters, the composite score does not, and chasing a 99 while the page still takes three seconds to become useful on a phone in a tram is the wrong optimisation.
A template with a "fast" badge is the same category of mistake. The badge is a marketing claim about the theme. It says nothing about your images, your tag manager, your cookie banner, or the hero video that autoplays before anything else has loaded. Page builders can produce a respectable lab score on an empty demo. They fight you the moment you put a real business on them, because the default is to ship the kitchen sink and then try to prune it.
If the only evidence that a site is high-performance is a screenshot, it is not.
A marketing site is a product
The first job is the one most "performance" conversations skip. Before anyone cares how fast the page became interactive, they have already decided whether they trust you.
That decision happens in the first viewport. Not the fifth scroll, not the about page. The first screen has to answer, without decoration: what is this, who is it for, and what should I do next. One clear action. Not five equally loud buttons, not a carousel of everything the company has ever offered, not a clever line that only makes sense once you already know the product.
Type is part of that, not a garnish. Sizes that relate to each other. Line lengths a person can actually read. A hierarchy that still works on a phone, which is where most of this traffic arrives. Trust is the residue of those decisions: real text instead of placeholder copy, photographs that belong to the company, a willingness to name what you do in plain language.
We treat a marketing site as a product because it has users, a job to do, and a failure mode. The user arrived with a question. The job is to answer it and give them a next step. The failure mode is that they leave for someone who made it easier. Design that ignores that sequence is decoration. Vibe-coded sites fail the test in a particular way: they look finished until you notice nothing on the page was a decision.
The method is dull on purpose.
- Write the one sentence that should sit at the top of the page.
- Cut everything in the first viewport that does not serve it.
- Give the remaining action a verb a human would actually use.
- Hold every later section to the same rule: one job, one primary action, no orphan blocks that exist because the sitemap said they should.
If you cannot do that on paper, a new theme will not do it for you.
Engineering that a ranking system can feel
The second job is the one people usually mean when they say performance, and they are not wrong to care about it. Google uses Core Web Vitals as a ranking signal: Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint. The useful way to think about them is not as a score to game, but as a description of whether the page became useful, stayed still, and responded when touched.
What actually moves those numbers on a marketing site is structural.
- Serve the HTML from the edge, close to the visitor, not from a single origin box a continent away.
- Ship the first viewport before you ship the rest. The hero image is the LCP candidate on most marketing pages; give it a real size, a modern format, and a fetch priority, or it will sit there while the rest of the page argues with itself.
- Do not block the first paint with a font file, a tag manager, and three widgets. Load the type so the layout does not jump. Reserve space for anything that arrives late.
- Keep the JavaScript on a marketing page closer to "a bit" than "a product application." INP problems on brochure sites are almost always optional scripts, not the product.
Page builders fight this because their business is flexibility. Flexibility means shipping a runtime that can do everything, then turning most of it off. You pay for the runtime anyway. That is why a Webflow or WordPress site can look fine in a demo and still fail in the field: the theme is not the bottleneck, the architecture is. You can improve one. You cannot usually rescue the other without leaving the builder.
None of this is exotic in 2026. It is just rarely what the page-builder path produces by default.
What Google, Seznam, and ChatGPT actually parse
The third job is discovery, and a fast, beautiful site can still fail it. A crawler, and an assistant, do not see your layout. They parse text, structure, and whether the same facts show up in more than one place.
That means headings that describe the content rather than decorate it. Real copy in the language the visitor searches in, not a machine mirror of the English page. Structured data that states the obvious: who you are, where you operate, what you offer. A bilingual site because someone wrote both versions, not because a plugin swapped strings.
Google is relatively good at inferring. Seznam is less forgiving of thin or English-only pages aimed at a Czech audience, and it leans on Firmy.cz in a way foreign teams still miss. Assistants are worse than either at guessing. If your homepage cannot complete the sentence "this is a company that ___ for ___ in ___", ChatGPT will recommend someone who can. Those levers are build decisions, not a later SEO phase.
The method is not a secret.
- Put the core facts in text, early, on the homepage. If you claim two markets, write both languages. Do not launch Czech as a translated slogan.
- Mark the organisation, the offer, and the pages up with the schema that fits. Schema does not make you rank. It stops a machine having to guess.
- Use the same name, description, and location on the site, on Google Business Profile, and on Firmy.cz.
- Give each important page a heading hierarchy that would still make sense as an outline. If the outline is vague, the page is vague.
- Do not hide the offer in an image. Machines still read text more reliably than pictures of text.
What a 2–6 week build actually includes
We say we launch in two to six weeks, and that is true for a certain shape of project. It is not true for every project, and pretending otherwise is how a studio burns the first month on a scope it never wrote down.
A two-to-three week build is a landing page, or a very small marketing site, when the offer is already clear and the raw material exists: copy or at least a brief, a point of view on the brand, images that are not "we will shoot them later." You get a designed first viewport, a short set of sections that earn their place, performance and structure built in, and a page that can be found for the thing it actually is.
A four-to-six week build is a proper marketing site. A handful of pages, not a thirty-page brochure. English and Czech done properly if both are in scope. Schema, a sitemap, the unglamorous redirects if you are replacing something. A design system small enough to keep consistent and large enough that the next page does not require a new invention. Hosting at the edge. Analytics that do not undo the thing you just made fast.
What that window does not include: inventing the company. A brand from a blank page plus a full site is two projects, and we will say so. A custom application with accounts, billing, and a CMS that can do everything is not a six-week marketing build. Waiting three weeks for copy, migrating a decade of posts, and rebuilding every integration are the usual reasons a six-week project becomes a twelve-week one. The honest version of "fast" is a tight scope and a client who can decide.
If you already have a site, the question is often rebuild versus a pass. Sometimes the stack is the problem. Sometimes the first viewport and the path to contact would move more than a new theme. We would rather tell you which than sell you the larger one by default.
If you want a straight read
If this sounds like the site you meant to have, and not quite the one you shipped, that is what a Website Review is for. We will look at the first viewport, the field performance, and whether a crawler or an assistant can tell what you are. Then we will tell you whether you need a two-week pass or a six-week build, and we will not dress a screenshot up as the answer.