Core Web Vitals un latentums: Vai ātrākas lapas iegūst vairāk AI atsaucību?

Core Web Vitals un latentums: Vai ātrākas lapas iegūst vairāk mākslīgā intelekta atsaucību?

Ievads

Ātra vietne ir vieglāk lietojama cilvēkiem. Tā var būt arī vieglāk pieejama, renderējama un saprotama meklētājprogrammām un mākslīgā intelekta sistēmām.

Tomēr bieži tiek palaista garām svarīga atšķirība:

Ātrāka lapa var uzlabot pārlūkošanu un satura pieejamību. Tas nenozīmē, ka ātrums pats par sevi liek mākslīgā intelekta sistēmai atsaukties uz lapu.

No 2026. gada 2. augusta Google norāda, ka stabili servera atbildes laiki un zemāks latentums var palielināt vietnes pārlūkošanas jaudu. Google arī norāda, ka tās mākslīgā intelekta meklēšanas funkcijas izmanto tās pašas pamata meklēšanas un indeksēšanas sistēmas kā tradicionālā meklēšana, un tām nav nepieciešamas īpašas mākslīgā intelekta iezīmēšanas vai ātruma optimizācijas. (developers.google.com)

Šis raksts piedāvā uz pierādījumiem balstītu testēšanas plānu, nevis apgalvo, ka pabeigts eksperiments jau ir veikts. Netika sniegta neviena vietne, lapu kopa, servera žurnāls vai atsaucību datu kopa. Mērķis ir definēt kontrolētu pētījumu, kas var izmērīt:

1. Vai zemāks laiks līdz pirmajam baitam palielina pārlūkošanas biežumu.
2. Vai zemāks Largest Contentful Paint uzlabo atklāšanu vai indeksēšanu.
3. Vai zemāks Cumulative Layout Shift ietekmē pārlūkošanu vai mākslīgā intelekta datu izguvi.
4. Vai veiktspējas uzlabojumi palielina ātrumu, ar kādu lapas ir redzami citētas mākslīgā intelekta meklēšanas sistēmās.

Īsā atbilde

Zemāks laiks līdz pirmajam baitam var uzlabot pārlūkošanu pareizos apstākļos

Google pašreizējā pārlūkošanas dokumentācijā teikts, ka tās pārlūkošanas jaudas ierobežojums var palielināties, ja vietnei ir stabili vai uzlabojoši atbildes laiki, tostarp laiks līdz pirmajam baitam. Ja atbildes laiki palielinās, vai ja vietne atgriež pārāk daudz servera kļūdu vai ātruma ierobežojumu atbildes, Google var samazināt pārlūkošanu. (developers.google.com)

Tomēr ātrāks atbildes laiks negarantē biežāku pārlūkošanu. Pārlūkošanas pieprasījums ir atkarīgs arī no tādiem faktoriem kā:

• Cik bieži vietne mainās.
• Cik populāra ir vietne un tās lapas.
• Vai saturs ir noderīgs un unikāls.
• Cik daudz dublikātu vai zemas vērtības URL pastāv.
• Vai atjauninātie URL ir iekļauti vietņu kartēs.

Tas nozīmē, ka zemākam latentumam vajadzētu būt visspēcīgākajai ietekmei uz lielām, bieži atjauninātām vai servera ierobežotām vietnēm, nevis obligāti uz mazu vietni ar ierobežotu jaunu saturu.

Zemāks Largest Contentful Paint var palīdzēt netieši

Largest Contentful Paint mēra, kad galvenais redzamais saturs parādās lietotājam. Google arī norāda, ka gan servera atbildes laiks, gan lapu un iegulto resursu renderēšanai nepieciešamais laiks var ietekmēt pārlūkošanas efektivitāti. (developers.google.com)

Iespējamā saistība ir netieša:

Zemāks latentums → ātrāka resursu piegāde → efektīvāka renderēšana vai ielāde → mazāk pārlūkošanas taimautu vai nepilnīgu ielādes.

Efektam vajadzētu būt visspēcīgākajam, ja svarīgs saturs ir atkarīgs no:

• Lēna JavaScript.
• Lieli attēli.
• Renderēšanu bloķējošas stila lapas.
• Klienta puses renderēšana.
• Smagi iegultie resursi.

Ātrs Largest Contentful Paint rādītājs pats par sevi, visticamāk, nebūs tiešs mākslīgā intelekta atsaucības signāls.

