SEO, արագագործություն և հասանելիություն

01Core Web Vitals. LCP, INP և CLS

Core Web Vitals-ը երեք մետրիկ է, որոնցով Google-ը նկարագրում է իրական օգտատիրոջ փորձառությունը։ Largest Contentful Paint-ը (LCP) այն պահն է, երբ հայտնվում է հիմնական բովանդակությունը, սովորաբար hero պատկերը կամ վերնագիրը. լավ է 2.5 վայրկյանը կամ պակասը։ Interaction to Next Paint-ը (INP) չափում է, թե որքան արագ է էջը տեսողականորեն արձագանքում սեղմումներին, հպումներին և ստեղների սեղմումներին ամբողջ այցի ընթացքում. լավ է 200 միլիվայրկյանը կամ պակասը։ INP-ն 2024-ի մարտին փոխարինեց First Input Delay-ին։ Cumulative Layout Shift-ը (CLS) չափում է, թե որքան է բովանդակությունն անսպասելիորեն «ցատկոտում». լավ է 0.1-ը կամ պակասը։ Էջն անցնում է, երբ իրական այցերի 75%-ը բավարարում է յուրաքանչյուր շեմին՝ mobile-ի և desktop-ի համար առանձին չափված։ Դրանք ranking ազդանշան են, բայց համեստ. դրանց ավելի մեծ արժեքը conversion-ներն են և օգտատերերի վստահությունը։

• LCP ≤ 2.5 s. բեռնում։
• INP ≤ 200 ms. արձագանքողություն։
• CLS ≤ 0.1. տեսողական կայունություն։
• Գնահատվում է իրական օգտատերերի 75-րդ պերցենտիլով։

02Ինչպես շտկել յուրաքանչյուր մետրիկը

LCP-ն ունի չորս մաս՝ սերվերի պատասխանի ժամանակը (TTFB), ուշացումը մինչև browser-ը կհայտնաբերի LCP ռեսուրսը, դրա ներբեռնման ժամանակը և render-ի ուշացումը։ Շտկեք դրանք այդ հերթականությամբ. HTML-ը cache արեք edge-ում, hero պատկերը դարձրեք հայտնաբերելի HTML-ում (ոչ թե JavaScript-ով կամ CSS background-ով դրված), երբեք lazy-load մի արեք այն, տվեք fetchpriority="high" և մատուցեք AVIF կամ WebP ձևաչափով՝ ճիշտ չափսով։ INP-ն main thread-ի աշխատանքի մասին է. ուղարկեք ավելի քիչ JavaScript, երկար task-երը բաժանեք, որպեսզի browser-ը կարողանա դրանց արանքում paint անել (scheduler.yield() կամ setTimeout), ոչ հրատապ React թարմացումների համար օգտագործեք startTransition և խուսափեք ծանր third-party script-ներից։ CLS-ը նախապես պահված տարածքի մասին է. պատկերների և embed-ների վրա միշտ սահմանեք width և height կամ aspect-ratio, տարածք պահեք banner-ների և գովազդների համար և օգտագործեք համապատասխան մետրիկաներով font fallback-ներ։

1<!-- LCP image: discoverable, eager, high priority, right size -->
2<img
3  src="/img/hero-1200.avif"
4  srcset="/img/hero-800.avif 800w, /img/hero-1200.avif 1200w, /img/hero-1800.avif 1800w"
5  sizes="(max-width: 768px) 100vw, 1200px"
6  width="1200" height="675"
7  fetchpriority="high"
8  alt="Fresh coffee being poured into a cup" />
9 
10<!-- below-the-fold images -->
11<img src="/img/team.avif" width="800" height="600" loading="lazy" decoding="async" alt="Our team" />

03Crawling, indexing և canonical-ներ

