Nuxt 4 unumdorligini optimallashtirish: production qo‘llanma

Nuxt 4 ilovasi serverda render qilinsa ham sekin ishlashi mumkin. SSR unumdorlik muammolarining faqat bir qismini hal qiladi: brauzer baribir juda ko‘p JavaScript olishi, foydalanuvchiga kerak bo‘lmagan komponentlarni hydrate qilishi, hajmi katta rasmlarni yuklashi, sekin API javoblarini kutishi yoki keragidan ortiq katta Nuxt payload’larini qayta ishlashi mumkin.

Production muhitida eng katta natija ko‘pincha mayda optimallashtirishlardan emas, to‘g‘ri arxitekturadan keladi: har bir route uchun mos rendering strategiyasini tanlash, client tomondagi ishni kamaytirish, data payload’larini kichik saqlash, kritik resurslarni optimallashtirish, mumkin bo‘lgan joylarda cache ishlatish va natijani ham lab, ham real foydalanuvchi ma’lumotlari orqali o‘lchash.

Ushbu qo‘llanma yozilgan paytda Nuxt 4 hujjatlarida ko‘rsatilgan Nuxt 4.5.2 versiyasiga moslashtirilgan.

Qisqa javob

Nuxt 4’ni production uchun optimallashtirishda beshta asosiy yo‘nalishdan boshlang:

Har bir route uchun mos rendering tanlang — statik kontentni prerender qiling, haqiqatan dinamik sahifalar uchun esa server rendering yoki caching ishlating.
Kamroq JavaScript yuboring — ixtiyoriy komponentlarni lazy-load qiling va darhol interaktivlik talab qilinmaydigan joylarda hydration’ni kechiktiring.
Data overhead’ni kamaytiring — takroriy so‘rovlardan saqlaning va client’ga faqat kerakli ma’lumotlarni serialize qiling.
LCP resurslarini optimallashtiring — ayniqsa hero rasmlar, fontlar, CSS va server response vaqtini.
Production’dagi real ishlashni o‘lchang — taxminga tayangan optimallashtirish o‘rniga Core Web Vitals, field data va bundle tahlilidan foydalaning.

Nuxt allaqachon code splitting, SSR, data-fetching utilitalari va Nitro’ni taqdim etadi. Asosiy vazifa — shu imkoniyatlarni ilovaning real ishlashiga mos sozlash. (nuxt.com)

Unumdorlik mezonlari

Google’ning hozirgi Core Web Vitals chegaralari:

Metrika	Yaxshi natija	Nimani o‘lchaydi
LCP	≤ 2.5 s	Yuklanish unumdorligi
INP	≤ 200 ms	O‘zaro ta’sirga javob berish tezligi
CLS	≤ 0.1	Vizual barqarorlik

Bu ko‘rsatkichlar 75-percentile bo‘yicha, mobil va desktop trafik uchun alohida baholanishi kerak. (web.dev)

Ular foydali mezonlar, lekin diagnostika o‘rnini bosa olmaydi. Sahifaning LCP ko‘rsatkichi server, rasmning kech aniqlanishi, CSS, CDN konfiguratsiyasi yoki bir nechta kechikishlarning birgalikdagi ta’siri sabab yomon bo‘lishi mumkin.

INTERNAL LINK: Core Web Vitals tushuntirilgan

Har bir route uchun rendering tanlang

Nuxt unumdorligi bo‘yicha eng muhim qarorlardan biri bundle optimallashtirishdan ham oldin qabul qilinadi: bu sahifani har bir so‘rovda dinamik render qilish haqiqatan kerakmi?

Nuxt default holatda server rendering’ni, shuningdek statik prerendering va Nitro route rules orqali hybrid xatti-harakatni qo‘llab-quvvatlaydi. (nuxt.com)

Masalan:

// nuxt.config.ts
export default defineNuxtConfig({
  routeRules: {
    '/': { prerender: true },
    '/about': { prerender: true },
    '/blog/**': { prerender: true },
    '/api/catalog': {
      cache: { maxAge: 60 * 10 }
    }
  }
})