Zemākam Cumulative Layout Shift, visticamāk, ir maza tieša pārlūkošanas ietekme

Cumulative Layout Shift mēra redzamā satura negaidītu kustību. Tas galvenokārt ir lietotāja pieredzes rādītājs. Bieži cēloņi ir attēli bez izmēriem, dinamiski ievietotas reklāmas, iegultais saturs un tīmekļa fonti. (web.dev)

Pārlūks nesaskaras ar izkārtojuma nobīdi tādā pašā veidā kā cilvēka apmeklētājs. Tāpēc tieša saistība starp zemāku Cumulative Layout Shift un biežāku pārlūkošanu ir maz ticama.

Var pastāvēt netieša saistība, ja liels izkārtojuma nobīde ir izraisīta ar:

• Satura, kas vēlu ievietots ar JavaScript palīdzību.
• Svarīga teksta, kas paslēpts, līdz tiek izpildīti skripti.
• Attēlu vai iegulšanas elementu, kas aizkavē lapas izveidi.
• Nestabilām veidnēm, kas dažādu ielādes laikā rada atšķirīgu saturu.

Šādos gadījumos patiesā problēma nav izkārtojuma nobīdes rādītājs. Patiesā problēma ir tā, ka lapa var būt grūti apstrādājama vai var atklāt svarīgu saturu pārāk vēlu.

Ātrākas lapas netiek automātiski citētas biežāk

Google norāda, ka lapas, kas parādās mākslīgā intelekta funkcijās, vispirms ir jāindeksē un tām jābūt piemērotām parādīties parastajos meklēšanas rezultātos ar fragmentu. Google arī norāda, ka nav papildu tehnisku prasību vai īpašu mākslīgā intelekta optimizāciju tās mākslīgā intelekta pārskatiem un mākslīgā intelekta režīmam. (developers.google.com)

OpenAI līdzīgi norāda, ka ChatGPT meklēšanas ranžējumi ir atkarīgi no vairākiem faktoriem un ka tās meklēšanas pārlūka OAI-SearchBot atļaušana ir svarīga iekļaušanai. Tas nenorāda, ka zemāki Core Web Vitals tieši palielina atsaucību varbūtību. (help.openai.com)

Tas liecina par četru posmu modeli:

1. Atklāšana — Vai sistēma uzzina, ka URL pastāv?
2. Ielāde un apstrāde — Vai sistēma var izgūt un saprast lapu?
3. Indeksēšana un izguve — Vai lapa tiek atlasīta konkrētam vaicājumam?
4. Atsaucības atlase — Vai lapa tiek parādīta kā redzams avots atbildē?

Lapas ātrums var ietekmēt pirmos divus posmus. Tas nav noteikts kā tiešs ceturtā posma cēlonis.

Nesenā izpēte arī liecina, ka mākslīgā intelekta sistēmas var lasīt daudzas atbilstošas lapas, bet citēt tikai dažas no tām. Citiem vārdiem sakot, izguve un atsaucība ir atsevišķi notikumi. (cambridge.org)

Kas būtu jāpārbauda?

Pētījumam vajadzētu pārbaudīt divus dažādus jautājumus, nevis uzskatīt “mākslīgā intelekta redzamību” par vienu rādītāju.

Jautājums 1: Vai veiktspēja ietekmē pārlūkošanu?

Galvenie rezultāti:

• Laiks no publicēšanas līdz pirmajam pārlūka pieprasījumam.
• Pārlūka pieprasījumu skaits uz lapu dienā.
• Laiks starp veiksmīgām atkārtotām pārlūkošanām.
• Pārlūkoto lapu skaits uz 1000 publicētām lapām.
• Veiksmīgu ielādes procentuālais daudzums.
• Servera kļūdu un ātruma ierobežojumu atbildes rādītājs.
• Laiks no publicēšanas līdz indeksēšanai.

Jautājums 2: Vai veiktspēja ietekmē atsaucības atlasi?

Galvenie rezultāti:

• Pārbaudīto vaicājumu procentuālais daudzums, kas rada redzamu atsaucību.
• Atsaucības rādītājs uz katru piemērotu lapu.
• Atsaucības daļa vaicājumā.
• Izgūto lapu procentuālais daudzums, kas kļūst par redzamām atsaucībām.
• Atsaucības noturība laika gaitā.
• Atsaucības rādītājs pēc mākslīgā intelekta sistēmas.