Որոնողական համակարգերն աշխատում են երեք քայլով՝ crawl (URL-ների ստացում), index (դրանց պահպանում և հասկացում) և rank։ robots.txt-ը կառավարում է crawling-ը, ոչ թե indexing-ը. արգելափակված URL-ը միևնույն է կարող է հայտնվել արդյունքներում, եթե այլ կայքեր հղում են դրան։ Էջը index-ից դուրս պահելու համար թույլ տվեք crawling-ը և վերադարձրեք noindex meta tag կամ X-Robots-Tag header։ Canonical link-ը որոնողական համակարգերին ասում է, թե որ URL-ն է հիմնական տարբերակը, երբ նույն բովանդակությունը հասանելի է մի քանի հասցեով, օրինակ՝ tracking պարամետրերով կամ ֆիլտրերով. դա ուժեղ հուշում է, ոչ թե հրաման։ Վերադարձրեք իրական status code-եր՝ 301 մշտական տեղափոխությունների համար, 404 կամ 410 հեռացված էջերի համար, և երբեք 200-ով «not found» էջ։ Համոզվեք, որ կարևոր բովանդակությունը սերվերում render արված HTML-ի մեջ է, ոչ թե միայն կլիենտի JavaScript-ով է բեռնվում։

1# robots.txt
2User-agent: *
3Disallow: /cart
4Disallow: /account
5Disallow: /*?sort=
6 
7Sitemap: https://example.com/sitemap.xml

04Sitemap-ներ, structured data և hreflang

Sitemap-ը թվարկում է այն URL-ները, որոնք ուզում եք index անել, ճշգրիտ lastmod ամսաթվով. Google-ն անտեսում է priority-ն և changefreq-ը։ Մեկ ֆայլը պարունակում է մինչև 50,000 URL կամ 50 MB՝ չսեղմված, ուստի մեծ կայքերն օգտագործում են sitemap index։ Structured data-ն, սովորաբար JSON-LD script tag-ի մեջ, նկարագրում է էջը schema.org-ի բառապաշարով՝ Organization, Product՝ Offer-ով, BreadcrumbList, Article, Event։ Այն կարող է բացել rich result-ներ, օրինակ՝ գներ և վարկանիշներ։ Բազմալեզու կայքերի համար hreflang-ը որոնողական համակարգերին ասում է, թե որ URL-ն է որ լեզվի կամ տարածաշրջանի համար։ Յուրաքանչյուր տարբերակ պետք է թվարկի բոլոր տարբերակները, ներառյալ ինքն իրեն, հղումները պետք է լինեն փոխադարձ, իսկ x-default-ը ցույց է տալիս fallback-ը։ Օգտագործեք լեզվի կոդեր՝ en, hy, ru, ըստ ցանկության տարածաշրջանով, օրինակ՝ en-GB։

1<link rel="canonical" href="https://example.com/en/products/espresso" />
2<link rel="alternate" hreflang="en" href="https://example.com/en/products/espresso" />
3<link rel="alternate" hreflang="hy" href="https://example.com/hy/products/espresso" />
4<link rel="alternate" hreflang="ru" href="https://example.com/ru/products/espresso" />
5<link rel="alternate" hreflang="x-default" href="https://example.com/en/products/espresso" />
6 
7<script type="application/ld+json">
8{ "@context": "https://schema.org", "@type": "Product", "name": "Espresso beans 1 kg",
9  "offers": { "@type": "Offer", "price": "24.90", "priceCurrency": "EUR",
10              "availability": "https://schema.org/InStock" } }
11</script>

05Պատկերների և font-երի օպտիմալացում

Պատկերները սովորաբար էջի ամենածանր մասն են։ Մատուցեք ժամանակակից ձևաչափեր (AVIF, հետո WebP), srcset-ով և sizes-ով չափսը հարմարեցրեք ցուցադրվող չափսին, սեղմեք և lazy-load արեք ամեն ինչ, որ առաջին էկրանից ներքև է։ Framework-ները օգնում են. Next.js-ի Image կոմպոնենտը ավտոմատ գեներացնում է չափսերն ու ձևաչափերը. Next.js 16-ում հին priority prop-ը փոխարինվել է preload-ով, և փաստաթղթերը LCP պատկերի համար խորհուրդ են տալիս loading="eager" կամ fetchPriority="high"։ Font-երը առաջացնում են թե՛ դանդաղ տեքստ, թե՛ layout shift։ Self-host արեք դրանք, subset արեք միայն անհրաժեշտ նիշերով (առանձին ֆայլեր լատինական, կիրիլյան կամ հայկական գրերի համար), preload արեք միայն մեկ-երկու կրիտիկական ֆայլ, օգտագործեք font-display: swap և fallback font՝ size-adjust-ով, որպեսզի swap-ը տեքստը տեղից չշարժի։ Variable font-երը կարող են մի քանի weight ֆայլ փոխարինել մեկով։

1@font-face {
2  font-family: "Brand Sans";
3  src: url("/fonts/brand-sans-latin.woff2") format("woff2");
4  font-display: swap;
5  unicode-range: U+0000-00FF;
6}
7 
8/* metric-matched fallback reduces layout shift on swap */
9@font-face {
10  font-family: "Brand Sans Fallback";
11  src: local("Arial");
12  size-adjust: 104%;
13  ascent-override: 92%;
14}