Marketing bosh sahifasi, dokumentatsiya yoki blog maqolasini odatda har bir tashrifchi uchun serverda qaytadan render qilish shart emas. Agar kontent faqat deployment yoki CMS orqali publish qilish jarayonida o‘zgarsa, prerendering request yo‘lidan server rendering’ni olib tashlaydi.

Dinamik account sahifalari esa boshqacha. Ular authentication, permissions yoki tez-tez o‘zgaradigan shaxsiy ma’lumotlarga bog‘liq bo‘lishi mumkin, shuning uchun odatda dinamik bo‘lib qolishi kerak.

Eng keng tarqalgan xatolardan biri — sozlash osonroq bo‘lgani uchun butun ilova uchun bitta rendering rejimini tanlash.

Statik sahifalarni yanada optimallashtirish mumkin

Nuxt 4 client tomonda interaktivlik umuman kerak bo‘lmagan sahifalar uchun noScripts imkoniyatini ham qo‘llab-quvvatlaydi. Prerendering bilan birga ishlatilganda bunday route odatiy Nuxt client script’lari va hydration xarajatisiz HTML va CSS ko‘rinishida berilishi mumkin. (nuxt.com)

export default defineNuxtConfig({
  routeRules: {
    '/blog/**': {
      prerender: true,
      noScripts: true
    }
  }
})

Buni interaktiv sahifalarga qo‘llamang. noScripts ishlatilgan route’da Vue hydration, client-side event handler’lar va odatiy client-side Nuxt navigatsiyasi bo‘lmaydi.

Hydration ishini kamaytiring

Server rendering HTML yaratadi, lekin interaktiv Nuxt sahifasida tegishli komponentlarni brauzerda hydrate qilish uchun baribir Vue ishlashi kerak.

Bu CPU vaqtini talab qiladi.

Uzun landing page quyidagilarni o‘z ichiga olishi mumkin:

navigatsiya,
hero kontent,
mijoz fikrlari,
narx kalkulyatorlari,
carousel’lar,
newsletter formalar,
xaritalar,
analytics integratsiyalari,
chat widget’lar.

Ularning barchasi bir vaqtda interaktiv bo‘lishi shart emas.

Nuxt lazy komponentlar uchun kechiktirilgan hydration strategiyalarini qo‘llab-quvvatlaydi. Komponent ko‘rinadigan bo‘lganda, brauzer bo‘sh turganda, foydalanuvchi o‘zaro ta’sir qilgandan keyin yoki boshqa belgilangan shart bajarilganda hydrate qilinishi mumkin. (nuxt.com)

<template>
  <HeroSection />

  <LazyTestimonials hydrate-on-visible />

  <LazyNewsletterForm hydrate-on-visible />

  <LazyCookieSettings hydrate-on-idle />
</template>

Bu ayniqsa first fold’dan pastdagi funksiyalar uchun foydali. Faqat performance score’ni yaxshilash uchun kritik above-the-fold elementlarning hydration’ini kechiktirmang; Nuxt hujjatlarida foydalanuvchiga darhol kerak bo‘ladigan kontent hydration’ini kechiktirmaslik tavsiya qilinadi. (nuxt.com)

Lazy loading va lazy hydration ham turli muammolarni hal qiladi. Lazy komponent code splitting’ga yordam beradi, delayed hydration esa serverda render qilingan kontent qachon interaktiv bo‘lishini boshqaradi.

INTERNAL LINK: Nuxt Hydration tushuntirilgan

Data payload’larini kichik saqlang

Nuxt’dagi useAsyncData va useFetch SSR-aware hisoblanadi. Ma’lumot server rendering vaqtida yuklanganda, Nuxt natijani o‘z payload’i orqali uzatishi mumkin, shuning uchun brauzer hydration paytida o‘sha request’ni qayta bajarishi shart bo‘lmaydi. (nuxt.com)

Bu foydali, ammo boshqa bir savol paydo bo‘ladi:

Sahifaga qancha ma’lumot serialize qilyapsiz?

Tasavvur qiling, API 40 ta field qaytaradi, ammo sahifaga ulardan faqat to‘rttasi kerak.

To‘liq obyektni uzatish o‘rniga:

const route = useRoute()

