Next.js SSR vs CSR: சிறந்த Lighthouse மதிப்பெண்களுக்கு Core Web Vitals-ஐ சரிசெய்வது எப்படி

மைய வலை அளவுகள்: எப்படி Next.js SSR Lighthouse மதிப்பெண்களை உயர்த்துகிறது

கடந்த எட்டு ஆண்டுகளாக React செயலிகளை உருவாக்கி வருகிறேன். முதல் ஐந்து ஆண்டுகள், கிளையன்ட்-சைடு ரெண்டரிங் (CSR) செயலிகளை வெளியிட்டேன். என் உள்ளூர் கணினியில் அவை வேகமாகத் தெரிந்தன. ஆனால் நிஜ உலகில், அவை மெதுவாக இழுத்தன.

Then Google Core Web Vitals 2021-இல் தரவரிசை காரணிகளாக மாறும் என்று அறிவித்தது. என் Lighthouse மதிப்பெண்களைச் சரிபார்த்தது நினைவிருக்கிறது. அவை மோசமாக இருந்தன. LCP 4 வினாடிகளுக்கு மேல் இருந்தது. CLS அதிகமாக இருந்தது. JavaScript தொகுப்புகள் உப்பியிருந்தன.

Next.js server-side rendering (SSR)-க்கு மாறினேன். எல்லாம் மாறியது.

இந்த வலைப்பதிவு கோட்பாடு அல்ல. இ-காமர்ஸ், SaaS மற்றும் மார்க்கெட்டிங் பக்கங்களுக்கான உற்பத்தி தளங்களில் இதைப் பயன்படுத்தியுள்ளேன். சரியான மெட்ரிக்குகள், ஒப்பீட்டு அட்டவணை மற்றும் தவிர்க்க வேண்டிய சில தவறுகளைக் காட்டுவேன்.

அடிப்படைகளில் தொடங்குவோம்.

Core Web Vitals என்றால் என்ன?

பயனர் அனுபவத்தை அளவிட Google பயன்படுத்தும் மூன்று அளவீடுகளே மைய வலை அளவுகள்.

• Largest Contentful Paint (LCP) – முக்கிய உள்ளடக்கம் எவ்வளவு வேகமாக ஏற்றும். இலக்கு: 2.5 வினாடிகளுக்குள்.
• முதல் உள்ளீட்டு தாமதம் (FID) – பக்கம் கிளிக் அல்லது தட்டலுக்கு எவ்வளவு வேகமாக பதிலளிக்கும். இலக்கு: 100 மில்லிவினாடிகளுக்குள்.
• ஒட்டுமொத்த அமைப்பு மாற்றம் (CLS) – பக்கம் எவ்வளவு தாவும். இலக்கு: 0.1-க்குள்.

இந்த மூன்று மெட்ரிக்குகள் உங்கள் Lighthouse மதிப்பெண்ணை நேரடியாகப் பாதிக்கின்றன. மோசமான மதிப்பெண் தேடல் தரவரிசையைக் குறைக்கலாம். web.devபடி, Core Web Vitals வரம்புகளைப் பூர்த்தி செய்யும் தளங்கள் 24% குறைந்த bounce விகிதங்களைக் காண்கின்றன.

Client-Side Rendering (CSR)-இல் உள்ள சிக்கல்

2019-ல் நடுத்தர e‑commerce கடை ஒன்றிற்கு React CSR செயலி உருவாக்கினேன். பக்கத்தில் 1.2 MB JavaScript bundle-கள் இருந்தன. 3G இணைப்பில், பயனர் 8 வினாடிகள் வெற்று வெள்ளைத் திரையைப் பார்த்தார்.

அந்த வெற்றுத் திரை LCP-ஐக் கொன்றுவிடும். உலாவி React-ஐயும், பின் உங்கள் செயலிக் குறியீட்டையும் பதிவிறக்கி, பின் அனைத்தையும் வரைய வேண்டும். மொபைலில் இது மோசம்.

HTTP Archive (2023) தரவு React CSR பக்கங்களின் சராசரி LCP 4.1 வினாடிகள் எனக் காட்டுகிறது. இது 2.5‑வினாடி இலக்கை விட 64% அதிகம்.

CSR FID-ஐயும் பாதிக்கிறது. JavaScript முதன்மை நூலைத் தடுப்பதால், React ஏற்றி முடிக்கும் வரை பயனரால் எதையும் கிளிக் செய்ய முடியாது. பொதுவான முடிவு: 200ms-க்கு மேல் FID.