Šie rezultāti jāatdala pēc pakalpojumu sniedzēja. Google mākslīgā intelekta pārskats, ChatGPT meklēšanas rezultāts, Microsoft Copilot atbilde, Perplexity atbilde un Claude meklēšanas atbilde var izmantot dažādus indeksus, pārlūkus, ranžēšanas sistēmas un atjaunināšanas grafikus.

Eksperimentālais dizains

1. Izveidojiet kontrolētu lapu kopu

Izmantojiet lapu kopu, kas ir pietiekami liela, lai iegūtu jēgpilnus pārlūka un atsaucību datus.

Praktisks sākotnējais dizains ietvertu:

• 240 līdz 800 lapas.
• Vismaz 20 lapas uz katru lapas veidni.
• Trīs līdz piecas satura kategorijas.
• Mūžzaļo un regulāri atjaunināto lapu sajaukums.
• Vienāds lapu skaits katrā apstrādes grupā.

Katrā lapā jābūt:

• Līdzīgai HTML struktūrai.
• Līdzīgam satura garumam.
• Tai pašai publicēšanas sistēmai.
• Tiem pašiem iekšējās saišu veidošanas modeļiem.
• Tiem pašiem kanoniskajiem noteikumiem.
• Tiem pašiem vietņu kartes apstrādes principiem.
• Tām pašām robots.txt atļaujām.
• Unikālai, noderīgai tēmai.

Neveidojiet simtiem plānu vai gandrīz dublētu lapu tikai eksperimentam. Google vadlīnijas brīdina, ka dublikātu un zemas vērtības URL var tērēt pārlūkošanas resursus un samazināt vietnes efektivitāti. (developers.google.com)

Saskaņotu pāru dizains ir noderīgs. Piemēram, savienojiet lapas ar līdzīgu:

• Satura garumu.
• Tēmas pieprasījumu.
• Atjaunināšanas biežumu.
• Iekšējo saišu skaitu.
• Ārējo saišu skaitu.
• Vēsturisko datplūsmu.
• Meklēšanas ranžējuma pozīciju.

Pēc tam novietojiet vienu lapu no katra pāra kontroles grupā un otru – apstrādes grupā.

2. Izmantojiet faktoriālo apstrādes dizainu

Galvenās veiktspējas apstrādes jāpārbauda neatkarīgi un kopā.

Tas rada kontrolētu eksperimentu trim pieprasītajām optimizācijām:

• HTTP/3.
• Satura piegādes tīkla malu kešatmiņa.
• Attēlu saspiešana.

Izkārtojuma stabilitātes apstrāde ir nepieciešama, jo pirmās trīs optimizācijas nevar droši izolēt Cumulative Layout Shift. Attēlu saspiešana var samazināt Largest Contentful Paint, nemainot izkārtojuma stabilitāti vispār.

Kāpēc HTTP/3 nepieciešams savs mērījums

HTTP/3 izmanto QUIC transporta protokolu un nodrošina neatkarīgas plūsmas, kas var novērst transporta līmeņa "head-of-line" bloķēšanu, kas atrodama HTTP/2 virs TCP. Tās ieguvumi ir atkarīgi no tā, vai klients vai pārlūks faktiski sarunājas ar HTTP/3. (rfc-editor.org)

Tāpēc katram pieprasījumam ierakstiet sarunāto protokolu:

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

Neuzskatiet, ka HTTP/3 iespējošana nozīmē, ka katrs pārlūks to izmanto. Ja Googlebot, OAI-SearchBot vai cits pārlūks turpina izmantot HTTP/2, HTTP/3 nevar ietekmēt šī pārlūka pieprasījumus.

Kāpēc malu kešatmiņa jāpārbauda uzmanīgi

Satura piegādes tīkls var samazināt laiku līdz pirmajam baitam, piegādājot saturu tuvāk pieprasītājam. Tas var arī samazināt pieprasījumu skaitu, kas sasniedz izcelsmes serveri. (web.dev)

Pārbaudiet vismaz trīs kešatmiņas stāvokļus:

1. Aukstā kešatmiņa — Malai jāsazinās ar izcelsmi.
2. Siltā kešatmiņa — Mala pasniedz lapu, nesazinoties ar izcelsmi.
3. Atkārtoti validētā kešatmiņa — Mala vai pārlūks izmanto ETag vai Last-Modified vērtību un saņem 304 Not Modified atbildi.

Google īpaši iesaka efektīvu HTTP kešatmiņas izmantošanu un atbalsta 304 Not Modified atbilžu izmantošanu, lai samazinātu nevajadzīgu apstrādi un joslas platumu. (developers.google.com)

