Core Web Vitals and Latency: Do Faster Pages Get More AI Citations?

Core Web Vitals and Latency: Do Faster Pages Get More Artificial Intelligence Citations?

Introduction

A fast website is easier for people to use. It may also be easier for search engines and artificial intelligence systems to fetch, render, and understand.

But an important distinction is often missed:

A faster page may improve crawling and content availability. That does not mean speed alone causes an artificial intelligence system to cite the page.

As of August 2, 2026, Google states that stable server response times and lower latency can increase a site’s crawl capacity. Google also states that its artificial intelligence search features use the same basic search and indexing systems as traditional search and do not require special artificial intelligence markup or speed optimizations. (developers.google.com)

This article presents an evidence-based testing plan rather than claiming that a completed experiment has already been run. No site, page set, server log, or citation dataset was provided. The goal is to define a controlled study that can measure:

1. Whether lower time to first byte increases crawling frequency.
2. Whether lower Largest Contentful Paint improves discovery or indexing.
3. Whether lower Cumulative Layout Shift affects crawling or artificial intelligence retrieval.
4. Whether performance improvements increase the rate at which pages are visibly cited by artificial intelligence search systems.

The Short Answer

Lower time to first byte can improve crawling under the right conditions

Google’s current crawl documentation says that its crawl capacity limit can increase when a site has stable or improving response times, including time to first byte. If response times rise, or if a site returns too many server errors or rate-limit responses, Google may reduce crawling. (developers.google.com)

However, faster response time does not guarantee more crawling. Crawl demand also depends on factors such as:

• How often the site changes.
• How popular the site and its pages are.
• Whether the content is useful and unique.
• How many duplicate or low-value URLs exist.
• Whether updated URLs are included in sitemaps.

This means lower latency should have the strongest effect on large, frequently updated, or server-constrained websites, not necessarily on a small site with limited new content.

Lower Largest Contentful Paint may help indirectly

Largest Contentful Paint measures when the main visible content appears for a user. Google also states that both server response time and the time required to render pages and embedded resources can affect crawling efficiency. (developers.google.com)

The likely relationship is indirect:

Lower latency → faster resource delivery → more efficient rendering or fetching → fewer crawl timeouts or incomplete fetches.

The effect should be strongest when important content depends on:

• Slow JavaScript.
• Large images.
• Render-blocking stylesheets.
• Client-side rendering.
• Heavy embedded resources.

A fast Largest Contentful Paint score by itself is not likely to be a direct artificial intelligence citation signal.

Lower Cumulative Layout Shift probably has little direct crawling effect

Cumulative Layout Shift measures unexpected movement of visible content. It is mainly a user experience metric. Common causes include images without dimensions, dynamically inserted advertisements, embedded content, and web fonts. (web.dev)

A crawler does not experience a layout shift in the same way a human visitor does. Therefore, a direct relationship between lower Cumulative Layout Shift and more crawling is unlikely.

There may be an indirect relationship when a high layout shift is caused by:

• Content inserted late by JavaScript.
• Important text hidden until scripts run.
• Images or embeds that delay page construction.
• Unstable templates that produce different content during different fetches.

In those cases, the real problem is not the layout shift score. The real problem is that the page may be difficult to process or may expose important content too late.

Faster pages are not automatically cited more often

Google says pages appearing in artificial intelligence features must first be indexed and eligible to appear in normal search results with a snippet. Google also says there are no additional technical requirements or special artificial intelligence optimizations for its artificial intelligence overviews and artificial intelligence mode. (developers.google.com)

OpenAI similarly states that ChatGPT search rankings depend on multiple factors and that allowing its search crawler, OAI-SearchBot, is important for inclusion. It does not state that lower Core Web Vitals directly increase citation probability. (help.openai.com)

This suggests a four-stage model:

1. Discovery — Does the system learn that the URL exists?
2. Fetching and processing — Can the system retrieve and understand the page?
3. Indexing and retrieval — Is the page selected for a particular query?
4. Citation selection — Is the page shown as a visible source in the answer?

Page speed may affect the first two stages. It is not established as a direct cause of the fourth stage.

Recent research also shows that artificial intelligence systems may read many relevant pages but cite only some of them. In other words, retrieval and citation are separate events. (cambridge.org)

What Should Be Tested?

The study should test two different questions rather than treating “artificial intelligence visibility” as one metric.

Question 1: Does performance affect crawling?

Primary outcomes:

• Time from publication to first crawler request.
• Number of crawler requests per page per day.
• Time between successful recrawls.
• Number of pages crawled per 1,000 published pages.
• Percentage of successful fetches.
• Rate of server errors and rate-limit responses.
• Time from publication to indexing.

Question 2: Does performance affect citation selection?

Primary outcomes:

• Percentage of tested queries that produce a visible citation.
• Citation rate per eligible page.
• Citation share within a query.
• Percentage of retrieved pages that become visible citations.
• Citation persistence over time.
• Citation rate by artificial intelligence system.

These outcomes must be separated by provider. A Google artificial intelligence overview, ChatGPT search result, Microsoft Copilot answer, Perplexity answer, and Claude search response may use different indexes, crawlers, ranking systems, and refresh schedules.

Experimental Design

1. Build a controlled page set

Use a page set large enough to produce meaningful crawler and citation data.

A practical starting design would include:

• 240 to 800 pages.
• At least 20 pages per page template.
• Three to five content categories.
• A mixture of evergreen and regularly updated pages.
• Equal numbers of pages in each treatment group.

Each page should have:

• Similar HTML structure.
• Similar content length.
• The same publishing system.
• The same internal linking pattern.
• The same canonical rules.
• The same sitemap treatment.
• The same robots.txt permissions.
• A unique, useful topic.

Do not create hundreds of thin or near-duplicate pages only for the experiment. Google’s guidance warns that duplicate and low-value URLs can waste crawl resources and reduce the efficiency of a site. (developers.google.com)

A matched-pair design is useful. For example, pair pages with similar:

• Content length.
• Topic demand.
• Update frequency.
• Internal link count.
• External link count.
• Historical traffic.
• Search ranking position.

Then place one page from each pair in the control group and the other in a treatment group.

2. Use a factorial treatment design

The main performance treatments should be tested independently and together.

This creates a controlled experiment for the three requested optimizations:

• HTTP/3.
• Content delivery network edge caching.
• Image compression.

The layout stability treatment is necessary because the first three optimizations do not reliably isolate Cumulative Layout Shift. Image compression may lower Largest Contentful Paint without changing layout stability at all.

Why HTTP/3 needs its own measurement

HTTP/3 uses the QUIC transport protocol and provides independent streams, which can avoid transport-level head-of-line blocking found in HTTP/2 over TCP. Its benefits depend on whether the client or crawler actually negotiates HTTP/3. (rfc-editor.org)

Therefore, record the negotiated protocol for every request:

• HTTP/1.1.
• HTTP/2.
• HTTP/3.

Do not assume that enabling HTTP/3 means every crawler uses it. If Googlebot, OAI-SearchBot, or another crawler continues to use HTTP/2, HTTP/3 cannot affect that crawler’s requests.

Why edge caching should be tested carefully

A content delivery network can reduce time to first byte by serving content closer to the requester. It can also reduce the number of requests reaching the origin server. (web.dev)

Test at least three cache states:

1. Cold cache — The edge must contact the origin.
2. Warm cache — The edge serves the page without contacting the origin.
3. Revalidated cache — The edge or crawler uses an ETag or Last-Modified value and receives a 304 Not Modified response.

Google specifically recommends efficient HTTP caching and supports the use of 304 Not Modified responses to reduce unnecessary processing and bandwidth. (developers.google.com)

Do not allow caching to serve stale or incorrect content to crawlers. Record:

• Cache hit or miss.
• Cache age.
• Edge location.
• Origin response time.
• Content version.
• Status code.
• Validation headers.

Why image compression should be tied to Largest Contentful Paint

WebP and AVIF generally provide better compression than older image formats. Smaller images can reduce transfer time and may improve Largest Contentful Paint when the image is the Largest Contentful Paint element. (web.dev)

The test should use:

• The same image dimensions.
• The same visual quality target.
• Responsive srcset images.
• A modern format with a suitable fallback.
• Explicit width and height values.
• No lazy loading for the Largest Contentful Paint image.
• An image URL visible in the initial HTML.

Image compression alone may not improve Largest Contentful Paint if the real delay comes from JavaScript or late resource discovery. Google’s performance guidance notes that reducing image download time can simply shift the delay to another part of the page if the Largest Contentful Paint element is revealed late. (web.dev)

3. Run the test long enough

A short test may miss the effects of crawl scheduling and index refresh.

A practical design is:

• Two weeks of baseline measurement.
• Six to twelve weeks of treatment measurement.
• A final reversal or crossover period if possible.

