Սերվերի կողմի ռենդերիنگի (SSR) թերությունները ինչ են?

SSR-ի հիմնական թերությունները՝

• Սերվերի վրա բեռի ավելացում: Յուրաքանչյուր հաճախորդի հարցումը պահանջում է էջի ամբողջական ռենդերինգ սերվերում, ինչը ավելի շատ ռեսուրսներ (CPU, հիշողություն) է սպառում համեմատ statական ֆայլերի կամ SPA-ի հետ:
• Կարգավորման բարդություն: Կոդի իզոմորֆիզմը (աշխատանք սերվերում և հաճախորդում), վիճակի կառավարումը միջեւ հարցումների, ասինխրոն տվյալների մշակումը։ Դեբագը կարող է ավելի բարդ լինել:
• Սերվերի սխալների դեպքում դադարեցում: Եթե գլխավոր ռենդերինգ սերվերը խափանվի, կայքը կարող է դառնալ անհասանելի, հակառակ դեպքում SPA-ում, հաճախորդը կարող է շարունակել աշխատել cache-ված ռեսուրսներով կամ fallback էջերով:
• Ավելի երկար ժամանակ մինչև ինտերակտիվություն (TTI): Թեև առաջին բովանդակությունը հայտնվում է ավելի արագ (FCP), օգտատերը չի կարող փոխազդել հավելվածի հետ մինչև ամբողջ JavaScript-ը (հիդրացիա) բեռնվի և կատարվի հաճախորդում։ SPA-ում, փոխազդեցությունը կարող է ավելի վաղ լինել արդեն բեռնված էջի մասերում:
• Cache-ի բարդություն: Դինամիկ գեներացված HTML-ի cache-ավորումը ավելի բարդ է, քան statական ռեսուրսները։ Պահանջվում են ավելի առաջադեմ cache-ավորման ռազմավարություններ սերվերի կողմից:
• Առաջին բայթի բարձր ժամանակ (TTFB): Սերվերը պետք է ժամանակ տրամադրի հարցման մշակման, տվյալների ստացման, HTML-ի ռենդերինգի և առաջին բայթի ուղարկման համար:
• Իզոմորֆիկ կոդի հետ կապված խնդիրներ: Որոշ հաճախորդ API-ներ (օրինակ, window, document) հասանելի չեն սերվերում, ինչը պահանջում է պայմանական կոդ գրել կամ օգտագործել հատուկ գրադարաններ:

// Պատճառական ռենդերինգի օրինակ սերվերում
if (typeof window === 'undefined') {
  // Կոդ, որը կատարվում է միայն սերվերում
  console.log('Սերվերային ռենդերինգ');
} else {
  // Կոդ, որը կատարվում է միայն հաճախորդում
  console.log('Հաճախորդային ռենդերինգ');
}