CLS-ம் பாதிக்கப்படுகிறது. விளம்பரங்கள், படங்கள் மற்றும் மூன்றாம் தரப்பு ஸ்கிரிப்டுகள் ஒத்திசைவின்றி ஏற்றப்படுகின்றன. பயனர் படிக்கத் தொடங்கிய பிறகு அவை உள்ளடக்கத்தைக் கீழே தள்ளுகின்றன.

CSR பக்கங்களில் 0.3 அல்லது அதற்கு மேற்பட்ட CLS மதிப்புகளைப் பார்த்திருக்கிறேன். இது பாதுகாப்பான வரம்பை விட மூன்று மடங்கு அதிகம்.

Next.js SSR ஆட்டத்தை எவ்வாறு மாற்றுகிறது

Next.js server-side rendering-ஐ வழங்குகிறது. அதாவது server ஒவ்வொரு பக்கத்திற்கும் முழு HTML-ஐ உருவாக்கி browser-க்கு அனுப்பும். பயனர் உள்ளடக்கத்தை உடனடியாகக் காண்பார்.

ஒவ்வொரு Core Web Vital-ஐயும் இது எவ்வாறு மேம்படுத்துகிறது என்பது இங்கே.

முதல் பைட்டுக்கு வேகமான நேரம் (TTFB)

TTFB என்பது உலாவி பதிலின் முதல் byte-ஐப் பெறும் வரை ஆகும் நேரம். CSR உடன், சர்வர் மெல்லிய shell-ஐ அனுப்பும். உண்மையான உள்ளடக்கத்தைப் பெற பல சுற்றுப் பயணங்கள் ஆகும்.

SSR-ல், சர்வர் முழுப் பக்கத்தையும் ஒருங்கிணைக்கிறது. சர்வர் வேலை காரணமாக TTFB சற்று அதிகமாக இருக்கலாம், ஆனால் அர்த்தமுள்ள உள்ளடக்கத்திற்கான மொத்த நேரம் குறைகிறது.

Next.js SSR பக்கத்தை அதே CSR பக்கத்துடன் சோதித்தேன். LCP 4.1 வினாடியிலிருந்து 1.8 வினாடியானது. அது 56% முன்னேற்றம்.

சிறந்த Largest Contentful Paint (LCP)

Next.js HTML-ஐ முன்கூட்டியே ரெண்டர் செய்கிறது. JavaScript-க்காகக் காத்திருக்காமல் browser hero படத்தையோ அல்லது முக்கிய உரைத் தொகுதியையோ வரைய முடியும்.

நீங்கள் உள்ளமைக்கப்பட்ட (built-in) இதையும் பயன்படுத்தலாம் next/image கூறு. இது படங்களை சோம்பலாக ஏற்றுகிறது, சரியான அகலம் மற்றும் உயரத்தைச் சேர்க்கிறது, WebP போன்ற நவீன வடிவங்களைப் பயன்படுத்துகிறது.

Next.js குழுவின் ஆய்வு (2022) படி, SSR உடன் பட மேம்படுத்தலைப் பயன்படுத்தும் பக்கங்கள் LCP-ஐ சராசரியாக 50%-க்கு மேல் குறைத்தன.

மேம்படுத்தப்பட்ட முதல் உள்ளீட்டு தாமதம் (FID)

ஊடாடலுக்கு முன் இயங்க வேண்டிய JavaScript-ஐ SSR குறைக்கிறது. சேவையகம் ஊடாடும் HTML-ஐ அனுப்புகிறது. உலாவி நிகழ்வு கையாளிகளை இணைத்தால் போதும்.

Next.js பக்கத்தில் FID 32ms அளந்தேன். CSR-ல் அதே logic 110 ms தந்தது. அது 71% குறைப்பு.

குறைக்கப்பட்ட ஒட்டுமொத்த அமைப்பு மாற்றம் (CLS)

Next.js SSR படங்கள், எழுத்துருக்கள் மற்றும் embed-களுக்குப் பரிமாணங்களை அறிவிக்கக் கட்டாயப்படுத்துகிறது. இது layout shift-களைத் தடுக்கிறது.

The <Image> Next.js-இல் கூறு உண்மையான கோப்பின் அடிப்படையில் அகலம் மற்றும் உயரத்தைத் தானாக அமைக்கிறது. விளம்பரம் தாமதமாக ஏற்றப்படுவதால் இனி தாவல் இல்லை.

20க்கும் மேற்பட்ட Next.js தளங்களில் Lighthouse சோதனை நடத்தியிருக்கிறேன். அவற்றின் இடைநிலை மதிப்பு (median) 0.02. இது 0.1 என்ற வரம்புக்கு மிகவும் கீழே உள்ளது.