06Հասանելիության հիմունքներ (WCAG)

WCAG-ը (Web Content Accessibility Guidelines) ստանդարտն է. 2.2 տարբերակը AA մակարդակով սովորական թիրախն է, և հենց դրան են հղում այնպիսի օրենքներ, ինչպիսին European Accessibility Act-ն է, որը կիրառվում է 2025-ի հունիսից։ Հիմունքները ծածկում են իրական խնդիրների մեծ մասը։ Օգտագործեք սեմանտիկ HTML՝ մեկ h1, վերնագրեր՝ հերթականությամբ, landmark-ներ (header, nav, main, footer), button՝ գործողությունների համար և a՝ հղումների համար։ Յուրաքանչյուր պատկերի պետք է իմաստալից alt տեքստ, կամ alt="", եթե այն դեկորատիվ է։ Տեքստի կոնտրաստը պետք է լինի առնվազն 4.5:1, կամ 3:1՝ մեծ տեքստի և UI կոմպոնենտների համար։ Ամեն ինչ պետք է աշխատի ստեղնաշարով՝ տեսանելի focus ցուցիչով։ Ֆորմաներին իրական label-ներ և հստակ սխալի հաղորդագրություններ են պետք։ Սեղմվող տարրերը պետք է լինեն առնվազն 24 x 24 CSS պիքսել։ Յուրաքանչյուր էջի համար սահմանեք lang ատրիբուտը, ինչը կարևոր է screen reader-ների համար բազմալեզու կայքերում։

• Նախ սեմանտիկ տարրեր, ARIA՝ միայն երբ HTML-ում համարժեք չկա։
• Ստեղնաշար. Tab-ի հերթականություն, տեսանելի focus, ոչ մի «թակարդ», Escape-ը փակում է dialog-ները։
• Կոնտրաստ՝ 4.5:1 տեքստի համար, 3:1՝ մեծ տեքստի և կառավարման տարրերի համար։
• Թեստավորեք screen reader-ով (VoiceOver, NVDA) և 200% zoom-ով։

07Չափում. Lighthouse, PageSpeed և CrUX

Տվյալները երկու տեսակի են։ Lab data-ն գալիս է ֆիքսված սարքի և ցանցի վրա սիմուլյացված բեռնումից՝ Lighthouse Chrome DevTools-ում կամ CI-ում։ Այն կրկնելի է և հիանալի է debugging-ի համար, բայց չի կարող ուղղակիորեն չափել INP-ն. Total Blocking Time-ը նրա փոխարինող ցուցանիշն է։ Field data-ն գալիս է իրական Chrome օգտատերերից՝ Chrome UX Report-ից (CrUX), որն ամփոփում է նախորդ 28 օրը։ PageSpeed Insights-ը URL-ի համար ցույց է տալիս երկուսն էլ, իսկ Search Console-ը խմբավորում է field data-ն ամբողջ կայքով։ Ձեր սեփական մանրամասն թվերի համար ավելացրեք web-vitals գրադարանը և մետրիկաներն ուղարկեք ձեր analytics, ներառյալ, թե որ տարրն էր LCP-ն և որ ինտերակցիան էր դանդաղ։ Օպտիմալացրեք field data-ի հիման վրա, շտկումները ստուգեք lab-ում, հետո սպասեք, որ field data-ն հաստատի։

1import { onLCP, onINP, onCLS } from "web-vitals/attribution";
2 
3function send(metric: { name: string; value: number; rating: string }) {
4  navigator.sendBeacon("/api/vitals", JSON.stringify(metric));
5}
6 
7onLCP(send);
8onINP(send);
9onCLS(send);

08INP-ի ներսում՝ input delay, processing և presentation