const { data: product } = await useAsyncData(
  `product-${route.params.slug}`,
  () => $fetch(`/api/products/${route.params.slug}`),
  {
    pick: ['id', 'name', 'price', 'image'],
    deep: false
  }
)

pick orqali natijani faqat kerakli property’lar bilan cheklash mumkin. Nuxt 4’dagi useAsyncData default holatda shallow reactivity ishlatadi, bu esa kerak bo‘lmagan paytda har bir ichki property’ni deep reactive qilish xarajatidan qochishga yordam beradi. (nuxt.com)

Dinamik route’larda cache yoki async-data key’lari haqiqiy resursni aniq ifodalashi kerak. Turli sahifalarda noaniq bir key’ni qayta ishlatish noto‘g‘ri shared data xatti-harakatiga olib kelishi mumkin.

Nuxt prerender qilingan va cache qilingan route’lar uchun payload extraction’ni ham qo‘llab-quvvatlaydi. Konfiguratsiyaga qarab, payload ma’lumotlari _payload.json fayllarida saqlanishi va client navigatsiyasi vaqtida qayta ishlatilishi mumkin. (nuxt.com)

LCP resursini optimallashtiring

Ko‘plab production saytlarida LCP elementi katta hero rasm yoki yirik matn blokidir.

Google yaxshi LCP’ni 75-percentile’da 2.5 soniya yoki undan kam deb belgilaydi, ammo LCP muammosiga bitta son sifatida emas, bir necha bosqichli jarayon sifatida qarash kerak. (web.dev)

Hero rasm uchun quyidagi zanjirni tekshiring:

Server response → HTML ichida aniqlanishi → rasm request’i → yuklanish → render

Rasmning o‘zi yaxshi optimallashtirilgan bo‘lsa ham, brauzer uni kech aniqlasa, LCP yomonlashishi mumkin.

Nuxt Image bilan to‘g‘ri o‘lchamlar va responsive sizing belgilang hamda haqiqiy LCP rasmni preload qilishni ko‘rib chiqing:

<NuxtImg
  src="/images/hero.webp"
  width="1440"
  height="810"
  sizes="sm:100vw lg:1200px"
  :preload="{ fetchPriority: 'high' }"
  alt="Product dashboard"
/>

Nuxt Image rasm preload’i va fetch priority boshqaruvini qo‘llab-quvvatlaydi. (image.nuxt.com) Web performance tavsiyalari muhim LCP rasm uchun kerakli joyda fetchpriority="high" ishlatishni tavsiya qiladi, shu bilan birga barcha resurslarga asossiz ravishda yuqori prioritet berishdan ogohlantiradi. (web.dev)

LCP elementi bo‘lishi kutilayotgan rasmga lazy loading qo‘llamang.

JavaScript xarajatini nazorat qiling

Nuxt route-level code splitting’ni avtomatik bajaradi, biroq uchinchi tomon dependency’lari baribir ayrim chunk’larni og‘irlashtirishi mumkin. (nuxt.com)

Ko‘p uchraydigan sabablar:

editor’lar,
chart kutubxonalari,
map SDK’lari,
animation kutubxonalari,
analytics paketlari,
customer-support widget’lari,
katta utility paketlar.

Faqat foydalanuvchi tugmani bosgandan keyin ko‘rinadigan funksiya odatda kritik boshlang‘ich bundle ichida bo‘lmasligi kerak.

<script setup lang="ts">
const open = ref(false)
</script>

<template>
  <button @click="open = true">
    Open analytics
  </button>

  <LazyAnalyticsDashboard v-if="open" />
</template>

Nuxt’dagi Lazy komponent qoidasi dynamic import’lardan foydalanadi, shuning uchun ixtiyoriy komponent kodi keyinroq yuklanishi mumkin. (nuxt.com)

Plugin’larni ham xuddi shunday tekshirish kerak. Nuxt hujjatlarida og‘ir plugin setup’i hydration’ni bloklashi mumkinligi, bir-biriga bog‘liq bo‘lmagan asynchronous plugin’larni esa parallel bajarish mumkinligi qayd etilgan. (nuxt.com)

Hydration mismatch’larni tuzating

Hydration warning shunchaki kosmetik muammo emas.

