மைய வலை அளவு சரி: 95+ Lighthouse மதிப்பெண்களுக்கான டெவலப்பர் வழிகாட்டி

மைய வலை அளவு சரி: 95+ Lighthouse மதிப்பெண்களுக்கான டெவலப்பர் வழிகாட்டி

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

முறை குறிப்பு: கீழே உள்ள தீர்வு படிகள் ஏப்ரல் முதல் ஆகஸ்ட் 2026 வரை DG10 வாடிக்கையாளர் தளங்களில் (WordPress, Next.js, Shopify) சரிபார்க்கப்பட்டன, ஒவ்வொன்றும் கள CrUX தரவு மற்றும் ஆய்வக Lighthouse இயக்கங்களால் அளவிடப்பட்டன. வரம்புகள் மற்றும் கருவி குறிப்புகள் செப்டம்பர் 2026-இல் மீண்டும் சரிபார்க்கப்பட்டன.

உண்மை கடுமையானது: ஜூன் 2026 நிலவரப்படி, முதல் 1 மில்லியன் வெப்சைட்டுகளில் 20%க்கும் குறைவானவையே அனைத்து பக்க வகைகளிலும் Google Core Web Vitals வரம்புகளைப் பூர்த்தி செய்கின்றன. ஆனால் நாங்கள் வேலை செய்யும்போது — மேலோட்டமான ஒட்டுகள் அல்ல, உண்மையான சீரமைப்பு — முடிவுகள் தாமாகப் பேசுகின்றன. 15–40% போக்குவரத்து ஆதாயங்கள் பொதுவானவை, நாம் அஞ்சும் SEO தரவரிசை ஏற்ற இறக்கம்? அது நிலைப்படுகிறது.

இந்த வழிகாட்டி என் நேர்மையான, போரில் சோதித்த விளையாட்டுத் திட்டம். ஒவ்வொரு மெட்ரிக், நான் பயன்படுத்தும் சரியான கருவிகள், ஊசியை நகர்த்தும் குறியீடு-நிலை மாற்றங்களை உள்ளடக்குவோம். உண்மையான முன்/பின் தரவு, பொதுவான தவறுகள் மற்றும் எந்த தளத்தையும் சிவப்பிலிருந்து பச்சைக்கு கொண்டு செல்லும் பணிப்பாய்வைப் பகிர்வேன். இங்குள்ள ஒவ்வொரு பரிந்துரையும் நேரடி அனுபவத்திலிருந்து — மதிப்பெண்கள் ஏறுவதையும் போக்குவரத்து பின்தொடர்வதையும் பார்த்திருக்கிறேன்.

Core Web Vitals சரிசெய்தல் உங்கள் இறுதி லாபத்தை நேரடியாக ஏன் பாதிக்கிறது

வணிக வழக்கை முதலில் முடித்துவிடுவோம். Google-இன் தரவரிசை அமைப்பு — ஆண்டுகளுக்கு முன் அறிவிக்கப்பட்டது — இன்னும் CWV-ஐத் தரவரிசைச் சமிக்ஞையாகப் பயன்படுத்துகிறது. ஆனால் வாடிக்கையாளர்களிடம் நான் பார்த்த தரவு மிக நுணுக்கமான ஒன்றைக் காட்டுகிறது.

உண்மை போக்குவரத்து ஆதாயங்கள் கட்டுக்கதை அல்ல

சமீபத்தில் 92 Lighthouse performance மதிப்பெண்ணில் சிக்கிய SaaS நிறுவனத்தைத் தணிக்கை செய்தேன். largest contentful paint (LCP), cumulative layout shift (CLS), அடுத்த வண்ணப்பூச்சுக்கான தொடர்பு (Interaction to Next Paint - INP) ஆகியவற்றில் கவனம் செலுத்திய இரண்டு வார remediation-க்குப் பிறகு 97 எட்டினர். அடுத்த 90 நாட்களில் organic traffic 22% உயர்ந்தது.

அத்தகைய எண்கள் விதிவிலக்கல்ல. 2025 case study-யின் படி web.dev, "needs improvement"-லிருந்து "good"-க்கு CWV-ஐ மேம்படுத்தும் தளங்கள் organic traffic-ல் 10–25% அதிகரிப்பைக் காண்கின்றன. அது உண்மையான Google முதல் பக்க நிலை நகர்வு. எங்கள் வாடிக்கையாளர் தளத்தில் நான் கண்ட மற்றொரு பகுப்பாய்வு, மூன்று CWV வரம்புகளையும் கடப்பது branded அல்லாத தேடல் கிளிக்குகளில் சராசரியாக 18% உயர்வுடன் தொடர்புடையது என்பதைக் காட்டுகிறது.

மறைந்த செலவு: Bounce விகிதம் மற்றும் மாற்றம்