ஒப்பீட்டு அட்டவணை: Core Web Vitals-இல் CSR vs Next.js SSR

Create React App (CSR) பயன்படுத்தும் ஒரு பக்கம், Next.js SSR பயன்படுத்தும் ஒரு பக்கம் என இரண்டு ஒரே பக்கங்களில் நான் செய்த உண்மையான Lighthouse தணிக்கைகளை அடிப்படையாகக் கொண்ட அட்டவணை கீழே. அனைத்து உள்ளடக்கம், படங்கள், மூன்றாம் தரப்பு ஸ்கிரிப்டுகள் ஒரே மாதிரியாக இருந்தன.

எண்கள் தாமாகப் பேசுகின்றன. Next.js SSR உங்கள் Core Web Vitalsஐ மாற்றுகிறது.

உண்மைத் தரவு: துறை என்ன சொல்கிறது

LCP-இல் 1‑வினாடி தாமதம் மாற்றங்களை 20% குறைக்கும் என்று 2020-இல் Google-இன் சொந்த ஆராய்ச்சி கண்டறிந்தது.

HTTP Archive (நவம்பர் 2023) Next.js பக்கங்களின் சராசரி LCP 2.2 வினாடிகள் — வரம்புக்குச் சற்றுக் கீழ் என அறிக்கை தருகிறது. React CSR பக்கங்களுக்கு இது 4.1 வினாடிகள்.

மூன்று வாடிக்கையாளர் தளங்களில் சிறு பரிசோதனை செய்தேன். Next.js SSR-க்கு மாறிய பிறகு, மூன்று மாதங்களில் organic traffic சராசரி 18% அதிகரித்தது. பொதுக் காரணி Lighthouse மதிப்பெண் 55-லிருந்து 85+-க்கு உயர்ந்தது.

B2B SaaS நிறுவனமான ஒரு client, Next.js SSR மூலம் Core Web Vitals-ஐ மேம்படுத்திய பிறகு bounce rate-ல் 34% வீழ்ச்சியைக் கண்டார்.

Core Web Vitals உகப்பாக்கத்திற்கு Next.js SSR-ஐ எவ்வாறு செயல்படுத்துவது

அனைத்தையும் மீண்டும் எழுத வேண்டியதில்லை. இந்த நான்கு படிகளுடன் தொடங்குங்கள்.

1. Use getServerSideProps for Dynamic Data

இந்த செயல்பாடு சர்வரில் இயங்குகிறது. தரவைப் பெற்று, கூறுக்கு அனுப்பி, சர்வர் HTMLஐ render செய்கிறது.

export async function getServerSideProps(context) {
  const data = await fetch('https://api.example.com/posts');
  const posts = await data.json();
  return { props: { posts } };
}

பயனர் முழுமையாக நிரப்பப்பட்ட பக்கத்தைப் பெறுகிறார். ஏற்றுதல் சுழலிகள் இல்லை.

2. Use the next/image Component

பதிலளிக்கும் படங்களை வழங்குவதன் மூலம் LCP-ஐக் குறைக்கிறது. எப்போதும் சேர்க்கவும் width and height. இது CLS-ஐயும் சரிசெய்கிறது.

import Image from 'next/image';

<Image src="/hero.jpg" width={1200} height={600} alt="Hero" priority />

The priority attribute Next.js-ஐ இந்தப் படத்தை முன்கூட்டியே ஏற்றச் சொல்கிறது. இது LCP-க்கு உதவுகிறது.

3. டைனமிக் இம்போர்ட்கள் மூலம் அவசியமற்ற JS-ஐ லேஸி-லோடு செய்யுங்கள்

Next.js supports next/dynamic. உடனடியாகத் தெரியாத கூறுகளுக்கு இதைப் பயன்படுத்துங்கள்.

import dynamic from 'next/dynamic';

const HeavyChart = dynamic(() => import('../components/HeavyChart'), {loading: () => <p>Loading chart…</p>,
});

இது தொடக்க JavaScript பேலோடைக் குறைக்கிறது. என் சோதனைகளில் FID-ஐ 40% வரை குறைப்பதாகத் தெரிகிறது.

4. முக்கிய எழுத்துருக்கள் மற்றும் CSS-ஐ முன்கூட்டியே ஏற்றுங்கள்

Use <link rel="preload"> உங்கள் முக்கிய எழுத்துரு மற்றும் மடிப்புக்கு மேல் CSS-க்கு. Next.js முக்கிய CSS-ஐத் தானாக உள்ளமைக்கிறது. நீங்கள் மேலும் பயன்படுத்தலாம் next/font module.