Nuxt hujjatlariga ko‘ra, mismatch’lar Vue’ni component tree’larni qayta render qilishga majbur qilishi, interaktivlikka yetib borish vaqtini oshirishi, vizual siljishlar keltirib chiqarishi va event handler’lar ishlashini buzishi mumkin. (nuxt.com)

Ko‘p uchraydigan sabablar:

server va client turli qiymatlar yaratadi,
browser-only API’lar SSR vaqtida ishlatiladi,
random qiymatlar alohida generatsiya qilinadi,
natija vaqtga bog‘liq bo‘ladi,
client-only rendering noto‘g‘ri ishlatiladi.

Warning’ni yashirish o‘rniga state farqining asl sababini tuzating.

Avval o‘lchang, keyin optimallashtiring

Performance ishlari quyidagi tartibda ketishi kerak:

Muammo → o‘lchash → sabab → tuzatish → qayta o‘lchash

Yetarli field data mavjud bo‘lsa, real foydalanuvchilarning Core Web Vitals ko‘rsatkichlarini PageSpeed Insights yoki CrUX orqali tekshiring. CrUX real Chrome foydalanuvchilarining tajribasini ifodalaydi, Lighthouse esa nazorat qilinadigan lab diagnostikasini beradi. (developer.chrome.com)

JavaScript uchun production bundle’ni tahlil qiling:

npx nuxt analyze

Nuxt’dagi analyze buyrug‘i production ilovasini build qiladi va kutilmaganda katta dependency yoki chunk’larni aniqlashga yordam beradigan bundle tahlilini yaratadi. Hozir bu buyruq hujjatlarda experimental sifatida ko‘rsatilgan. (nuxt.com)

Production uchun foydali workflow:

Field LCP, INP va CLS ko‘rsatkichlarini tekshiring.
Sekin route’ni realistik mobil sharoitda qayta yarating.
Network waterfall va performance trace’ni tekshiring.
Haqiqiy blocking resource yoki main-thread task’ni aniqlang.
Bitta muhim bottleneck’ni tuzating.
Deploy qiling va field performance’ni qayta solishtiring.

Faqat Lighthouse score uchun optimallashtirmang.

Keng tarqalgan xatolar

Arxitekturani soddalashtirish uchun SSR’ni o‘chirib qo‘yish.ssr: false ilovani client-side rendering’ga o‘tkazadi va SSR’ning ko‘plab afzalliklarini yo‘qotadi. Nuxt hujjatlarida statik SPA output dastlab bo‘sh app container bilan kelishi, SSR prerendering esa sahifa HTML’ini darhol berishi aniq ko‘rsatilgan. (nuxt.com)

Hammasini darhol hydrate qilish. Server-rendered HTML brauzer qiladigan ish bepul degani emas. Kritik bo‘lmagan interaktivlikni kechiktiring.

API obyektlarini to‘liq yuborish. Request sonini kamaytirib, juda katta serialize qilingan payload yuborish bottleneck’ni faqat boshqa joyga ko‘chiradi.

LCP rasmni lazy-load qilish. Kritik kontent ataylab kechiktirilmasligi, aksincha brauzer tomonidan imkon qadar erta aniqlanishi kerak.

Har bir experimental performance funksiyasini qo‘shish. Experimental funksiyalar o‘zgarishi va muhim trade-off’larga ega bo‘lishi mumkin. Masalan, Nuxt 4.5 experimental SSR streaming’ni hujjatlashtiradi, ammo u response headers va status qachon o‘zgartirilishi mumkinligiga ta’sir qiladi hamda bir nechta route-rule konfiguratsiyalarida avtomatik fallback qiladi. Bunday imkoniyatlarni global qo‘llashdan oldin haqiqiy ilovada sinab ko‘ring. (nuxt.com)

SeoNest tavsiyasi

Nuxt’ni tashqaridan ichkariga qarab optimallashtiring.

Avval foydalanuvchilar real hayotda nimani boshdan kechirayotganini o‘lchang. Keyin bottleneck server response vaqti, rendering strategiyasi, kritik resurslarning yuklanishi, hydration, JavaScript execution yoki data transfer bilan bog‘liqligini aniqlang.