For a crossover test, switch the treatments between matched page groups. If the performance effect disappears when the treatment is removed, the result is stronger than a simple before-and-after comparison.

Core Web Vitals field data should be evaluated over a suitable period. The Chrome User Experience Report uses a rolling 28-day aggregation, so it is not designed to show instant changes after a deployment. (developer.chrome.com)

4. Measure the complete crawler population

Do not treat all automated traffic as one group.

At minimum, separate:

Search crawlers

• Googlebot.
• Bingbot.

Artificial intelligence search crawlers

• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.

User-requested fetchers

• Perplexity-User.
• Claude-User.
• ChatGPT user fetchers where identifiable.

Training crawlers

• GPTBot.
• ClaudeBot.
• Google-Extended controls.

Training crawlers should not be used as a proxy for artificial intelligence search citations. Anthropic, OpenAI, and Google distinguish between crawlers used for training, search, or user-requested retrieval. Google also states that Google-Extended does not affect Google Search inclusion or ranking. (help.openai.com)

Perplexity similarly distinguishes between PerplexityBot, which supports search indexing, and Perplexity-User, which may retrieve a page in response to a user request. (docs.perplexity.ai)

Verify crawler identity using published IP ranges or reverse DNS where the provider supports it. User-agent strings can be copied by unrelated crawlers. Google specifically warns that Googlebot user-agent strings can be spoofed. (developers.google.com)

Metrics to Collect

Performance metrics

Collect both laboratory and real-user data:

• Time to first byte.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Total page weight.
• Initial HTML size.
• Image transfer size.
• Number of requests.
• Time spent in server processing.
• Time spent waiting for the Largest Contentful Paint resource.
• HTTP protocol.
• Cache status.

Google recommends a rough time to first byte target of 800 milliseconds or less, but time to first byte is not itself a Core Web Vital. (web.dev)

The current Core Web Vitals “good” thresholds at the 75th percentile are:

• Largest Contentful Paint: 2.5 seconds or less.
• Cumulative Layout Shift: 0.1 or less.
• Interaction to Next Paint: 200 milliseconds or less. (web.dev)

Crawl metrics

For every verified crawler request, record:

timestamp
url
user_agent
verified_bot
source_ip
http_protocol
status_code
response_time
time_to_first_byte
bytes_sent
cache_status
edge_location
etag
last_modified
referrer

Calculate:

crawl_requests_per_url_day
successful_fetch_rate
5xx_rate
429_rate
median_recrawl_interval
p75_recrawl_interval
publication_to_first_fetch
publication_to_first_index

Artificial intelligence citation metrics

Use a fixed set of queries across each platform. The query set should include:

• Direct factual questions.
• Comparison questions.
• “Best” or recommendation questions.
• Freshness-sensitive questions.
• Questions where the tested page is the strongest answer.
• Questions where the tested page is relevant but not dominant.

For each query, record:

engine
model or experience
timestamp
location
device
query
pages shown as sources
page citation order
whether the tested page was cited
whether the tested page was retrieved but not cited
answer text hash

Repeat queries because artificial intelligence answers can vary. Use a fixed schedule, such as three times per week, and record changes in the engine or model.

Microsoft Bing Webmaster Tools now provides an Artificial Intelligence Performance report showing cited pages, grounding queries, and citation trends across supported Microsoft artificial intelligence experiences. Microsoft warns that the data is aggregated, sampled, and observational; it cannot prove that a particular page change caused a citation change. (bing.com)

Google also began rolling out dedicated generative artificial intelligence performance reports in Search Console in June 2026. The reports were initially available to only a subset of websites, so access may vary. (developers.google.com)

Statistical Analysis

Crawling frequency

Use a mixed-effects count model, such as a negative binomial model:

crawl_count ~ treatment
            + time_to_first_byte
            + page_age
            + update_frequency
            + sitemap_status
            + internal_links
            + server_errors
            + (1 | page)
            + (1 | crawler)

The page and crawler effects matter because some pages naturally receive more attention than others, and different crawlers have different schedules.

Discovery and indexing

Use survival analysis for:

• Time from publication to first fetch.
• Time from publication to first index.
• Time from update to recrawl.

The key result is not simply whether a page was eventually crawled. It is whether the treatment reduced the time required for the page to be found and processed.

Artificial intelligence citation selection

Use a hierarchical logistic model:

citation_present ~ treatment
                 + time_to_first_byte
                 + largest_contentful_paint
                 + cumulative_layout_shift
                 + indexed_status
                 + search_visibility
                 + content_freshness
                 + page_authority
                 + (1 | query)
                 + (1 | engine)
                 + (1 | page)