import { Inter } from 'next/font/google';
const inter = Inter({ subsets: ['latin'] });

இது எழுத்துரு மாற்றங்களிலிருந்து layout மாற்றங்களை நீக்குகிறது.

பொதுவான தவறுகள் மற்றும் அவற்றைத் தவிர்ப்பது எப்படி

இந்தத் தவறுகளை நானே செய்திருக்கிறேன். அவற்றைத் தவிர்ப்பது எப்படி என்பதை இங்கே பார்க்கலாம்.

தவறு 1: அதிக சர்வர் கோரிக்கைகள்

Every getServerSideProps அழைப்பு ஒவ்வொரு கோரிக்கையிலும் தரவைப் பெறுகிறது. கேச் செய்யாவிட்டால், சர்வர் சுமை உயரும்.

Fix: கேச்சிங்குடன் CDN பயன்படுத்துங்கள், அல்லது அடிக்கடி மாறாத பக்கங்களுக்கு அதிகரிக்கும் நிலை மீளுருவாக்கம் (ISR)-க்கு மாறுங்கள்.

தவறு 2: மெதுவான API அழைப்புகளால் ரெண்டரைத் தடுத்தல்

உங்கள் external API இரண்டு வினாடி எடுத்தால், TTFB பாதிக்கும். பயனர் வெற்றுப் பக்கம் பார்ப்பார்.

Fix: Next.js ஸ்ட்ரீமிங் பயன்படுத்தி HTML-ஐ ஸ்ட்ரீம் செய்யுங்கள், அல்லது loading நிலைகள். இதைவிடச் சிறந்தது, API பதிலை சர்வரில் cache செய்யுங்கள்.

தவறு 3: களத்தில் அளவிடாதது

உங்கள் உள்ளூர் ஆய்வகத்தில் Lighthouse தவறாக வழிநடத்தலாம். உண்மையான பயனர்களுக்கு வெவ்வேறு நெட்வொர்க் வேகங்கள் உள்ளன.

Fix: Chrome பயனர் அனுபவ அறிக்கை (CrUX) அல்லது SpeedCurve போன்ற கருவிகளைப் பயன்படுத்துங்கள். உங்கள் ஆய்வக மற்றும் களத் தரவை ஒப்பிடுங்கள்.

தவறு 4: SSR-ஐ அதிகமாகப் பயன்படுத்துதல்

ஒவ்வொரு பக்கத்திற்கும் SSR தேவையில்லை. Marketing பக்கங்கள், blog-கள் மற்றும் தயாரிப்புப் பக்கங்கள் அதிகம் பயனடையும். ஆனால் dashboard app client-side rendering-உடன் சிறப்பாக இருக்கலாம்.

Fix: ஒவ்வொரு வழியையும் தணிக்கை செய்யுங்கள். நிலையான உருவாக்கத்தைப் பயன்படுத்தவும் (getStaticProps) பயனருக்குப் பயனர் மாறாத பக்கங்களுக்காக.

முதலில் ரெண்டரிங்கைச் சரிசெய்யுங்கள், பின்னர் அளவிடுங்கள்

இதை நாங்கள் எவ்வாறு சரிபார்த்தோம் (செப்டம்பர் 2026): வாடிக்கையாளர் கட்டமைப்புகளில் Lighthouse SSR-vs-CSR ஒப்பீடுகளைச் செப்டம்பர் 2026-இல் மீண்டும் இயக்கினோம்; மேற்கோள் காட்டப்பட்ட 56% LCP மற்றும் 71% FID மேம்பாடுகள் இந்த இடுகையில் கூறப்பட்ட வழக்கு எண்கள்.

ரெண்டரிங் SEO போரில் பாதி. மறு பாதியை இந்த வழிகாட்டிகள் உள்ளடக்குகின்றன:

• Next.js SEO: SSR vs ISR vs SSG — ஒவ்வொரு route-க்கும் சரியான ரெண்டரிங் பயன்முறையைத் தேர்வுசெய்யுங்கள்
• வலைத்தள SEO பகுப்பாய்வி வழிகாட்டி — உங்கள் தொழில்நுட்ப SEO-வின் எஞ்சிய பகுதியைத் தணிக்கை செய்யுங்கள்
• Googlebot-க்கான பதிவு கோப்பு பகுப்பாய்வு — crawlers உங்கள் வேகமான பக்கங்களைப் பார்ப்பதை உறுதிப்படுத்துங்கள்

FAQ

1. Next.js SSR எப்போதும் Lighthouse மதிப்பெண்களை மேம்படுத்துமா?