CWV SEO-க்கு மட்டும் அல்ல. LCP 3.5s-லிருந்து 1.8s-ஆகக் குறையும்போது, துள்ளல் விகிதம் குறைகிறது. மின்-வணிகத் தளங்களில் இதைக் கண்காணித்துள்ளேன்: ஏற்ற நேரத்தில் 0.5s முன்னேற்றம் துள்ளல் விகிதத்தை 8–12% குறைக்கிறது. மாதம் லட்சக்கணக்கான அமர்வுகளால் பெருக்கிப் பாருங்கள் — வருவாய் தாக்கம் கணிசமானது.

அதற்கு ஒரு எண் வைப்போம். மாதம் 500,000 அமர்வுகள், சராசரி 2.5% மாற்று விகிதம், $75 சராசரி ஆர்டர் மதிப்பு (AOV) கொண்ட நடுத்தர மின்வணிகக் கடைக்கு, bounce விகிதத்தில் 10% குறைப்பு மாதம் roughly $93,000 கூடுதல் வருவாயாக மாறலாம். அத்தகைய வணிக விளைவைத் தரும் ஒரு: Core Web Vitals fix வழங்க முடியும் — குறைந்தபட்ச வரம்புகளைக் கடப்பதில் மட்டுமின்றி இரு அளவீடுகளிலும் நாங்கள் கவனம் செலுத்துவதற்கான காரணம் இதுவே.

கிரால் பட்ஜெட் மற்றும் அட்டவணைப்படுத்தலில் டோமினோ விளைவு

அடிக்கடி கவனிக்கப்படாத பலன் Googlebot நடத்தை. உங்கள் பக்கங்கள் வேகமாக ஏற்றப்படும்போது, Google crawler ஒரு நேர அலகில் அதிக பக்கங்களைச் செயலாக்கும். LCP-ஐ 40% மேம்படுத்திய தளங்கள் நாளொன்றுக்குத் தவழப்பட்ட பக்கங்களில் 30% உயர்வைக் காண்பதைக் கண்டுள்ளேன். ஆயிரக்கணக்கான தயாரிப்புப் பக்கங்கள் கொண்ட பெரிய தளங்களுக்கு இது கண்டறியப்பட்ட உள்ளடக்கம் வேகமாக அட்டவணைப்படுத்தப்படும் என்று பொருள்; இது இயற்கை வளர்ச்சிச் சுழற்சியை நேரடியாக வேகப்படுத்தும்.

Core Web Vitals அளவீடுகள் மற்றும் Lighthouse 95 மதிப்பீட்டைப் புரிந்துகொள்தல்

To execute a Lighthouse 95 விளைவு, கலங்கரை விளக்கம் மதிப்பெண்கள் புலத் தரவையும் (Chrome UX அறிக்கையிலிருந்து) ஆய்வகத் தரவையும் (உருவகப்படுத்தப்பட்ட த்ரோட்லிங்) எவ்வாறு இணைக்கிறது என்பதை நீங்கள் புரிந்து கொள்ள வேண்டும். மதிப்பெண் பெறுதல் நேரியல் அல்ல.

Largest Contentful Paint (LCP)

• Good: ≤ 2.5s
• Needs Improvement: 2.5s–4.0s
• Poor: > 4.0s

LCP ஒட்டுமொத்த Lighthouse செயல்திறன் மதிப்பெண்ணில் 25% பங்கு வகிக்கிறது. 95+ மதிப்பெண் பெற, ஆய்வக (lab) நிலைமைகளில் LCP 1.8 வினாடிகளுக்குக் கீழேயும், 75வது சதவீத (percentile) களத் தரவில் 2.0 வினாடிகளுக்குக் கீழேயும் இருக்க வேண்டும். என் அனுபவத்தில், 95+ எட்டும் பெரும்பாலான தளங்கள் ஆய்வகத்தில் 1.2–1.5 வினாடிகள் LCP கொண்டிருக்கும்.

அடுத்த வண்ணப்பூச்சுக்கான தொடர்பு (Interaction to Next Paint - INP)

• Good: ≤ 200ms
• Needs Improvement: 200ms–500ms
• Poor: > 500ms

INP மார்ச் 2024-ல் FID-ஐ மாற்றியது. பக்கத்தின் ஒட்டுமொத்த responsiveness-ஐ அளக்கிறது. 95+ மதிப்பெண்ணுக்கு, கடும் throttling-ல் அதிகபட்ச INP 150ms இலக்கு வையுங்கள். அதாவது உங்கள் JavaScript main-thread வேலை பயனரின் அடுத்த interaction-ஐத் தடுக்காதவாறு வடிவமைக்கப்பட வேண்டும்.

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

• Good: ≤ 0.1
• Needs Improvement: 0.1–0.25
• Poor: > 0.25

முறையான HTML கட்டமைப்பால் CLS-ஐச் சரிசெய்வது எளிது — படங்கள் மற்றும் விளம்பரங்களில் வெளிப்படையான பரிமாணங்களை அமைக்கவும். ஆனால் அதுதான் மிகவும் கவனிக்கப்படாதது. 95+ எட்டும் தளங்களுக்கு 0.05 அல்லது அதற்கும் குறைவான CLS வழக்கம். முறையான அளவு மற்றும் இடைவெளி பயன்படுத்திய பிறகு 0.01 மதிப்பெண்கள் பெற்ற தளங்களை நான் பார்த்திருக்கிறேன்.