Run two separate models:

1. Retrieval model — Was the page retrieved or shown as a candidate?
2. Citation model — If retrieved, was the page visibly cited?

This distinction is essential. A performance improvement that increases crawling but not retrieval is not an artificial intelligence citation effect. A performance improvement that increases retrieval but not citations suggests the page is being considered but loses during source selection.

Expected Findings

These are working hypotheses, not claimed experimental results.

Hypothesis 1: Time to first byte will have the clearest crawl effect

Expect a positive relationship between lower time to first byte and crawl capacity when:

• The site has many pages.
• Pages change often.
• The origin server is slow or overloaded.
• The site returns 5xx or 429 responses.
• The crawler spends significant time waiting for responses.

Expect little measurable effect on a small site with low crawl demand.

Hypothesis 2: Largest Contentful Paint will matter through rendering and resource delivery

Expect lower Largest Contentful Paint to help when:

• The page depends on browser rendering.
• Important content is behind JavaScript.
• Large images or stylesheets are required for indexing.
• The crawler fetches many page resources.
• The slower treatment produces timeouts or incomplete rendering.

Expect a weak relationship when the page’s important text is already present in the initial HTML.

Hypothesis 3: Cumulative Layout Shift will have little direct effect

Expect no meaningful direct relationship between Cumulative Layout Shift and crawl frequency or citation rate after controlling for page structure and JavaScript behavior.

If Cumulative Layout Shift appears to predict citations, investigate whether it is acting as a proxy for:

• Client-side rendering.
• Late content insertion.
• Unstable advertisements.
• Hidden or delayed text.
• Poorly structured HTML.

Hypothesis 4: Speed alone will not produce more artificial intelligence citations

The strongest predictors of citation selection are likely to remain:

• Relevance to the query.
• Content quality.
• Clear answers.
• Freshness.
• Authority and trust.
• Search index eligibility.
• Retrieval rank.
• Whether the page directly supports the claim being made.

Google’s guidance emphasizes useful, reliable, people-first content and says that artificial intelligence search features are grounded in the existing search and indexing systems. (developers.google.com)

A Performance Budget Tuned for Artificial Intelligence Retrieval

The following is a proposed operating budget. It is not a published artificial intelligence ranking formula.

Google’s current documentation says Googlebot fetches the first 2 megabytes of a supported file and fetches external scripts and stylesheets separately. It also recommends placing important metadata and structured data early in the HTML. (developers.google.com)

Implementation Recommendations

HTTP/3

Use HTTP/3 when it is supported by the hosting provider and content delivery network.

Measure:

• HTTP/3 negotiation rate.
• HTTP/2 fallback rate.
• Connection setup time.
• Time to first byte.
• Performance by geographic region.
• Performance by crawler.

Do not treat HTTP/3 as a guaranteed search or artificial intelligence optimization. It is a transport improvement that may help only clients that use it.

Content Delivery Network Edge Caching

For public, non-personalized pages:

• Set clear Cache-Control rules.
• Use long-lived caching for versioned static assets.
• Use short but useful caching for frequently updated HTML.
• Avoid cache fragmentation from unnecessary query parameters.
• Preserve canonical URLs.
• Support ETag and Last-Modified.
• Test cold, warm, and revalidated cache states.
• Confirm that crawler requests receive the same important content as human requests.

A content delivery network should reduce latency without creating stale, inconsistent, or bot-specific page versions.

Image Compression

For images:

• Use AVIF or WebP when visual quality is acceptable.
• Provide responsive image sizes.
• Do not serve a desktop-sized image to a small mobile screen.
• Do not lazy-load the Largest Contentful Paint image.
• Include image dimensions.
• Place the Largest Contentful Paint image in the initial HTML.
• Use fetchpriority="high" only when appropriate.
• Keep important explanations in text rather than embedding them only inside images.

Image compression is most valuable when the image is the Largest Contentful Paint element. It will not fix a page whose main delay comes from server rendering or JavaScript execution. (web.dev)

Layout Stability

To lower Cumulative Layout Shift:

• Set width and height attributes on images.
• Reserve space for advertisements.
• Reserve space for embedded video and social content.
• Avoid inserting banners above existing text.
• Use stable font loading strategies.
• Avoid replacing large blocks of server-rendered content after page load.

These changes improve the user experience even if they have no measurable effect on crawling or citations. (web.dev)