Neļaujiet kešatmiņai pasniegt novecojušu vai nepareizu saturu pārlūkiem. Ierakstiet:

• Kešatmiņas trāpījums vai netrāpījums.
• Kešatmiņas vecums.
• Malu atrašanās vieta.
• Izcelsmes atbildes laiks.
• Satura versija.
• Statusa kods.
• Validācijas galvenes.

Kāpēc attēlu saspiešana jāsaista ar Largest Contentful Paint

WebP un AVIF parasti nodrošina labāku saspiešanu nekā vecāki attēlu formāti. Mazāki attēli var samazināt pārsūtīšanas laiku un var uzlabot Largest Contentful Paint, ja attēls ir Largest Contentful Paint elements. (web.dev)

Testam vajadzētu izmantot:

• Tos pašus attēla izmērus.
• To pašu vizuālās kvalitātes mērķi.
• Adaptīvus srcset attēlus.
• Modernu formātu ar piemērotu rezerves variantu.
• Eksplīcītās width un height vērtības.
• Bez "lazy loading" Largest Contentful Paint attēlam.
• Attēla URL, kas redzams sākotnējā HTML.

Attēlu saspiešana pati par sevi var neuzlabot Largest Contentful Paint, ja patiesā aizkave rodas no JavaScript vai vēlu atrasto resursu dēļ. Google veiktspējas vadlīnijas norāda, ka attēlu lejupielādes laika samazināšana var vienkārši pārvirzīt aizkavi uz citu lapas daļu, ja Largest Contentful Paint elements tiek atklāts vēlu. (web.dev)

3. Veiciet testu pietiekami ilgi

Īss tests var palaist garām pārlūkošanas grafika un indeksu atsvaidzināšanas ietekmi.

Praktisks dizains ir:

• Divas nedēļas pamatmērījumiem.
• Sešas līdz divpadsmit nedēļas apstrādes mērījumiem.
• Galīgais reversijas vai krustojuma periods, ja iespējams.

Krustojuma testā mainiet apstrādes starp saskaņotām lapu grupām. Ja veiktspējas efekts pazūd, kad apstrāde tiek noņemta, rezultāts ir spēcīgāks nekā vienkāršs pirms un pēc salīdzinājums.

Core Web Vitals lauka dati jānovērtē atbilstošā periodā. Chrome User Experience Report izmanto ritošu 28 dienu apkopojumu, tāpēc tas nav paredzēts, lai parādītu tūlītējas izmaiņas pēc izvietošanas. (developer.chrome.com)

4. Izmēriet pilnu pārlūku populāciju

Neapstrādājiet visu automatizēto datplūsmu kā vienu grupu.

Vismaz atdaliet:

Meklēšanas pārlūki

• Googlebot.
• Bingbot.

Mākslīgā intelekta meklēšanas pārlūki

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

Lietotāja pieprasītie ielādētāji

• Perplexity-User.
• Claude-User.
• ChatGPT lietotāju ielādētāji, kur tos var identificēt.

Apmācības pārlūki

• GPTBot.
• ClaudeBot.
• Google-Extended vadības ierīces.

Apmācības pārlūki nevajadzētu izmantot kā mākslīgā intelekta meklēšanas atsaucību starpniekus. Anthropic, OpenAI un Google atšķir pārlūkus, kas tiek izmantoti apmācībai, meklēšanai vai lietotāja pieprasītai izguvei. Google arī norāda, ka Google-Extended neietekmē Google meklēšanas iekļaušanu vai ranžēšanu. (help.openai.com)

Perplexity līdzīgi atšķir PerplexityBot, kas atbalsta meklēšanas indeksēšanu, un Perplexity-User, kas var izgūt lapu, atbildot uz lietotāja pieprasījumu. (docs.perplexity.ai)

Pārbaudiet pārlūka identitāti, izmantojot publicētos IP diapazonus vai reverso DNS, ja pakalpojumu sniedzējs to atbalsta. Lietotāja aģenta virknes var kopēt nesaistīti pārlūki. Google īpaši brīdina, ka Googlebot lietotāja aģenta virknes var viltot. (developers.google.com)

Savācamie rādītāji

Veiktspējas rādītāji

Apkopojiet gan laboratorijas, gan reālo lietotāju datus:

• Laiks līdz pirmajam baitam.
• First Contentful Paint.
• Largest Contentful Paint.
• Cumulative Layout Shift.
• Interaction to Next Paint.
• Kopējais lapas svars.
• Sākotnējā HTML lielums.
• Attēla pārsūtīšanas lielums.
• Pieprasījumu skaits.
• Laiks, kas pavadīts servera apstrādē.
• Laiks, kas pavadīts, gaidot Largest Contentful Paint resursu.
• HTTP protokols.
• Kešatmiņas statuss.

Google iesaka aptuvenu laika līdz pirmajam baitam mērķi 800 milisekundes vai mazāk, taču laiks līdz pirmajam baitam pats par sevi nav Core Web Vital. (web.dev)

Pašreizējie Core Web Vitals “labie” sliekšņi 75. procentilē ir:

• Largest Contentful Paint: 2,5 sekundes vai mazāk.
• Cumulative Layout Shift: 0,1 vai mazāk.
• Interaction to Next Paint: 200 milisekundes vai mazāk. (web.dev)

Pārlūkošanas rādītāji

Katram pārbaudītam pārlūka pieprasījumam ierakstiet:

text 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

Aprēķiniet:

text 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

Mākslīgā intelekta atsaucību rādītāji

Izmantojiet fiksētu vaicājumu kopu katrā platformā. Vaicājumu kopā jāiekļauj:

• Tieši faktu jautājumi.
• Salīdzinājuma jautājumi.
• “Labākais” vai ieteikumu jautājumi.
• Jautājumi, kas jūtīgi pret aktualitāti.
• Jautājumi, kuros pārbaudītā lapa ir spēcīgākā atbilde.
• Jautājumi, kuros pārbaudītā lapa ir atbilstoša, bet nav dominējoša.

Katram vaicājumam ierakstiet:

text 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

Atkārtojiet vaicājumus, jo mākslīgā intelekta atbildes var atšķirties. Izmantojiet fiksētu grafiku, piemēram, trīs reizes nedēļā, un ierakstiet izmaiņas dzinējā vai modelī.

Microsoft Bing Webmaster Tools tagad nodrošina mākslīgā intelekta veiktspējas pārskatu, kas parāda citētas lapas, pamatojuma vaicājumus un atsaucību tendences atbalstītajās Microsoft mākslīgā intelekta pieredzēs. Microsoft brīdina, ka dati ir apkopoti, atlasīti un novērojoši; tie nevar pierādīt, ka konkrēta lapas izmaiņa izraisīja atsaucības izmaiņas. (bing.com)

Google arī sāka ieviest īpašus ģeneratīvā mākslīgā intelekta veiktspējas pārskatus pakalpojumā Search Console 2026. gada jūnijā. Pārskati sākotnēji bija pieejami tikai daļai vietņu, tāpēc piekļuve var atšķirties. (developers.google.com)

Statistiskā analīze

Pārlūkošanas biežums

Izmantojiet jaukta efekta skaitīšanas modeli, piemēram, negatīvo binomiālo modeli:

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

Lapas un pārlūka efekti ir svarīgi, jo dažas lapas dabiski saņem vairāk uzmanības nekā citas, un dažādiem pārlūkiem ir atšķirīgi grafiki.

Atklāšana un indeksēšana

Izmantojiet izdzīvošanas analīzi:

• Laiks no publicēšanas līdz pirmajai ielādei.
• Laiks no publicēšanas līdz pirmajam indeksam.
• Laiks no atjaunināšanas līdz atkārtotai pārlūkošanai.

Galvenais rezultāts nav tikai tas, vai lapa galu galā tika pārlūkota. Tas ir, vai apstrāde samazināja laiku, kas nepieciešams, lai lapa tiktu atrasta un apstrādāta.

Mākslīgā intelekta atsaucību atlase

Izmantojiet hierarhisku loģistisko modeli:

text 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)

Izpildiet divus atsevišķus modeļus:

1. Izgūšanas modelis — Vai lapa tika izgūta vai parādīta kā kandidāts?
2. Atsaucības modelis — Ja izgūta, vai lapa tika redzami citēta?

Šī atšķirība ir būtiska. Veiktspējas uzlabojums, kas palielina pārlūkošanu, bet ne izguvi, nav mākslīgā intelekta atsaucības efekts. Veiktspējas uzlabojums, kas palielina izguvi, bet ne atsaucības, liecina, ka lapa tiek izskatīta, bet zaudē avotu atlases laikā.

Paredzamie secinājumi

Šīs ir darba hipotēzes, nevis apgalvoti eksperimentāli rezultāti.