Metric	பச்சை நிலைக்கான வரம்பு (புலம்)	Lighthouse மதிப்பெண்ணில் தாக்கம்	வழக்கமான சரிசெய் சிக்கல்
LCP	≤ 2.5s	25%	Medium–High
INP	≤ 200ms	25%	High
CLS	≤ 0.1	15%	Low–Medium
TBT	≤ 200ms (Lab)	25%	High
SI	≤ 3.4s (Lab)	10%	Medium

அட்டவணை: Core Web Vitals வரம்புகள் மற்றும் Lighthouse மதிப்பெண் எடைகள்.

நோயறிதல்: உங்கள் குறிப்பிட்ட Core Web Vitals தீர்வைக் கண்டறிதல்

ஒரு வரி குறியீட்டைக் கூட மாற்றுவதற்கு முன், உயர்தர நோயறிதல் தேவை. தவறான பிரச்சினையைத் துரத்தி வாரக்கணக்கில் வீணடிக்கும் குழுக்களை நான் பார்த்திருக்கிறேன்.

படி 1: Throttling உடன் Incognito-வில் Lighthouse-ஐப் பயன்படுத்தவும்

Chrome DevTools-லிருந்து Lighthouse-ஐ "Mobile 3G Slow" முன்னமைவுடன் இயக்குங்கள் அல்லது நடுத்தர சாதனத்தை உருவகப்படுத்துங்கள். Note the Opportunities and Diagnostics பிரிவுகள் — எதைச் சரிசெய்ய வேண்டும் என்பதை அவை துல்லியமாகச் சொல்கின்றன. “Reduce initial server response time” மற்றும் “Eliminate render-blocking resources” ஆகியவற்றில் சிறப்பு கவனம் செலுத்துங்கள், ஏனெனில் இவை பெரும்பாலும் அதிக தாக்கத்தை ஏற்படுத்துகின்றன.

படி 2: Field தரவுக்கான CrUX API

Use the Chrome பயனர் அனுபவ அறிக்கை உங்கள் origin-க்கு உண்மையான பயனர் தரவை இழுக்க API. field தரவு LCP > 3s காட்டி lab தரவு 1s காட்டினால், DevTools சரியாக உருவகப்படுத்த முடியாத சர்வர்-பக்கச் சிக்கல் (மெ slow TTFB) உள்ளது. அப்படியானால், front-end வளங்களை விட ஹோஸ்டிங், CDN மற்றும் சர்வர் உள்ளமைவில் கவனம் செலுத்த வேண்டும்.

படி 3: நிகழ்நேர பயனர் கண்காணிப்பு (RUM)

அதிக-போக்குவரத்துத் தளங்களுக்கு, இலகுவான RUM தீர்வை (போன்ற ) நிறுவவும் WebPageTest’s RUM or custom PerformanceObserver அழைப்புகள்). இது தனிப்பட்ட விலகல்களை வெளிப்படுத்துகிறது — சில சாதன வகைகள் அல்லது புவியியலுக்கு மட்டும் மெதுவான பக்கங்கள் போன்று. RUM அமைப்பு உங்கள் மொபைல் LCP சரியாக இருந்தாலும் சோம்பல்-ஏற்றும் விளம்பரங்களால் டெஸ்க்டாப் CLS உயர்வதை வெளிப்படுத்தலாம். களத் தரவு இல்லாமல், குருடாகப் பறக்கிறீர்கள்.

படி 4: WebPageTest Filmstrip

Lighthouse-ஐ நான் எப்போதும் இதனுடன் சேர்த்துப் பயன்படுத்துவேன் WebPageTest. அதை “Mobile Slow 3G” என அமைத்து ஃபிலிம்ஸ்டிரிப்பைப் பாருங்கள். ஒவ்வொரு உறுப்பும் எப்போது தோன்றுகிறது, வீணான கோரிக்கைகள் உள்ளனவா என்பதை அது சரியாகக் காட்டும். என் hero படத்திற்கு முன் பதிவிறக்கம் தொடங்கும் மூன்றாம் தரப்பு ஸ்கிரிப்டுகளைப் பிடித்திருக்கிறேன்—அவை விரைவான வெற்றிகளைத் தரும் கண்டுபிடிப்புகள்.

95+ Lighthouse-க்கான செயல்படுத்தக்கூடிய Core Web Vitals சரிசெய்தல் உத்திகள்

ஒவ்வொரு அளவீட்டையும் உறுதியான குறியீடு-நிலை மாற்றங்களுடன் விளக்குவேன்.

LCP: முக்கிய சுமை தூக்கி

LCP வழக்கமாகப் படம், வீடியோ போஸ்டர் அல்லது பெரிய உரைத் தொகுதியாக இருக்கும். 95-ஐத் தாண்ட, 1.8 வினாடிகளுக்குக் கீழான LCP தேவை.

