Why Fast, Hand-Coded Sites Get Cited More by Google and AI (With San Diego Numbers, 2026)
By Alexey Chasin · Updated September 25, 2026 · 8 min read
Fast pages get cited more for three reasons. Google uses page experience and Core Web Vitals to break ties between pages of similar relevance. Crawlers, including GPTBot, ClaudeBot and PerplexityBot, fetch more pages from a fast site in the same crawl budget and give up on slow ones. And AI engines that assemble an answer in seconds read the pages that return in milliseconds, in full, and skip the ones that time out. In our September 2026 audit of 76 San Diego business homepages, 42% loaded 20 or more script files, WordPress sites loaded a median of 23, and 29% took over a second to send the first byte. A hand-coded site sends one to three scripts and responds in under 200 milliseconds, which is why every page we build is measured before launch.
Three ways speed becomes citations
1. The ranking tie-breaker
Google's page experience signals, with Core Web Vitals at the center, decide between pages that answer a query equally well. For a local business competing with five similar sites for 'roofer Escondido', the one that loads in under a second on a phone wins the tie. Since AI Overviews cite pages that already rank, the tie-breaker is also a citation-breaker.
2. Crawl budget and completeness
Every crawler has a time budget per site. A site that returns pages in 200 milliseconds gets more pages crawled, more often, and each one read to the end. A site that takes three seconds per page gets fewer pages crawled and some abandoned mid-read. A 30-page local site on a slow host can have half its pages stale in Google's index and unknown to the AI crawlers, while a fast site of the same size is fully indexed and current.
3. Real-time reading by AI engines
ChatGPT search, Perplexity and Google AI Mode fetch and read pages live while composing an answer, within a few seconds. A page that returns fast and renders its content in the HTML is read in full. A page that takes five seconds, or that only shows content after JavaScript runs, is read partially or not at all. Speed and server-rendered content are what make a page available to be cited at the moment it matters.
What slows local sites down, from the data
| Finding | Result |
|---|---|
| Median external script files | 16.5; 42% load 20 or more |
| WordPress sites, median scripts | 23 (Duda sites: 8; custom and Next.js: single digits) |
| Most scripts on one homepage | 67 |
| Median HTML size | 243 KB; 36% over 300 KB; largest 905 KB |
| Response time over one second | 29% of sites; slowest 6.7 seconds |
| Slowest trade by median response | Plumbing, 2.2 seconds |
The pattern is consistent: a theme, a page builder, a slider, a chat widget, a form plugin, three analytics tags, a font loader and a cookie banner, each adding scripts nobody removed. None of it is necessary for a business site, and all of it runs before the customer sees the phone number.
What a fast build looks like
- Server-rendered HTML with the content in it, so crawlers and AI engines read the page without running JavaScript.
- One to three script files, for the things that need them: a form, a load-time display, an image gallery.
- Images sized to the layout and served in WebP or AVIF, lazy-loaded below the fold.
- System fonts or one self-hosted font, no font-loading script.
- Static pages served from a global edge network, so first byte is under 200 milliseconds from anywhere in California.
- No page builder, no theme, no plugin updates, nothing to slow down over time.
This site is the demonstration: 149 pages, first byte in a fraction of a second, Lighthouse 99 to 100 on performance, accessibility, best practices and SEO, measured on the homepage before every release. The load-time counter on the homepage is the visitor's own browser measuring it.
What to do with an existing slow site
Run the homepage through PageSpeed Insights and count the scripts in the page source. Under 10 scripts and a mobile score above 80: keep the site and remove what you can. Over 20 scripts or a score under 50: the site will not get fast by removing plugins, because the theme and builder are the weight, and a rebuild that keeps the URLs and content is the honest answer. Our audit put 42% of local sites in the second group.
Speed is not a design choice. It is the difference between a page that is read and cited and one that is skipped, by Google, by crawlers and by the AI engine composing an answer while the customer waits.