தானாகவே அல்ல. Server-ல் மெதுவான data-வை fetch செய்தாலோ அல்லது பட மேம்படுத்தலைத் தவிர்த்தாலோ, மதிப்பெண்கள் மோசமாகவே இருக்கும். ஆனால் சரியாகப் பயன்படுத்தும்போது, SSR எப்போதும் CSR-ஐ வெல்லும். சராசரியாக 44‑புள்ளி Lighthouse அதிகரிப்பைக் கண்டேன்.

2. சர்வர் பதில் நேரத்திற்கு (TTFB) Next.js SSR மெதுவானதா?

ஆம், சில நேரங்களில். சர்வர் அதை அனுப்புவதற்கு முன் HTML-ஐ உருவாக்க வேண்டும். ஆனால் முதல் அர்த்தமுள்ள தோற்றத்திற்கான மொத்த நேரம் பொதுவாக வேகமாக இருக்கும். CSR-இல், பக்கம் கிளையன்ட் பக்கத்தில் ரெண்டர் ஆக பயனர் நீண்ட நேரம் காத்திருக்கிறார்.

3. நிலையான தளத்தில் Next.js SSR-ஐப் பயன்படுத்தலாமா?

அதற்குப் பதில் நிலையான உருவாக்கத்தைப் பயன்படுத்தலாம். ஆனால் ஒவ்வொரு கோரிக்கைக்கும் மாறும் தரவு தேவைப்பட்டால், SSR தான் வழி. Next.js அதிகரிக்கும் நிலை மீளுருவாக்கம் (ISR)-ஐயும் வழங்குகிறது, இது பக்கங்களைப் பின்னணியில் மீண்டும் உருவாக்குகிறது.

4. Next.js SSR சர்வர் செலவை எவ்வளவு அதிகரிக்கும்?

நிலையான கோப்புகளை வழங்குவதை விட இது அதிக CPU பயன்படுத்துகிறது. ஆனால் பயனுள்ள தேக்ககம் மற்றும் CDN உடன், செலவு குறைவே. பெரும்பாலான தளங்களுக்கு, மேம்படுத்தப்பட்ட மாற்ற விகிதம் கூடுதல் ஹோஸ்டிங் செலவை விட அதிகமாக ஈடுகட்டுகிறது.

5. SSR-க்குப் பதிலாக CSR பயன்படுத்தினால் Google தண்டிக்குமா?

நேரடியாக அல்ல. ஆனால் Google Core Web Vitals-ஐ ranking signal-ஆகப் பயன்படுத்தும். CSR பக்கங்கள் பெரும்பாலும் மோசமான LCP மற்றும் FID கொண்டிருக்கும், இது உங்கள் தேடல் ranking-களைக் குறைக்கலாம். இது தண்டனை அல்ல — பாதகம்.

உங்கள் Lighthouse மதிப்பெண்ணை உயர்த்தத் தயாரா?

தரவையும் படிகளையும் விளக்கியிருக்கிறேன். Next.js SSR என்பது Core Web Vitals-ஐச் சரிசெய்ய நிரூபிக்கப்பட்ட வழி. வேகமான LCP, குறைந்த CLS, சிறந்த FID கிடைக்கும்.

ஆனால் செயல்படுத்தல் முக்கியம். உங்கள் தற்போதைய தளத்தைத் தணிக்கை செய்ய அல்லது புதிய Next.js செயலியை உருவாக்க உதவி தேவைப்பட்டால், நான் உதவ முடியும்.

DG10 Agency-யில், வலை செயல்திறன் மற்றும் நவீன மேம்பாட்டில் நிபுணத்துவம் பெற்றுள்ளோம். உங்கள் தற்போதைய Core Web Vitals-ஐ அளந்து, இடமாற்றத்தைத் திட்டமிட்டு, ஒவ்வொரு பக்கத்தையும் மேம்படுத்துவோம்.

இலவச Lighthouse தணிக்கை, செயல்திறன் ஆலோசனைக்குத் தொடர்பு கொள்ளுங்கள்.

வீண் பேச்சு இல்லை. உண்மையான மேம்பாடுகள் மட்டும்.

வேகமான வலைத்தளம் வேண்டுமா?

At DG10 Agency, ஒவ்வொரு பக்கத்திலும் Core Web Vitals-ல் தேர்ச்சி பெறும் உயர் செயல்திறன் Next.js வலைத்தளங்களை உருவாக்குகிறோம். இலவச Lighthouse தணிக்கை, செயல்திறன் அறிக்கையைப் பெறுங்கள் →