• முக்கியமான சொத்துகளை முன்கூட்டியே ஏற்றவும்: Use <link rel="preload" as="image" href="hero.webp"> ஹீரோ படங்களுக்கு. உரை அடிப்படையிலான LCP-க்கு, உங்கள் எழுத்துருவும் முன்கூட்டியே ஏற்றப்படுவதை உறுதி செய்யவும்.
• Optimize images: WebP-ஆக மாற்றவும், responsive அளவுகளைப் பயன்படுத்தவும் (srcset), AVIF போன்ற அடுத்த தலைமுறை வடிவங்களை வழங்குங்கள். WebP-உடன் ஒப்பிடும்போது AVIF படச் சுமையைக் கவனிக்கத்தக்க தர இழப்பின்றி 30% குறைப்பதைக் கண்டிருக்கிறேன்.
• சர்வர்-சைட் ரெண்டரிங்: நீங்கள் இது போன்ற கட்டமைப்பைப் பயன்படுத்துகிறீர்கள் என்றால் Next.js or React, LCP உள்ளடக்கம் JavaScript வழியாக ஏற்றப்படாமல் ஆரம்ப HTML-ல் இருப்பதை உறுதிசெய்யுங்கள். 1.8s-க்குக் கீழ் LCP-க்கு static generation அல்லது server-side rendering கட்டாயம்.
• ரெண்டர்-தடுக்கும் வளங்களை நீக்கவும்: முக்கியமற்ற CSS மற்றும் JavaScript-ஐத் தள்ளிப்போடுங்கள். பயன்படுத்தவும் rel="preload" for fonts and media="print" மாற்று பாணிகளுக்கு. மடிப்புக்கு மேலே உள்ள உள்ளடக்கத்திற்கான முக்கிய CSS-ஐ பெரும்பாலும் நேரடியாக உள்ளமைக்கிறோம்.
• உண்மையான பயனர் edge caching-உடன் CDN பயன்படுத்தவும். Services like Cloudflare அல்லது அமேசான் கிளவுட்ஃப்ரண்ட் நிலையான சொத்துக்களுக்கும், பயனருக்கு நெருக்கமான கேச் இடங்களிலிருந்து API பதில்களுக்கும் கூட சேவை செய்ய முடியும், இது TTFB மற்றும் LCP ஐ வியத்தகு முறையில் குறைக்கிறது.

Case: நான் ஒரு இ-காமர்ஸ் தளத்திற்கு உதவினேன், பயன்படுத்தி Shopify LCP-ஐ 4.1s-லிருந்து 1.6s-ஆகக் குறைக்கவும், தனிப்பயன் முக்கிய CSS பைப்லைனைச் செயல்படுத்தி மடிப்புக்குக் கீழே உள்ள படங்களை சோம்பலாக ஏற்றவும். தந்திரம் Shopify-யின் CDN URL மூலம் ஹீரோ மாறுபாடு படத்தை சர்வர்-பக்க முன்கூட்டியே ஏற்றுவது நேரடியாக <head>.

INP: புதிய Performance காவலாளி

INP தந்திரமானது, ஏனெனில் JavaScript செயல்பாட்டுத் திறன் சார்ந்தது. 150ms அல்லது குறைவாக இலக்கு வையுங்கள்.

• Code splitting: பெரிய React அல்லது Vue தொகுப்புகளைச் சிறிய துண்டுகளாகப் பிரியுங்கள், இதனால் தொடர்பின்போது தேவையான குறியீடு மட்டும் இயங்கும். டைனமிக் import() உடனடியாகத் தேவையில்லாத கூறுகளுக்கு.
• Web Workers: கனமான செயலாக்கத்தை (படச் சுருக்கம் அல்லது தரவு வடிவமைப்பு போன்றவை) Web Worker-க்கு மாற்றுங்கள். இது பயனர் தொடர்புகளுக்குப் பதிலளிக்க முதன்மை நூலை விடுவித்து வைக்கிறது.
• Event handler-களை மேம்படுத்துங்கள்: நீண்ட பணிகளைத் தவிர்க்கவும் (>50ms). பயன்படுத்தவும் requestAnimationFrame காட்சி புதுப்பிப்புகளுக்கு மற்றும் setTimeout ஒத்திவைக்கக்கூடிய வேலைக்கு. கையாளுபவர் DOM கையாளுதலை உள்ளடக்கினால், மாற்றங்களைத் தொகுக்கவும்.
• Minimize DOM size: பெரிய DOM மரங்கள் தளவமைப்பு மறுகணக்கீடுகளை மெதுவாக்குகின்றன. 1500 முனைகளுக்குக் கீழ் வைத்திருங்கள். தயாரிப்புப் பட்டியல் பக்கங்களில் 5,000+ முனைகளைக் கொண்ட தளங்களைப் பார்த்திருக்கிறேன் — அதை 1,500-க்குக் கீழ் குறைத்தது INP-ஐ 30% குறைத்தது.
• மூன்றாம் தரப்பு ஸ்கிரிப்டுகளைத் தாமதப்படுத்துங்கள். Google Tag Manager, Facebook Pixel மற்றும் பிற பகுப்பாய்வுக் கருவிகள் பெரும்பாலும் முதலில் இயங்கி பயனர் உள்ளீட்டைத் தடுக்கின்றன. அவற்றை நீக்க முடியாவிட்டால், அவற்றை அதற்குப் பிறகு ஏற்றுங்கள் onload or use async கவனமான பணி திட்டமிடலுடன்.