INP-ն մոտավորապես հաղորդում է այցի ամենավատ ինտերակցիան. շատ ինտերակցիաներով էջերում յուրաքանչյուր 50-ից մեկ outlier անտեսվում է։ Յուրաքանչյուր ինտերակցիա ունի երեք մաս, և յուրաքանչյուրն ունի իր լուծումը։ Input delay-ը այն ժամանակն է, մինչև ձեր handler-ն ընդհանրապես կսկսի աշխատել, սովորաբար որովհետև մեկ այլ long task է ընթանում, օրինակ՝ hydration, tag manager կամ analytics batch։ Processing time-ը հենց ձեր event handler-ներն են։ Presentation delay-ը handler-ներից հետո մինչև հաջորդ frame-ի նկարվելը կատարվող աշխատանքն է. փոխվածի style, layout և paint, որն աճում է DOM-ի չափի և մեծ React re-render-ների հետ։ Long Animation Frames API-ն (LoAF) հաղորդում է, թե որ սկրիպտներն են frame-ը դանդաղեցրել՝ մինչև source URL և ֆունկցիա, իսկ web-vitals attribution build-ը այդ գրառումները կցում է INP-ին։ Այսպիսով՝ մասնատեք մրցակցող long task-երը input delay-ը կրճատելու համար, նախ նկարեք տեսողական արձագանքը և մնացածը հետաձգեք processing-ը կրճատելու համար, և DOM-ը փոքր պահեք ու թարմացումները՝ լոկալ, presentation delay-ը կրճատելու համար։

1const yieldToMain = () =>
2  "scheduler" in globalThis && "yield" in scheduler
3    ? scheduler.yield()
4    : new Promise((resolve) => setTimeout(resolve, 0));
5 
6button.addEventListener("click", async () => {
7  showAddedState();      // 1. visual feedback in this frame
8  await yieldToMain();   // 2. let the browser paint
9  await saveCart();      // 3. heavy work afterwards
10  sendAnalytics();
11});

09Ակնթարթային նավիգացիաներ՝ bfcache և speculation rules

Ամենաարագ էջի բեռնումն այն է, որը երբեք տեղի չի ունենում։ Back/forward cache-ը (bfcache) հիշողության մեջ պահում է էջի ամբողջական snapshot, ուստի Back-ն ու Forward-ը վերականգնում են այն ակնթարթորեն՝ առանց ցանցի և առանց JavaScript-ի կրկնակի գործարկման։ Էջը կորցնում է այդ առավելությունը, եթե գրանցում է unload handler, օգտատիրոջ հեռանալու պահին պահում է որոշ բաց կապեր, կամ բացառված է header-ներով, ինչպես Cache-Control: no-store-ը։ DevTools-ում՝ Application և Back/forward cache բաժնում, կարելի է ստուգել էջը և տեսնել, թե կոնկրետ ինչու է այն բլոկավորված։ Առաջ նավիգացիաների համար Speculation Rules API-ն թույլ է տալիս Chromium-ի վրա հիմնված բրաուզերներին prefetch կամ ամբողջությամբ prerender անել հավանական հաջորդ էջերը՝ ցուցակից կամ հղումների համընկնմամբ, eagerness կարգավորմամբ, օրինակ՝ moderate (սկսել hover-ի ժամանակ)։ Prerender արված էջը բացվելիս ցույց է տալիս գրեթե զրոյական LCP։ Մյուս բրաուզերներն անտեսում են կանոնները, ուստի սա անվտանգ progressive enhancement է։ Prerender արեք միայն side effect-եր չունեցող GET էջեր, բացառեք logout կամ add-to-cart հղումները և analytics-ը հետաձգեք մինչև էջն իրականում ցուցադրվի՝ օգտագործելով document.prerendering-ը։

1<script type="speculationrules">
2{
3  "prerender": [{
4    "where": { "and": [
5      { "href_matches": "/*" },
6      { "not": { "href_matches": "/logout" } },
7      { "not": { "href_matches": "/cart/*" } },
8      { "not": { "selector_matches": "[data-no-prerender]" } }
9    ]},
10    "eagerness": "moderate"
11  }]
12}
13</script>

10Crawl budget և ռենդերինգ մեծ կայքերում