Hipotēze 1: Laikam līdz pirmajam baitam būs visredzamākais pārlūkošanas efekts

Gaida pozitīvu saistību starp zemāku laiku līdz pirmajam baitam un pārlūkošanas jaudu, ja:

• Vietnei ir daudz lapu.
• Lapas bieži mainās.
• Izcelsmes serveris ir lēns vai pārslogots.
• Vietne atgriež 5xx vai 429 atbildes.
• Pārlūks pavada ievērojamu laiku, gaidot atbildes.

Gaida mazu mērāmu efektu uz mazām vietnēm ar zemu pārlūkošanas pieprasījumu.

Hipotēze 2: Largest Contentful Paint būs svarīgs renderēšanas un resursu piegādes dēļ

Gaida, ka zemāks Largest Contentful Paint palīdzēs, ja:

• Lapa ir atkarīga no pārlūkprogrammas renderēšanas.
• Svarīgs saturs ir aiz JavaScript.
• Indeksēšanai nepieciešami lieli attēli vai stila lapas.
• Pārlūks ielādē daudzus lapas resursus.
• Lēnāka apstrāde rada taimautus vai nepilnīgu renderēšanu.

Gaida vāju saistību, ja lapas svarīgais teksts jau ir sākotnējā HTML.

Hipotēze 3: Cumulative Layout Shift būs maza tieša ietekme

Pēc lapas struktūras un JavaScript uzvedības kontroles nav sagaidāma būtiska tieša saistība starp Cumulative Layout Shift un pārlūkošanas biežumu vai atsaucību biežumu.

Ja šķiet, ka Cumulative Layout Shift prognozē atsaucības, izpētiet, vai tas darbojas kā starpnieks:

• Klienta puses renderēšanai.
• Vēla satura ievietošana.
• Nestabilām reklāmām.
• Slēptam vai aizkavētam tekstam.
• Slikti strukturētam HTML.

Hipotēze 4: Ātrums pats par sevi neradīs vairāk mākslīgā intelekta atsaucību

Spēcīgākie atsaucības atlases prognozētāji, visticamāk, paliks:

• Atbilstība vaicājumam.
• Satura kvalitāte.
• Skaidras atbildes.
• Aktualitāte.
• Autoritatīvums un uzticība.
• Meklēšanas indeksa atbilstība.
• Izguves rangu.
• Vai lapa tieši atbalsta izteikto apgalvojumu.

Google vadlīnijas uzsver noderīgu, uzticamu, uz cilvēkiem orientētu saturu un norāda, ka mākslīgā intelekta meklēšanas funkcijas balstās uz esošajām meklēšanas un indeksēšanas sistēmām. (developers.google.com)

Veiktspējas budžets, kas pielāgots mākslīgā intelekta izguvei

Šis ir piedāvātais operatīvais budžets. Tā nav publicēta mākslīgā intelekta ranžēšanas formula.

Google pašreizējā dokumentācija norāda, ka Googlebot ielādē pirmos 2 megabaitus atbalstītā faila un atsevišķi ielādē ārējos skriptus un stila lapas. Tas arī iesaka ievietot svarīgus metadatus un strukturētos datus HTML sākumā. (developers.google.com)

Ieviešanas ieteikumi

HTTP/3

Izmantojiet HTTP/3, ja to atbalsta mitināšanas pakalpojumu sniedzējs un satura piegādes tīkls.

Mēriet:

• HTTP/3 sarunāšanās ātrumu.
• HTTP/2 atkāpes ātrumu.
• Savienojuma iestatīšanas laiku.
• Laiku līdz pirmajam baitam.
• Veiktspēju pēc ģeogrāfiskā reģiona.
• Veiktspēju pēc pārlūka.

Neuzskatiet HTTP/3 par garantētu meklēšanas vai mākslīgā intelekta optimizāciju. Tas ir transporta uzlabojums, kas var palīdzēt tikai klientiem, kas to izmanto.

Satura piegādes tīkla malu kešatmiņa

Publiskām, nepersonalizētām lapām:

• Iestatiet skaidrus Cache-Control noteikumus.
• Izmantojiet ilgstošu kešatmiņu versijotiem statiskiem resursiem.
• Izmantojiet īsu, bet noderīgu kešatmiņu bieži atjauninātam HTML.
• Izvairieties no kešatmiņas fragmentācijas no nevajadzīgiem vaicājuma parametriem.
• Saglabājiet kanoniskos URL.
• Atbalstiet ETag un Last-Modified.
• Pārbaudiet aukstās, siltās un atkārtoti validētās kešatmiņas stāvokļus.
• Apstipriniet, ka pārlūka pieprasījumi saņem to pašu svarīgo saturu kā cilvēka pieprasījumi.