Ko‘pchilik production Nuxt saytlarida ustuvorlik quyidagicha bo‘lishi kerak:

to‘g‘ri rendering strategiyasi → tez kritik kontent → minimal hydration → kichik payload’lar → nazorat qilinadigan JavaScript → caching → doimiy field measurement

Texnik jihatdan murakkab konfiguratsiya avtomatik ravishda tez degani emas. Eng yaxshi Nuxt arxitekturasi — server, tarmoq va brauzerni keraksiz ish qilishga majbur qilmaydigan arxitektura.

FAQ

SSR har doim tezroqmi?

Yo‘q. SSR dastlabki HTML yetkazib berishni yaxshilashi mumkin, ammo sekin server rendering, katta payload’lar va og‘ir hydration baribir yomon performance’ga olib kelishi mumkin. To‘g‘ri yondashuv route’ga bog‘liq.

Har bir sahifani prerender qilish kerakmi?

Yo‘q. Natijasini oldindan xavfsiz generatsiya qilish mumkin bo‘lgan sahifalarni prerender qiling. Shaxsiylashtirilgan yoki tez-tez o‘zgaradigan sahifalar dinamik rendering talab qilishi mumkin.

Lazy loading INP’ni yaxshilaydimi?

Kritik yo‘ldan keraksiz JavaScript’ni olib tashlasa, yordam berishi mumkin. Ammo INP foydalanuvchi interaction’lari atrofida main thread qanday real ish bajarayotganiga bog‘liq. Google event handler’lar ishini kamaytirish va zarur bo‘lganda uzun task’larni kichik qismlarga bo‘lishni tavsiya qiladi. (web.dev)

`hydrate-never` ishlatish kerakmi?

Faqat client-side interaktivlik talab qilmaydigan kontent uchun. Nuxt bunday komponentlarni odatiy hydration xarajatisiz serverda render qilishi mumkin. (nuxt.com)

Avval nimani optimallashtirish kerakligini qanday bilaman?

Agar mavjud bo‘lsa, real foydalanuvchilarning Core Web Vitals ko‘rsatkichlaridan boshlang. Keyin metric qiymatiga qarab taxmin qilish o‘rniga, lab tool’lari va browser trace’lar orqali uning sababini toping.

Yakuniy xulosa

Nuxt 4 yuqori unumdorlik uchun kuchli asosni allaqachon beradi, ammo production performance arxitekturangiz Nuxt va brauzerga qancha ish yuklashiga bog‘liq.

Har bir request vaqtida rendering talab qilmaydigan kontentni prerender qiling. Qayta ishlatiladigan response’larni cache qiling. Sahifaga faqat kerakli data va JavaScript’ni yuboring. Interaktivlikni foydalanuvchiga haqiqatan kerak bo‘lgan paytda hydrate qiling. Dastlabki foydalanuvchi tajribasiga ta’sir qiladigan resursga prioritet bering va har bir muhim o‘zgarishni o‘lchovlar bilan tekshiring.

Bu yondashuv alohida optimallashtirish usullarini yig‘ishdan yaxshiroq masshtablanadi, chunki u sahifaning haqiqiy xarajatlarini kamaytiradi.

Sources

Nuxt — Introduction, Nuxt 4 documentation. Current documentation identifies v4.5.2. Nuxt Introduction
Nuxt — Prerendering. Nuxt Prerendering
Nuxt — Server / Hybrid Rendering. Nuxt Server Documentation
Nuxt — Components: Dynamic Imports and Delayed Hydration. Nuxt Components Documentation
Nuxt — useAsyncData. Nuxt useAsyncData Documentation
Nuxt — Nuxt and Hydration. Nuxt Hydration Best Practices
Nuxt Image — NuxtImg. Nuxt Image NuxtImg Documentation
Google web.dev — Web Vitals. Web Vitals
Google web.dev — Philip Walton and Barry Pollard, Optimize Largest Contentful Paint, updated March 31, 2025. Optimize Largest Contentful Paint
Chrome for Developers — Chrome UX Report API. CrUX API Documentation

Nuxt 4 unumdorligini optimallashtirish: production qo‘llanma