Մի քանի հարյուր էջով կայքը crawl է արվում ամբողջությամբ։ Հարյուր հազարավոր URL-ների դեպքում, օրինակ՝ faceted կատալոգում, crawl budget-ը դառնում է իրական. Googlebot-ը մեկ կայքի վրա ծախսում է սահմանափակ քանակով fetch-եր, որոնք կախված են նրանից, թե որքան արագ և առողջ է ձեր սերվերը և որքան պահանջարկ կա ձեր URL-ների նկատմամբ։ Կորուստը գալիս է անվերջ URL տարածքներից. ֆիլտրերի համակցություններ, սորտավորման կարգեր, session կամ tracking պարամետրեր, անվերջ օրացույցներ։ Վերահսկեք այն շերտերով։ Ակնառու հղումներ դրեք միայն այն facet էջերին, որոնք ուզում եք ինդեքսավորել։ Մյուս համակցությունները canonical արեք դեպի հիմնական էջը, կամ disallow արեք պարամետրերը robots.txt-ում, եթե դրանք նույնիսկ չպետք է fetch արվեն. հիշեք, որ բլոկավորված URL-ը չի կարող ցույց տալ իր noindex-ը։ Sitemap-ներում պահեք միայն canonical, ինդեքսավորվող URL-ներ՝ ազնիվ lastmod-ով։ Ստուգված Googlebot-ով ֆիլտրված server log-երը ցույց են տալիս, թե իրականում ուր է գնում crawling-ը։ Ռենդերինգը նույնպես կարևոր է. Google-ը կատարում է JavaScript, բայց որպես առանձին, ավելի թանկ քայլ, ուստի կոնտենտը և հղումները, որոնք հայտնվում են միայն client-side fetch-ից հետո, գտնվում են ավելի ուշ և ավելի քիչ հուսալի։

• Արագ, կայուն պատասխանները (ցածր TTFB, քիչ 5xx սխալներ) թույլ են տալիս Googlebot-ին ավելի շատ crawl անել։
• Դատարկ ֆիլտրերի համակցությունների համար վերադարձրեք 404՝ բարակ 200 էջի փոխարեն։
• Search Console-ի Crawl stats հաշվետվությունը ցույց է տալիս պատասխանի կոդերը, ֆայլերի տիպերը և host-ի վիճակը։

11Accessibility checklist-ից այն կողմ՝ անուններ, դերեր և live թարմացումներ

Ավտոմատ գործիքները բռնում են WCAG խախտումների միայն մի մասը. մնացածի համար պետք է հասկանալ accessibility tree-ն։ Բրաուզերը DOM-ը վերածում է օբյեկտների ծառի, որոնցից յուրաքանչյուրն ունի role (button, link, dialog), accessible name (տեքստային բովանդակությունից, label-ից, aria-label-ից կամ aria-labelledby-ից), վիճակներ, ինչպես expanded կամ checked, և ըստ ցանկության նկարագրություն։ Screen reader-ները կարդում են այս ծառը, ոչ թե ձեր պիքսելները. ստուգեք այն DevTools-ի Accessibility պատուհանում։ Այնտեղ երևում են ավելի խորը խնդիրներ. icon button-ներ առանց անվան, custom dropdown-ներ, որոնք չեն աշխատում ստեղնաշարով, single-page նավիգացիաներ, որոնք փոխում են կոնտենտը առանց focus-ը տեղափոխելու, ուստի screen reader-ի օգտատերերը չգիտեն, որ էջը փոխվել է (տեղափոխեք focus-ը նոր h1-ի վրա կամ հայտարարեք վերնագիրը), status հաղորդագրություններ, ինչպես «added to cart»-ը, որոնք տեսողապես հայտնվում են, բայց երբեք չեն հայտարարվում։ Հայտարարությունների համար օգտագործեք live region, օրինակ՝ role='status', որն արդեն գոյություն ունի DOM-ում, նախքան դրա տեքստը փոխելը։ Native dialog էլեմենտը showModal()-ով ինքն է trap անում focus-ը և մշակում Escape-ը։ Հիմնական flow-երը ստուգեք VoiceOver-ով կամ NVDA-ով։

1<button type="button" aria-label="Open cart" aria-expanded="false" aria-controls="cart">
2  <svg aria-hidden="true" focusable="false"><!-- icon --></svg>
3</button>
4 
5<!-- present on page load; changing its text is announced politely -->
6<p role="status" class="visually-hidden" id="cart-status"></p>
7 
8<dialog id="cart" aria-labelledby="cart-title">
9  <h2 id="cart-title">Your cart</h2>
10  <!-- opened with cart.showModal(): focus is trapped, Escape closes -->
11</dialog>