Satura piegādes tīklam vajadzētu samazināt latentumu, neradot novecojušas, nekonsekventas vai botu specifiskas lapu versijas.

Attēlu saspiešana

Attēliem:

• Izmantojiet AVIF vai WebP, ja vizuālā kvalitāte ir pieņemama.
• Nodrošiniet adaptīvus attēlu izmērus.
• Nepasniegt datora izmēra attēlu mazam mobilā tālruņa ekrānam.
• Neveiciet "lazy-loading" Largest Contentful Paint attēlam.
• Iekļaujiet attēla izmērus.
• Novietojiet Largest Contentful Paint attēlu sākotnējā HTML.
• Izmantojiet fetchpriority="high" tikai tad, ja tas ir piemērots.
• Saglabājiet svarīgus skaidrojumus tekstā, nevis iegultot tos tikai attēlos.

Attēlu saspiešana ir visvērtīgākā, ja attēls ir Largest Contentful Paint elements. Tas neatrisinās lapu, kuras galvenā aizkave rodas no servera renderēšanas vai JavaScript izpildes. (web.dev)

Izkārtojuma stabilitāte

Lai samazinātu Cumulative Layout Shift:

• Iestatiet platuma un augstuma atribūtus attēliem.
• Rezervējiet vietu reklāmām.
• Rezervējiet vietu iegultam video un sociālajam saturam.
• Izvairieties no reklāmkarogu ievietošanas virs esošā teksta.
• Izmantojiet stabilas fontu ielādes stratēģijas.
• Izvairieties no lielu servera renderētā satura bloku aizstāšanas pēc lapas ielādes.

Šīs izmaiņas uzlabo lietotāja pieredzi, pat ja tām nav mērāmas ietekmes uz pārlūkošanu vai atsaucībām. (web.dev)

Rīki un uzraudzība

Veiktspējas rīki

Izmantojiet:

• Chrome lietotāja pieredzes pārskatu reālo lietotāju Core Web Vitals.
• Chrome lietotāja pieredzes pārskata lietojumprogrammu programmēšanas interfeisu automatizētai lauka datu vākšanai.
• PageSpeed Insights laboratorijas auditiem un lauka datiem.
• Lighthouse atkārtojamiem laboratorijas testiem.
• Lighthouse Continuous Integration pieprasījumu veiktspējas budžetiem.
• WebPageTest vairāku atrašanās vietu testiem, kešatmiņas stāvokļiem un protokolu salīdzinājumiem.
• Chrome DevTools Largest Contentful Paint un izkārtojuma nobīdes atkļūdošanai.
• web-vitals JavaScript bibliotēku reālo lietotāju uzraudzībai.

Chrome User Experience Report lietojumprogrammu programmēšanas interfeiss nodrošina lapas līmeņa un izcelsmes līmeņa apkopotus lauka datus, tostarp Largest Contentful Paint, Cumulative Layout Shift, Interaction to Next Paint un eksperimentālo laiku līdz pirmajam baitam. (developer.chrome.com)

Lighthouse Continuous Integration var veikt veiktspējas pārbaudes pie katras koda izmaiņas un izgāzt kompilācijas, ja budžeti tiek pārsniegti. (github.com)

Pārlūku uzraudzība

Izmantojiet servera žurnālus, malu žurnālus un nelielu sintētisko zondēšanas komplektu.

Zondēšanas piemērs:

bash 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

Veiciet to pašu testu ar:

• Googlebot.
• Bingbot.
• OAI-SearchBot.
• PerplexityBot.
• Claude-SearchBot.
• Normālu pārlūkprogrammas lietotāja aģentu.

Testam vajadzētu pārbaudīt:

• Statusa kodu.
• Robots atļaujas.
• Atbildes galvenes.
• HTML saturu.
• HTTP versiju.
• Kešatmiņas stāvokli.
• Atbildes laiku.
• Vai svarīgs teksts ir pieejams bez JavaScript.

Meklēšanas un indeksēšanas uzraudzība

Izmantojiet:

• Google Search Console pārlūkošanas statistiku.
• Google Search Console lapu indeksēšanas pārskatus.
• Google Search Console URL pārbaudi.
• Google Search Console vietņu kartes datus.
• Google Search Console ģeneratīvā mākslīgā intelekta pārskatus, kad tie ir pieejami.
• Bing Webmaster Tools pārlūkošanas pieprasījumus un indeksētās lapas.
• Bing Webmaster Tools mākslīgā intelekta veiktspēju.
• Dienas vietņu kartes un lastmod pārbaudes.

Search Console lietojumprogrammu programmēšanas interfeiss var izgūt veiktspējas datus pēc lapas, vaicājuma, datuma, ierīces un meklēšanas parādīšanās, ievērojot tā datu ierobežojumus. (developers.google.com)

Atsaucību uzraudzība

Izveidojiet atsaucību paneli, kas satur no 50 līdz 200 stabiliem vaicājumiem par katru tēmu. Izpildiet paneli pēc fiksēta grafika un ierakstiet:

• Vai platforma meklēja.
• Kuri avoti parādījās.
• Vai pārbaudītais URL tika citēts.
• Atsaucības secība.
• Atbildes datums un laiks.
• Vai lapa mainījās.
• Vai modelis vai meklēšanas pieredze mainījās.

Nesalīdziniet atsaucību skaitu no dažādām sistēmām, it kā tās būtu līdzvērtīgas. Microsoft norāda, ka atsaucību aktivitāte nav ranžēšanas rādītājs, autoritātes rādītājs, datplūsmas mērījums vai kvalitātes rādītājs. (bing.com)

Brīdinājumu noteikumi

Izveidojiet brīdinājumus par:

• Laiks līdz pirmajam baitam, kas palielinās par vairāk nekā 25 procentiem.
• Largest Contentful Paint, kas pārsniedz 2,5 sekundes 75. procentilē.
• Cumulative Layout Shift, kas pārsniedz 0,1.
• Ilgstošu 5xx vai 429 atbilžu pieaugumu.
• Pārlūka veiksmes rādītāja kritumu.
• Robots.txt izmaiņām.
• Vietņu kartes kļūdu.
• Pēkšņu indeksēto lapu kritumu.
• Pēkšņu mākslīgā intelekta atsaucību kritumu vairākās platformās.
• Atsaucību apjoma izmaiņas, kas ietekmē tikai vienu platformu.

Atsaucību samazināšanos, kas ietekmē vienu platformu, var izraisīt modeļa, indeksa, vaicājuma vai produkta maiņa, nevis lapas veiktspējas problēma. Microsoft nepārprotami brīdina, ka atsaucību tendences ir novērošanas rakstura un var mainīties satura atjauninājumu, lietotāju pieprasījuma un sistēmas vai modeļa izmaiņu dēļ. (bing.com)

Galīgais secinājums

Vispamatotākais secinājums ir:

Ātrākas lapas var uzlabot pārlūkošanas efektivitāti, īpaši, ja servera latentums, resursu lielums, kļūdas vai renderēšanas aizkaves ir ierobežojoši faktori. Taču pašlaik nav spēcīgu pierādījumu, ka zemāki Core Web Vitals tieši liek mākslīgā intelekta sistēmām izvēlēties lapu kā atsaucību.

Paredzamā cēloņsakarību ķēde ir:

text 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

Pēdējais solis joprojām ir neskaidrs, jo atsaucību atlase ir atkarīga no atbilstības, kvalitātes, aktualitātes, autoritātes, vaicājuma nodoma, izguves ranga un katras mākslīgā intelekta sistēmas uzvedības.

Lielākajai daļai vietņu pareizā veiktspējas stratēģija tādēļ nav “optimizēt mākslīgā intelekta atsaucībām” izolēti. Tā ir:

1. Nodrošiniet svarīga satura pieejamību sākotnējā HTML.
2. Uzturiet stabilu laiku līdz pirmajam baitam.
3. Izmantojiet malu kešatmiņu publiskam saturam.
4. Saspiest un prioritizēt svarīgus attēlus.
5. Novērst izkārtojuma nobīdes.
6. Atgriezt uzticamus statusa kodus.
7. Uzturiet vietņu kartes un iekšējās saites aktuālas.
8. Atļaut pareizos meklēšanas pārlūkus.
9. Mēriet pārlūkošanu, indeksēšanu, izguvi un atsaucības kā atsevišķus posmus.

Šī pieeja rada ātrāku vietni cilvēkiem, veselīgāku vietni meklēšanas pārlūkiem un pārbaudāmu pamatu mākslīgā intelekta redzamības izpratnei.