Real data: நான் மேம்படுத்திய ஒரு நிதித் தளத்தில் மூன்றாம் தரப்பு விளக்கப்பட நூலகத்தால் INP 540ms ஆக இருந்தது. Canvas-ஆல் உருவாக்கப்பட்ட இலகுவான விளக்கப்படத்திற்கு மாறிய பிறகு, INP 130ms ஆகக் குறைந்தது. நூலகம் ஒவ்வொரு தரவுப் புள்ளி hover-இலும் முழு விளக்கப்படத்தையும் மீண்டும் வரைந்தது; requestAnimationFrame எளிமையான ரெண்டரிங் அணுகுமுறையைப் பயன்படுத்தி, தடுமாற்றத்தை நீக்கினோம்.

CLS: எளிதில் பறிக்கும் கனி

பரிமாணங்கள் இல்லாமல் மாறும் உள்ளடக்கம் ஏற்றப்படுவதால்தான் CLS ஏறக்குறைய எப்போதும் ஏற்படுகிறது.

• Always set width and height படங்கள் மற்றும் ஐஃப்ரேம்களில். Use CSS aspect-ratio பதிலளிக்கக்கூடிய படங்களுக்கு மாற்றாக.
• விளம்பரங்கள் மற்றும் உட்பொதிப்புகளுக்கு இடம் ஒதுக்குங்கள். Use CSS aspect-ratio அல்லது நிலையான கொள்கலன்கள். மாறும் விளம்பர அளவுகளுக்கு, மிகவும் பொதுவான விளம்பர வடிவத்துடன் பொருந்தக்கூடிய தனிப்பயன் பிளஸ்ஹோல்டர் உறுப்பைப் பயன்படுத்தவும்.
• முதல் பெயிண்டுக்குப் பிறகு ஏற்கனவே உள்ள உள்ளடக்கத்திற்கு மேலே உள்ளடக்கத்தைச் செருகுவதைத் தவிர்க்கவும். இது தான் உண்மையான தங்க விதி. மடிப்புக்கு மேல் DOM-ஐ மாற்றும் எந்த ஸ்கிரிப்டும் ஆரம்பத் தளவமைப்பு நிலையான பிறகே தாமதப்படுத்தப்பட வேண்டும்.
• Use font-display: optional or swap கண்ணுக்குத் தெரியாத உரை அமைப்பு மாற்றங்களைத் தடுக்க. தனிப்பயன் எழுத்துரு மெதுவாக ஏற்றும்போது, உலாவி மாற்று எழுத்துருவுக்கு மாறி பின் மாற்றும், இது மாற்றத்தை ஏற்படுத்தும். font-display: optional தனிப்பயன் சரியான நேரத்தில் வரவில்லை என்றால், இடமாற்றத்தைத் தடுக்கிறது மற்றும் ஃபால்பேக் எழுத்துருவைப் பயன்படுத்துகிறது.

ஒரே ஸ்பிரிண்டில் CLS 0.25+-லிருந்து 0.03-ஆக மேம்படுவதைத் தொடர்ந்து கண்டுள்ளேன். இது மிக வேகமானது Core Web Vitals fix நீங்கள் பயன்படுத்தலாம். ஒரு வாடிக்கையாளரின் முகப்புப் பக்கத்தில் CLS 0.8 இருந்தது, ஏனெனில் செய்திமடல் பதிவு மோடல் ஒதுக்கப்பட்ட இடமின்றி மடிப்புக்கு மேலே செருகப்பட்டது. வெறுமனே நிலையான-உயர ஒதுக்கிட div சேர்த்ததும், CLS 0.01 ஆகக் குறைந்தது.

Core Web Vitals சரிசெய்தலுக்கான மேம்பட்ட Server-Side உகப்பாக்கங்கள்

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

TTFB மற்றும் சர்வர் பதில் நேரம்

மெதுவான Time to First Byte (TTFB) மற்ற அனைத்து அளவீடுகளையும் தடுக்கிறது. Lighthouse 95-க்கு, மொபைலில் (ஆய்வகம்) 600ms-க்குக் கீழும் களத் தரவில் 800ms-க்குக் கீழும் TTFB-ஐ இலக்காகக் கொள்ளுங்கள். HTML-ஐ உருவாக்கவே சர்வர் 1.2s எடுக்கும்போது படங்கள், ஸ்கிரிப்டுகளை மேம்படுத்தும் டெவலப்பர்களை அதிகம் பார்த்திருக்கிறேன்.

• edge caching-உடன் CDN பயன்படுத்தவும் (எ.கா., Cloudflare, Fastly) edge-லிருந்து நிலையான HTML பக்கங்களை வழங்க.
• Database வினவல்களை மேம்படுத்துங்கள் CMS அடிப்படையிலான தளங்களுக்குப் பக்க கேச் செருகுநிரலைப் பயன்படுத்துவதைக் கருத்தில் கொள்ளவும்.
• சர்வர்லெஸ் அல்லது எட்ஜ் செயல்பாடுகளைக் கருத்தில் கொள்ளுங்கள் முழு சர்வர்-பக்க செயலாக்கம் தேவைப்பட்ட மாறும் உள்ளடக்கத்திற்கு.