Tooling and Monitoring

Performance tools

Use:

• Chrome User Experience Report for real-user Core Web Vitals.
• Chrome User Experience Report application programming interface for automated field data collection.
• PageSpeed Insights for laboratory audits and field data.
• Lighthouse for repeatable laboratory tests.
• Lighthouse Continuous Integration for pull-request performance budgets.
• WebPageTest for multi-location tests, cache states, and protocol comparisons.
• Chrome DevTools for Largest Contentful Paint and layout shift debugging.
• The web-vitals JavaScript library for real-user monitoring.

The Chrome User Experience Report application programming interface provides page-level and origin-level aggregated field data, including Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint, and experimental time to first byte. (developer.chrome.com)

Lighthouse Continuous Integration can run performance checks on every code change and fail builds when budgets are exceeded. (github.com)

Crawler monitoring

Use server logs, edge logs, and a small set of synthetic probes.

Example probe:

curl --http3 -sS -o /dev/null -D - \
  -w 'status=%{http_code}\nhttp_version=%{http_version}\nnamelookup=%{time_namelookup}\nconnect=%{time_connect}\nstarttransfer=%{time_starttransfer}\ntotal=%{time_total}\nsize=%{size_download}\n' \
  -A 'Mozilla/5.0 (compatible; OAI-SearchBot/1.0)' \
  https://example.com/page

Run the same test with:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• A normal browser user-agent.

The test should verify:

• Status code.
• Robots permission.
• Response headers.
• HTML content.
• HTTP version.
• Cache state.
• Response time.
• Whether important text is present without JavaScript.

Search and indexing monitoring

Use:

• Google Search Console crawl statistics.
• Google Search Console page indexing reports.
• Google Search Console URL Inspection.
• Google Search Console sitemap data.
• Google Search Console generative artificial intelligence reports when available.
• Bing Webmaster Tools crawl requests and indexed pages.
• Bing Webmaster Tools Artificial Intelligence Performance.
• Daily sitemap and lastmod checks.

The Search Console application programming interface can retrieve performance data by page, query, date, device, and search appearance, subject to its data limits. (developers.google.com)

Citation monitoring

Create a citation panel containing 50 to 200 stable queries per topic. Run the panel on a fixed schedule and record:

• Whether the platform searched.
• Which sources appeared.
• Whether the tested URL was cited.
• Citation order.
• The answer date and time.
• Whether the page changed.
• Whether the model or search experience changed.

Do not compare citation counts from different systems as if they were equivalent. Microsoft states that citation activity is not a ranking score, authority score, traffic measure, or quality score. (bing.com)

Alerting Rules

Create alerts for:

• Time to first byte rising by more than 25 percent.
• Largest Contentful Paint moving above 2.5 seconds at the 75th percentile.
• Cumulative Layout Shift moving above 0.1.
• A sustained increase in 5xx or 429 responses.
• A drop in crawler success rate.
• A robots.txt change.
• A sitemap error.
• A sudden fall in indexed pages.
• A sudden fall in artificial intelligence citations across several platforms.
• A change in citation volume that affects only one platform.

A citation decline affecting one platform may be caused by a model, index, query, or product change rather than a page performance issue. Microsoft explicitly warns that citation trends are observational and can change because of content updates, user demand, and system or model changes. (bing.com)

Final Conclusion

The most defensible conclusion is:

Faster pages can improve crawl efficiency, especially when server latency, resource size, errors, or rendering delays are limiting factors. But there is currently no strong evidence that lower Core Web Vitals directly cause artificial intelligence systems to select a page as a citation.

The expected causal chain is:

Lower latency
→ better server capacity
→ fewer failed or delayed fetches
→ faster discovery and processing
→ improved chance of being indexed and retrieved
→ possible increase in citations

The final step remains uncertain because citation selection depends on relevance, quality, freshness, authority, query intent, retrieval rank, and the behavior of each artificial intelligence system.

For most websites, the correct performance strategy is therefore not “optimize for artificial intelligence citations” in isolation. It is:

1. Keep important content available in the initial HTML.
2. Keep time to first byte stable.
3. Use edge caching for public content.
4. Compress and prioritize important images.
5. Prevent layout shifts.
6. Return reliable status codes.
7. Keep sitemaps and internal links current.
8. Allow the correct search crawlers.
9. Measure crawling, indexing, retrieval, and citation as separate stages.

That approach produces a faster website for people, a healthier site for search crawlers, and a testable foundation for understanding artificial intelligence visibility.