Ինչպես դարձնել քո կայքը ավելի արագ. գործնական ստուգաթերթ
Կայքն ավելի արագ դարձնելու համար նախ չափիր այն PageSpeed Insights-ով, ապա շտկիր ամենամեծ պատճառը, որ նա ցույց է տալիս. սովորաբար չափից մեծ նկարները, չափից շատ JavaScript-ը, ծանր տառատեսակները կամ երրորդ կողմի սկրիպտները։ Նպատակ դիր Google-ի Core Web Vitals-ի «լավ» նպատակները. հիմնական բովանդակությունը երևա 2.5 վայրկյանում, արձագանքը հպումներին՝ 200 միլիվայրկյանում, և գրեթե ոչ մի դասավորության թռիչք։ Շատ կայքեր այնտեղ են հասնում մի քանի փոփոխությամբ, ոչ թե վերագրելով։
Չափիր նախքան որևէ բան փոխելը
Գուշակելը ժամանակ է կորցնում։ Երկու անվճար գործիք ծածկում է գրեթե բոլորին.
- PageSpeed Insights (pagespeed.web.dev) — տեղադրիր կենդանի URL. այն ցույց է տալիս field data՝ իրական Chrome օգտատերերից (եթե կայքն ունի բավարար երթևեկություն) և lab data՝ մոդելավորված բեռնումից, գումարած կոնկրետ խնդիրների ցանկը։
- Lighthouse Chrome DevTools-ում — նույն lab թեստը, որ աշխատում է ցանկացած էջի վրա, որ կարող ես բացել, ներառյալ նախադիտման։ Թեստավորիր բջջային ռեժիմում. հեռախոսները դանդաղ ցանցերի վրա են, որտեղ խնդիրներն երևում են։
Թվերը, որոնք կարևոր են, Google-ի Core Web Vitals-ն են։ 2026 թվականի սեպտեմբերի դրությամբ Google-ի փաստաթղթերը web.dev-ում տալիս են այս «լավ» շեմերը՝ չափված էջի բեռնումների 75-րդ տոկոսայնում.
| Չափանիշ | Ինչ է չափում | Լավ |
|---|---|---|
| Largest Contentful Paint (LCP) | Որքան շուտ է երևում հիմնական բովանդակությունը (հերոյի նկար, վերնագիր) | 2.5 վ կամ պակաս |
| Interaction to Next Paint (INP) | Որքան արագ է էջը արձագանքում սեղմումներին, հպումներին և մուտքագրմանը | 200 մվ կամ պակաս |
| Cumulative Layout Shift (CLS) | Որքան է դասավորությունը ցատկում բեռնման ժամանակ | 0.1 կամ պակաս |
INP-ը 2024 թվականին փոխարինեց հին First Input Delay չափանիշը։ Եթե գործիքը դեռ հաղորդում է FID, այն հնացած է։
Գրիր քո սկզբնական թվերը. յուրաքանչյուր շտկումից հետո նորից փորձիր, որպեսզի իմանաս, թե ինչն է օգնել։
Որտեղ է ժամանակը գնում. տարբերակներ և փոխզիջումներ
Ամեն սովորական պատճառ ունի շտկում, և յուրաքանչյուր շտկում ունի գին։ Սկսիր վերևի կետերից. դրանք ամենաէժանն են և ամենատարածվածը։
| Պատճառ | Սովորական շտկում | Փոխզիջում |
|---|---|---|
| Մեծ նկարներ | Չափափոխիր ցուցադրվող չափին, սեղմիր, օգտագործիր WebP կամ AVIF | Թեթև որակի կորուստ, եթե չափազանց սեղմես |
| Նկարները սխալ հերթականությամբ բեռնվում են | Lazy-load արա ծալքից ներքևի նկարները. հերոյի նկարին տուր բարձր առաջնահերթություն | Ոչ մի, եթե հերոյի նկարը չէ lazy |
| Չափից շատ JavaScript | Բաժանիր կոդը ըստ էջի, հեռացրու չօգտագործվող գրադարանները | Որոշ վերամշակում |
| Միայն կլիենտում ռենդերինգ | Նախառենդերիր կամ սերվերում ռենդերիր հանրային էջերը | Ավելի շատ build կամ սերվերի կարգավորում |
| Վեբ տառատեսակներ | Ավելի քիչ ընտանիքներ և կշիռներ, նախաբեռնիր հիմնականը, font-display: swap | Տիպոգրաֆիական բազմազանության կորուստ |
| Երրորդ կողմի սկրիպտներ | Հեռացրու չօգտագործվողները, մնացածը բեռնիր էջից հետո | Կորցնում ես վիջեթ կամ թրեքեր |
| Դանդաղ սերվերի պատասխան | Քեշավորում, CDN, ստատիկ հոստինգ բովանդակության էջերի համար | Մտածելու բան՝ քեշի թարմացում |
Նկարներ
Նկարները ամենատարածված խնդիրն են և ամենահեշտ շտկվողը. 4,000 պիքսելանոց լուսանկար, որ ցուցադրվում է 800 պիքսել լայնությամբ, ստիպում է յուրաքանչյուր այցելուին ներբեռնել հինգ անգամ ավելին, քան նա տեսնում է։
- Մատուցիր նկարները այն չափով, որով ցուցադրվում են, արձագանքող
srcsetչափերով հեռախոսների և համակարգիչների համար։ - Օգտագործիր ժամանակակից ձևաչափեր (WebP կամ AVIF) և խելամիտ սեղմում։
- Դիր
widthևheightյուրաքանչյուր նկարի վրա, որպեսզի բրաուզերը տեղ պահի։ Միայն սա շտկում է դասավորության տեղաշարժի մեծ մասը։ - Lazy-load արա ծալքից ներքևի նկարները
loading="lazy"-ով։ - Երբեք մի lazy-load արա էջի վերևի հիմնական նկարը։ Google-ի LCP ուղեցույցը այս մասին կտրական է. LCP նկարի lazy-loading-ը միշտ ուշացնում է այն։ Դրա փոխարեն տուր
fetchpriority="high"։
JavaScript
Շատ AI-ով կառուցված կայքեր single-page app-եր են (SPA). բրաուզերը ներբեռնում է JavaScript փաթեթ և հետո նկարում է էջը։ Որքան մեծ է փաթեթը, այնքան երկար է դատարկ էկրանը։ Շտկումներ՝ ըստ ջանքի աճի.
- Հեռացրու այն, ինչ չես օգտագործում։ Խնդրիր կախվածությունների ցուցակը և հեռացրու գրադարանները, որ մեկ անգամ ավելացվել և մոռացվել են. ամսաթվերի գրադարան մեկ ամսաթվի համար, ամբողջական պատկերակների փաթեթ հինգ պատկերակի համար։
- Բաժանիր ըստ երթուղու։ Բեռնիր ադմին վահանակի կոդը միայն այն ժամանակ, երբ որևէ մեկը բացում է այն, ոչ թե գլխավոր էջում։
- Նախառենդերիր հանրային էջերը։ Մարքեթինգային էջը, որ գալիս է որպես իրական HTML, երևում է մինչև JavaScript-ի աշխատելը։ Սա օգնում է նաև որոնման համակարգերին. տե՛ս SEO AI-ով կառուցված կայքերի համար։
Դանդաղ INP-ը սովորաբար նշանակում է մեկ երկար առաջադրանք, որ արգելափակում է էջը. ցուցակի զտումը յուրաքանչյուր ստեղնի սեղմումով, կամ ամբողջ աղյուսակի վերառենդերինգը, երբ փոխվում է մեկ բջիջ։ Chrome DevTools-ի Performance վահանակը ցույց է տալիս, թե որը։
Տառատեսակներ
Յուրաքանչյուր տառատեսակի ընտանիք և կշիռ ևս մեկ ֆայլ է։ Երկու ընտանիք և երեք-չորս կշիռ սովորաբար բավարար են։ Նախաբեռնիր ծալքից վերև օգտագործվող տառատեսակը, օգտագործիր font-display: swap, որպեսզի տեքստը անմիջապես երևա, և ինքդ հոստավորիր տառատեսակները, եթե արտաքին ծառայությունը դանդաղ է քո այցելուների համար։
Երրորդ կողմի սկրիպտներ
Չաթ վիջեթները, անալիտիկան, heatmap-երը, գովազդային պիքսելները, embed տեսանյութերը և սոցիալական հոսքերը բեռնում են կոդ այլ սերվերներից։ Յուրաքանչյուրը փոքր է թվում. միասին հաճախ էջի ամենադանդաղ մասն են։ Պահիր այն, որին իրականում նայում ես։ Մնացածը բեռնիր այն բանից հետո, երբ էջը փոխազդելի է, և ծանր embed-ները (YouTube նվագարկիչ, քարտեզ) փոխարինիր թեթև նախադիտմամբ, որը կբեռնի իսկականը սեղմելիս։
Սերվերի պատասխան
Time to first byte (TTFB) — որքան ժամանակ է պահանջում սերվերը պատասխանը սկսելու համար — ընկած է յուրաքանչյուր այլ չափանիշի տակ։ CDN-ից (սերվերների ցանց, որ մոտ է քո այցելուներին. տե՛ս ինչ է CDN-ը) սպասարկվող ստատիկ էջերը արագ են գրեթե ամենուր։ Յուրաքանչյուր հարցման վրա սերվերի կողմից կառուցված էջերը կախված են այդ սերվերից և նրա տվյալների բազայից։ Քեշավորելը կրկնվող աշխատանքը և տվյալների բազայի ինդեքսները դանդաղ հարցումների համար սովորական շտկումներ են։
Հուշումներ, որոնք աշխատում են
Եղիր կոնկրետ. նշիր էջը, չափանիշը և սահմանափակումը։ Տեղադրիր PageSpeed Insights-ի գտածոները, եթե ունես։
PageSpeed Insights-ը ցույց է տալիս LCP 4.8 վ բջջային սարքում գլխավոր էջի համար, և LCP տարրը հերոյի նկարն է։ Չափափոխիր և փոխարկիր հերոյի նկարը WebP-ի, մատուցիր արձագանքող չափեր, դիր width և height, տուր fetchpriority="high" և համոզվիր, որ այն lazy չէ։ Lazy-load արա ծալքից ներքևի յուրաքանչյուր նկար։ Մի փոխիր դիզայնը։
Աուդիտ արա այս ծրագրի կախվածությունները։ Թվարկիր յուրաքանչյուր փաթեթ, թե ինչ է օգտագործում այն և մոտավորապես որքան է ավելացնում փաթեթին։ Հեռացրու չօգտագործվողները և բաժանիր /admin և /settings երթուղիները առանձին մասերի, որոնք բեռնվում են միայն այցելելիս։
/products էջի որոնման դաշտը դանդաղ է թվում։ Debounce արա զտումը, խուսափիր ամբողջ ցուցակի վերառենդերինգից յուրաքանչյուր ստեղնի սեղմումով, և էջավորիր կամ վիրտուալացրու ցուցակը, եթե այն ունի 200-ից ավելի տարր։
Ստեպ առ ստեպ
- Թեստավորիր կենդանի էջը PageSpeed Insights-ում բջջային ռեժիմում։ Նշիր LCP, INP և CLS, և ցուցակված երեք առաջին խնդիրները։
- Շտկիր նկարները նախ. չափեր, ձևաչափեր, չափսեր, lazy-loading ծալքից ներքև, առաջնահերթություն հերոյին։
- Կտրիր երրորդ կողմի սկրիպտները, որ չես օգտագործում, և հետաձգիր մնացածը։
- Կրճատիր տառատեսակները այն բանին, ինչ դիզայնը պետք է։
- Փոքրացրու JavaScript-ը. հեռացրու չօգտագործվող փաթեթները, բաժանիր ըստ երթուղու։
- Նախառենդերիր հանրային էջերը, եթե դեռ միայն կլիենտում են ռենդերվում և LCP-ը դեռ դանդաղ է։
- Ստուգիր սերվերը. քեշավորում, տվյալների բազայի ինդեքսներ, ստատիկ հոստինգ բովանդակության համար, որ հազվադեպ է փոխվում։
- Նորից հրապարակիր և նորից թեստավորիր։ PageSpeed Insights-ի field data-ն թարմանում է հաջորդ շաբաթների ընթացքում, երբ իրական այցեր են գալիս, ուստի վաղ արդյունքները գնահատիր lab տվյալներով։
Սովորական սխալներ
- Թեստավորել միայն արագ laptop-ի վրա։ Քո այցելուները միջին կարգի հեռախոսների և անկայուն բջջային ինտերնետի վրա են։ Թեստավորիր բջջային ռեժիմում։
- Հետապնդել կատարյալ 100-ը։ Lab գնահատականը ուղեցույց է։ Երբ Core Web Vitals-ը լավ տիրույթում է, բովանդակությունը և օգտագործելիությունը ավելի կարևոր են, քան վերջին մի քանի միավորը։
- Lazy-load անել ամեն ինչ, ներառյալ հերոյի նկարը։ Դա վատթարացնում է LCP-ը։
- Ավելացնել արագության plugin կամ գրադարան վերևից։ Քաշը հեռացնելը գրեթե միշտ ավելի լավն է, քան կոդ ավելացնելը այն կառավարելու համար։
- Օպտիմիզացնել նախադիտումը, ոչ թե կենդանի կայքը։ Development նախադիտումները աշխատեցնում են չօպտիմիզացված build-եր։ Չափիր հրապարակված URL-ը։
- Արագությունը մեկ անգամ շտկել։ Յուրաքանչյուր նոր վիջեթ, նկար և գործառույթ ավելացնում է քաշ։ Նորից թեստավորիր մեծ փոփոխություններից հետո։
Արագության ստուգաթերթ
- LCP ≤ 2.5 վ, INP ≤ 200 մվ, CLS ≤ 0.1 բջջային սարքում
- Նկարները չափափոխված, սեղմված, ժամանակակից ձևաչափով, width և height-ով
- Հերոյի նկարը lazy չէ; ծալքից ներքևի նկարները lazy են
- Չօգտագործվող JavaScript գրադարաններ չկան; ծանր երթուղիները առանձնացված են
- Երկու տառատեսակի ընտանիք կամ պակաս, հիմնական տառատեսակը նախաբեռնված
- Միայն այն երրորդ կողմի սկրիպտները, որ իրականում օգտագործում ես, բեռնված ուշ
- Հանրային էջերը նախառենդերված կամ ստատիկ, որտեղ հնարավոր է
- Նորից թեստավորված կենդանի URL-ի վրա հրապարակումից հետո
Արագությունն ու բջջային դասավորությունը միասին են. տե՛ս ինչպես դարձնել կայքը բջջային ադապտիվ։ Լրիվ նախագործարկային անցման համար ինչպես տանել AI նախատիպը արտադրություն ծածկում է մնացածը։
Արագությունը Mythex-ում
Mythex-ում այս փոփոխությունները կատարում ես չաթում հարցնելով, կամ Pro-ում՝ կոդի խմբագրիչում։ Ստուգիր հրապարակված URL-ը, ոչ թե Preview-ը, քանի որ Preview-ն աշխատեցնում է development սերվեր։ Ստատիկ front end-երը տեղակայվում են որպես ստատիկ կայքեր հրապարակելիս (ստատիկ կայքեր), ինչը հարմար է բովանդակության էջերի համար։ Սերվեր ունեցող հավելվածները սպասում են զրոյի. անգործության ժամանակ քնում են և արթնանում հաջորդ այցի ժամանակ, այնպես որ լուռ շրջանից հետո առաջին հարցումը ավելի դանդաղ է, և կցված տվյալների բազան քնում է 5 րոպե անգործությունից հետո (հոստինգի սահմանափակումներ)։ Եթե հանրային էջը դանդաղ է միայն առաջին այցի ժամանակ, դա հավանական պատճառն է։ Մարքեթինգային էջերը ստատիկ պահելը օգնում է։ Փոփոխություններից հետո նորից հրապարակիր և արա hard-refresh։
Հարցեր
Ո՞րն է էջի բեռնման լավ ժամանակը։
Google-ի Core Web Vitals-ը տալիս է ամենահստակ նպատակները. հիմնական բովանդակությունը պետք է երևա 2.5 վայրկյանում (LCP), էջը պետք է արձագանքի մուտքին 200 միլիվայրկյանում (INP), իսկ դասավորության տեղաշարժը պետք է մնա 0.1-ից ցածր (CLS), չափված իրական այցերի 75-րդ տոկոսայնում։
Ազդո՞ւմ է կայքի արագությունը SEO-ի վրա։
Այո, մի փոքր։ Google-ը օգտագործում է էջի փորձի ազդանշաններ, այդ թվում՝ Core Web Vitals, բայց համապատասխան բովանդակությունն ավելի շատ է կարևորվում։ Արագությունն ավելի մեծ ազդեցություն ունի այցելուների վրա, որոնք լքում են դանդաղ էջերը, նախքան որևէ բան կարդալը։
Ինչու է իմ PageSpeed Insights գնահատականը ամեն անգամ տարբեր։
Lab գնահատականը գալիս է մեկ մոդելավորված բեռնումից, ուստի ցանցի և սերվերի ժամանակը տատանվում է յուրաքանչյուր գործարկման ժամանակ։ Գործարկիր մի քանի անգամ և նայիր միտումին, իսկ ավելի մեծ կշիռ տուր field data բաժնին, որը գալիս է իրական Chrome օգտատերերից։
Ի՞նչն է դանդաղեցնում առավելագույն թվով կայքեր։
Սովորաբար չափից մեծ նկարները, չափից շատ JavaScript-ը, վեբ տառատեսակները և երրորդ կողմի սկրիպտները, ինչպիսիք են չաթ վիջեթները, գովազդային պիքսելները և embed-ները։ Դանդաղ սերվերի պատասխանը կամ սառը գործարկվող backend-ը ավելացնում է բոլորին։