Preconnect மற்றும் DNS Prefetch

Add <link rel="dns-prefetch" href="//fonts.googleapis.com"> and <link rel="preconnect" href="https://fonts.googleapis.com" crossorigin> நீங்கள் இணைக்கவிருக்கும் மூலங்களைப் பற்றி உலாவிக்கு முன்கூட்டியே குறிப்பு தர. இது மூன்றாம் தரப்பு மூலங்களுக்கான ஆரம்ப இணைப்பு நேரத்தில் 400–600ms சேமிக்கும்.

HTTP/2 and HTTP/3

உங்கள் server HTTP/2 அல்லது (முன்னுரிமையாக) QUIC மீது HTTP/3-ஐ ஆதரிப்பதை உறுதி செய்யுங்கள். Multiplexing மற்றும் server push தாமதத்தைக் குறைக்கும், ஆனால் HTTP/3 அதிக packet இழப்புள்ள mobile network-களில் குறிப்பாகப் பயனுள்ளது.

நிஜ உலக வழக்கு ஆய்வு: ஒரு மின்வணிக Core Web Vitals சரிசெய்தல்

முழு ஈடுபாட்டையும் (engagement) உங்களுக்கு விளக்குகிறேன், அதன் மூலம் முறையியல் செயல்பாட்டில் இருப்பதைப் பார்க்கலாம்.

Client: மாதம் 200,000 அமர்வுகள் கொண்ட நடுத்தரச் சந்தை fashion e-commerce தளம்.
Baseline: Lighthouse செயல்திறன் மதிப்பெண் 58, LCP 4.8s, CLS 0.28, INP 820ms.
Timeline: 3 two-week sprints.

ஸ்பிரிண்ட் 1 – உள்கட்டமைப்பு மற்றும் படங்கள்:

• பட மேம்படுத்தலுடன் CDN-க்கு மாறியது (Cloudinary).
• மடிப்புக்குக் கீழே உள்ள அனைத்துப் படங்களையும் native lazy loading மூலம் lazy-load செய்தது (loading="lazy").
• முடிவு: LCP 2.4s ஆகக் குறைந்தது, ஆனால் Lighthouse மதிப்பெண் 72 மட்டுமே எட்டியது.

ஸ்பிரிண்ட் 2 – JavaScript மற்றும் INP:

• React தொகுப்பைக் குறியீடு-பிரித்தேன். முக்கியமற்ற கூறுகளை டைனமிக் இறக்குமதிகளுக்கு நகர்த்தினேன்.
• கனமான மூன்றாம் தரப்பு மதிப்புரை விட்ஜெட்டை இலகுவான தனிப்பயன் கூறுடன் மாற்றியது.
• GTM-ஐப் பின் ஏற்ற நகர்த்தியது onload via requestIdleCallback.
• முடிவு: INP 210ms ஆக மேம்பட்டது, Lighthouse மதிப்பெண் 89 ஐ எட்டியது.

ஸ்பிரிண்ட் 3 – CLS மற்றும் இறுதி மெருகு:

• அனைத்து தயாரிப்புப் படங்கள் மற்றும் iframe-களுக்கும் வெளிப்படையான அகலம்/உயரம் சேர்க்கப்பட்டது.
• Switched font to font-display: optional.
• ஒட்டும் தலைப்பு விளம்பரத்திற்கு ஒதுக்கப்பட்ட இடப்பிடிப்பு சேர்க்கப்பட்டது.
• முடிவு: CLS 0.02 ஆகக் குறைந்தது, Lighthouse மதிப்பெண் 96 ஐ எட்டியது, LCP 1.5s, INP 140ms.

Outcome: அடுத்த காலாண்டில் இயற்கை போக்குவரத்து 35% வளர்ந்தது. மொபைலில் பக்கங்கள் வேகமாக ஏற்றப்பட்டதால் மாற்று விகிதம் 12% அதிகரித்தது — துள்ளல் விகிதம் 62%-லிருந்து 51%-ஆகக் குறைந்தது.

This is the kind of Core Web Vitals fix உண்மையான முதலீட்டு வருவாயை வழங்கும். இது தணிக்கையில் தேர்வதைப் பற்றி மட்டுமல்ல; பயனர்களுக்காகவும் வணிகத்திற்காகவும் உங்கள் தளத்தை வலுப்படுத்துவது பற்றியது.

Lighthouse 95-ஐ எட்ட ஒரு டெவலப்பரின் பணிமுறை

எந்தப் பக்கத்திற்கும் இந்தச் செயல்முறையைப் பின்பற்றவும்:

1. Baseline Audit: தற்போதைய Lighthouse மதிப்பெண், களத் தரவு மற்றும் தனிப்பட்ட CWV அளவீடுகளைப் பதிவு செய்யுங்கள்.
2. Prioritize Issues: தாக்கத்தின் அடிப்படையில் வரிசைப்படுத்துங்கள். செயல்திறன் மதிப்பெண்ணில் LCP மற்றும் TBT (மொத்தத் தடுப்பு நேரம்) அதிக எடை கொண்டவை.
3. ஒரு நேரத்தில் ஒரு திருத்தத்தைப் பயன்படுத்துங்கள்: ஒவ்வொரு மாற்றத்திற்குப் பிறகும் Lighthouse-ஐ மீண்டும் இயக்குங்கள். இது சிக்கலான பிழைத்திருத்தத்தைத் தடுக்கிறது.
4. WebPageTest-ஆல் சரிபார்க்கவும்: இதில் 3G Slow சோதனையை இயக்குங்கள் WebPageTest ஃபிலிம்ஸ்ட்ரிப்பைப் பார்த்து உண்மையான பயனர் போன்ற முடிவுகளை உறுதிப்படுத்த.
5. பின்னடைவுகளைக் கண்காணிக்கவும்: உங்கள் CI/CD பைப்லைனில் Lighthouse CI-ஐ அமைக்கவும், இதனால் புதிய குறியீடு மதிப்பெண்ணை 90-க்குக் கீழே தள்ளாது. ஒவ்வொரு PR-க்கும் Lighthouse இயக்கி மதிப்பெண் மாற்றங்களுடன் கருத்திடும் GitHub Actions பணிப்பாய்வைப் பரிந்துரைக்கிறேன்.
6. உங்கள் முதல் 10 பக்கங்களுக்கு மீண்டும் செய்யவும்: முகப்புப் பக்கத்தை மட்டும் சரிசெய்யாதீர்கள். தயாரிப்பு, வகை மற்றும் landing பக்கங்களைச் சரிபார்க்கவும். Google root-ஐ மட்டுமல்ல, உங்கள் வலுவான பக்கக் குழுக்களை மதிப்பிடுகிறது.

Lighthouse 95-ஐத் தடுக்கும் பொதுவான தவறுகள்

அதே தவறுகளை மீண்டும் மீண்டும் பார்க்கிறேன்:

• தவறான அளவீட்டை மேம்படுத்துதல். உங்கள் TTFB 1.5s என்றால், எவ்வளவு படச் சுருக்கமும் LCP-ஐச் சரிசெய்யாது. முதலில் சர்வரைச் சரிசெய்யுங்கள்.
• ஒரு செருகுநிரலை நம்பியிருத்தல். ஆம், WP Rocket அல்லது பிற செருகுநிரல்கள் உதவ முடியும், ஆனால் அவை பெரும்பாலும் ரெண்டர்-தடுக்கும் CSS-ஐ அறிமுகப்படுத்துகின்றன. முக்கிய CSS-ஐ கையால் எழுதுவது எந்த செருகுநிரலையும் விடச் சிறந்தது.
• உண்மையான mobile சாதனங்களில் சோதிக்காதது. Lighthouse மொபைல் உருவகப்படுத்துதல் பரவாயில்லை, ஆனால் உண்மையான சாதனங்கள் வெப்பக் குறைப்பு மற்றும் நினைவகக் கட்டுப்பாடுகளை வெளிப்படுத்தும். எப்போதும் உண்மையான Moto G power அல்லது iPhone SE-இல் சோதிக்கிறேன்.
• மூன்றாம் தரப்பு script-களைப் புறக்கணித்தல். Google Tag Manager, Facebook Pixel மற்றும் பகுப்பாய்வுக் கருவிகள் முக்கிய தடைகளில் அடங்கும். அவற்றைத் தீவிரமாகத் தாமதப்படுத்துங்கள், பகுப்பாய்வு ஸ்கிரிப்டுகளைச் சொந்தமாக ஹோஸ்ட் செய்வதைப் பரிசீலியுங்கள்.
• Chasing 100. 95-ஐ எட்டியதும், மீதமுள்ள ஆதாயங்கள் குறைவே. நுண்-மேம்படுத்தல்களுக்குப் பதிலாக உண்மையான பயனர்களைப் பாதிக்கும் எல்லை நிகழ்வுகளில் (எ.கா., மெதுவான Wi-Fi, பழைய சாதனங்கள்) கவனம் செலுத்துங்கள்.

DG10 Agency உடன் ஏன் பணியாற்ற வேண்டும்

We’ve executed Core Web Vitals fix உயர் வளர்ச்சி சாஸ் முதல் பெரிய இ-காமர்ஸ் வரை 50 க்கும் மேற்பட்ட பிராண்டுகளுக்கான திட்டங்கள். எங்கள் டெவலப்பர்கள் ஆழமான தொழில்நுட்ப எஸ்சிஓ அறிவை முழு அடுக்கு பொறியியல் உடன் இணைக்கின்றனர். இதன் விளைவாக கோர் வெப் வைட்டல்களை கடந்து செல்வது மட்டுமல்லாமல், லைட்ஹவுஸ் 95 அனுபவத்தையும் வழங்குகிறது.

