Why after 20 years of web development I still put performance first
It started with a 56k modem
I built my first serious website around 2004. The audience: people with a 56k modem. Every kilobyte counted. I optimized images until they were barely recognizable, wrote CSS by hand, and avoided JavaScript where I could.
Not because I was a perfectionist. Okay, a little bit. But mostly because I knew: if the page takes too long to load, the visitor is gone. It was that simple.
That principle has not left me in twenty years. The technology changed. Modems gave way to ADSL, ADSL to fiber. Visitors became impatient in a different way: not because their connection was too slow, but because the competition is one click away.
The benchmark for "fast enough" shifts constantly. But the lesson? Exactly the same. Performance is not a luxury. It is a basic requirement.
In 2004, 56k was the standard. In 2012 we measured performance in seconds. In 2018 in milliseconds. In 2026, an AI crawler judges your server within the first few hundred milliseconds and decides whether to continue or give up. The bar shifts. The lesson does not.
Twenty years of client projects, one constant
At Kobalt I have built and optimized dozens of websites. From small local businesses to mid-size B2B companies. The projects vary enormously, but the patterns? Strikingly consistent.
Every time a client complains about disappointing organic traffic, I ask the same first question: how fast does your website load?
Not the second or third question. The first.
Because in nine out of ten cases, performance is part of the problem. A slow website ranks worse, converts worse and makes a worse impression. I once spent an entire evening shaving 12 milliseconds off a TTFB. My wife was less impressed than I was. But the client noticed the difference.
- A website that loads in 0.8 seconds converts on average twice as well as a website that loads in 3 seconds.
- Google gives fast websites a direct preference through Core Web Vitals.
- Mobile users abandon a page after three seconds of loading in more than 50% of cases.
- AI crawlers with strict timeouts index slow websites less completely.
The perfect storm: performance and AI
What genuinely fascinates me about the current development around AI and AEO is this: everything I have advocated for over the past twenty years now also turns out to be essential for AI visibility.
Performance was always a persuasion conversation. I could demonstrate that a faster website delivers better results. But the direct cause and effect was sometimes hard to quantify.
Now it is different.
Now I can say: a slow website is literally skipped by AI crawlers. A site on shared hosting with a TTFB of 2 seconds is indexed less completely by GPTBot than a VPS with a TTFB of 150ms. That is not theory. That is measurable, demonstrable, and directly linked to missed citations in ChatGPT, Perplexity and Google AI Overviews.
I notice I am getting a bit excited here. Let me rewind.
The point is: the arguments for performance have always been good. But now they are irrefutable. AI crawlers have made the persuasion conversation unnecessary.
A B2B e-commerce client invested in a complete performance optimization: new hosting, HTTP/2, WebP images, lazy loading, better caching. The AEO scan afterwards showed a significant improvement in the technical component. Not because we had done anything to the content. Because the website had simply become faster.
My advice: start at the foundation
If you are starting with AEO today, do not be seduced by the sexy topics. llms.txt is nice. Schema.org is important. But if your website is on a slow shared server with a TTFB of 1.5 seconds and an unoptimized database? Then the rest is treating symptoms.
Start at the foundation. Make sure your website is fast. Not "fast enough for a human", but fast for an automated crawler with a strict timeout.
- Measure first. GTmetrix, WebPageTest, Google PageSpeed Insights. Know your baseline.
- Fix the server. Shared hosting? Consider migrating to VPS or managed hosting.
- Optimize the critical loading paths. CSS inline for above-the-fold, JS deferred or async, images as WebP or AVIF.
- Enable HTTP/2 on your server or via a CDN. Evaluate HTTP/3.
- Measure again. Confirm that the improvements are measurable in TTFB and Core Web Vitals.
And only then: llms.txt, Schema.org, E-E-A-T. In that order.
It is like birdwatching: you can have the most expensive binoculars, but if you cannot sit still, you see nothing. Performance is that sitting still. It is the discipline that makes everything else possible.
Frequently asked questions
Is performance really always the first priority?
It depends on how bad the performance is. TTFB below 400ms and green Core Web Vitals? Then performance is not your first concern. But in practice, the majority of websites I work with have a performance problem that undermines all other optimizations. Always measure first.
How much improvement can I expect?
That varies enormously. Websites starting from a Lighthouse score of 40 and a TTFB of 2 seconds can reach scores of 85 to 95 and TTFBs below 200ms after optimization. The effect on AI readiness is proportional: more pages are fully crawled, more content is indexed, more citations follow. Clients who migrate from shared to VPS hosting see this most clearly.
How do I maintain performance over time?
Performance degrades by default. Every new plugin, every new script, every unoptimized image adds weight. The solution: monitoring. Set up a weekly automated test via SpeedCurve, Calibre or the free PageSpeed Insights API. Set a threshold (TTFB above 500ms) and get alerted when it is exceeded. Treat performance as a metric, not a one-time project.
After twenty years of web development, my conclusion is simple: performance is never the only thing that matters, but it is always the first question. Everything you build on top of it stands or falls with the speed of the foundation.
How does your website score on AI readiness?
Get your AEO score within 30 seconds and discover what you can improve.