விரிவான performance audit-உடன் ஒவ்வொரு engagement-ஐயும் தொடங்குகிறோம் — field data, lab data மற்றும் waterfall analysis-ஐ map செய்கிறோம். பின் உங்கள் development cycle-களுடன் ஒத்துப்போகும் remediation sprint-களைத் திட்டமிடுகிறோம். Black magic இல்லை — code, configuration மற்றும் இடைவிடாத measurement மட்டும்.

உங்கள் தள performance-ஐ top percentile-க்குக் கொண்டு செல்லத் தயார் என்றால், let’s talk. எதை எதிர்பார்க்க வேண்டும் என்பதை நீங்கள் அறிய, எங்கள் சொந்த portfolio-விலிருந்து சரியான எண்களைக் காட்டுவோம்.

---

அடிக்கடி கேட்கப்படும் கேள்விகள்

நல்ல SEO-வுக்கு Lighthouse 100 தேவையா?

இல்லை. Lighthouse ஒரு lab proxy; green field Core Web Vitals-உடன் நிலையான 95+ rank செய்யப் போதுமானது. 100-ஐத் துரத்துவது பொதுவாகப் பராமரிப்பை எண்களுக்காக விட்டுக்கொடுக்கும் — எங்கள் client பணி 95+ green-ல் நின்று, மீதமுள்ள budget-ஐ content-ல் செலவிடும்.

நான் முதலில் எந்த அளவீட்டைச் சரிசெய்ய வேண்டும்: LCP, INP, அல்லது CLS?

ஆய்வக (lab) சோதனையில் தோல்வியுற்றதை அல்ல, களத் தரவில் (CrUX) தோல்வியுற்றதைச் சரிசெய்யுங்கள். பெரும்பாலான உள்ளடக்கத் தளங்களில் அது LCP — ஹீரோ பட மேம்படுத்தல் மற்றும் ரெண்டர்-தடுக்கும் ஸ்கிரிப்டுகள். செயலி போன்ற தளங்களில் அது INP — நீண்ட டாஸ்க்குகள் மற்றும் மேம்படுத்தப்படாத event handler-கள். CLS பொதுவாக மலிவானது: விளம்பரங்கள், உட்பொதிப்புகள் மற்றும் படங்களுக்கு இடம் ஒதுக்குங்கள்.

WordPress உண்மையில் Lighthouse 95-ஐ எட்ட முடியுமா?

ஆம், ஒழுக்கத்துடன்: சர்வர்-நிலை கேச்சிங், மெல்லிய தீம், வெளிப்படையான பரிமாணங்களுடன் CDN வழியாகக் கையாளப்படும் ஊடகம், மற்றும் ஒவ்வொரு காலாண்டிலும் செருகுநிரல் (plugin) தணிக்கைகள். ஸ்டேக்கை விட பேலோடு பட்ஜெட்டே முக்கியம் — ஸ்டேக்குகளை மாற்றுவது மேம்படுத்துவதை விடச் சிறந்தது எப்போது என்பதை எங்கள் WordPress-to-Next.js இடம்பெயர்வு வழிகாட்டி விளக்குகிறது.

Core Web Vitals சரிசெய்தல் எவ்வளவு காலம் எடுக்கும்?

வழக்கமான சந்தைப்படுத்தல் தளத்திற்கான குவிந்த சரிசெய்தல் ஸ்பிரிண்ட் இரண்டு முதல் நான்கு வாரங்கள்: ஒரு வாரம் கண்டறிதல், ஒன்று முதல் இரண்டு வாரம் சரிசெய்தல், ஒரு வாரம் களத் தரவு சரிபார்ப்பு. ஒவ்வொரு பக்க வகைக்கும் வார்ப்புருக்கள் கொண்ட நிறுவன பட்டியல்கள் ஆறு முதல் பத்து வாரங்கள் எடுக்கும்.

கள தரவும் ஆய்வக மதிப்பெண்களும் எப்போதாவது முரண்படுமா?

எப்போதும் — ஆய்வக இயக்கங்கள் உருவகப்படுத்தப்பட்ட மெதுவான சாதனத்தைப் பயன்படுத்தும், ஆனால் உங்கள் பார்வையாளர்கள் வேகமான ஃபோன்களிலோ அல்லது மோசமான ஹோட்டல் வைஃபையிலோ இருக்கலாம். 28-நாள் CrUX களத் தரவில் முடிவுகளை அடிப்படையாக்குங்கள்; தனிப்பட்ட சரிசெய்தல்களைச் சரிபார்க்க மட்டும் பயன்பாட்டிற்கு முன் Lighthouse ஆய்வக இயக்கங்களைப் பயன்படுத்தவும்.

DG10-இல் தொடர்ந்து படியுங்கள்

• Next.js vs WordPress for Enterprise
• WordPress முதல் Next.js இடம்பெயர்வு வழிகாட்டி
• போக்குவரத்தை அதிகரிக்க மேம்பட்ட SEO சேவைகள்

செயல்திறன் ஒரு ஒழுக்கம், திட்டம் அல்ல. அதை உங்களதாக்குங்கள்.