உங்கள் இணையதளத்தை வேகமாக்குவது எப்படி: நடைமுறைச் சரிபார்ப்புப் பட்டியல்

இணையதளத்தை வேகமாக்க, முதலில் PageSpeed Insights மூலம் அளவிடுங்கள், பின்னர் அது சுட்டிக்காட்டும் மிகப் பெரிய காரணத்தைச் சரிசெய்யுங்கள் - பெரும்பாலும் மிகப் பெரிய படங்கள், அதிக JavaScript, கனமான எழுத்துருக்கள் அல்லது மூன்றாம் தரப்பு ஸ்கிரிப்ட்கள். Google-இன் Core Web Vitals "நல்ல" இலக்குகளை நோக்கிச் செல்லுங்கள்: முக்கிய உள்ளடக்கம் 2.5 வினாடிகளுக்குள் தெரிய வேண்டும், தட்டல்களுக்குப் பதில் 200 மில்லி விநாடிகளுக்குள், மற்றும் கிட்டத்தட்ட எந்த அமைப்புத் தாவலும் இருக்கக்கூடாது. பெரும்பாலான தளங்கள் ஒரு சில மாற்றங்களால் அங்கே செல்கின்றன; முழுவதுமாக மீண்டும் எழுத வேண்டியதில்லை.

எதையும் மாற்றுவதற்கு முன் அளவிடுங்கள்

ஊகிப்பது நேரத்தை வீணாக்கும். இரண்டு இலவசக் கருவிகள் பெரும்பாலானவர்களுக்குப் போதும்:

• PageSpeed Insights (pagespeed.web.dev) - ஒரு நேரடி URL-ஐ ஒட்டுங்கள். உண்மையான Chrome பயனர்களிடமிருந்து field data (உங்கள் தளத்திற்குப் போதுமான போக்குவரத்து இருந்தால்) மற்றும் உருவகப்படுத்திய ஏற்றத்திலிருந்து lab data காட்டும், குறிப்பிட்ட பிரச்சினைகளின் பட்டியலுடன்.
• Chrome DevTools-இல் Lighthouse - திறக்கக்கூடிய எந்தப் பக்கத்திலும், முன்னோட்டம் உட்பட, அதே ஆய்வக சோதனை. கைப்பேசி பயன்முறையில் சோதியுங்கள்; மெதுவான நெட்வொர்க்குகளில் உள்ள கைப்பேசிகளில்தான் பிரச்சினைகள் தெரியும்.

முக்கியமான எண்கள் Google-இன் Core Web Vitals. செப்டம்பர் 2026 நிலவரப்படி, web.dev-இல் உள்ள Google-இன் ஆவணம் பக்க ஏற்றங்களின் 75வது சதவீதத்தில் அளக்கப்படும் இந்த "நல்ல" வரம்புகளைத் தருகிறது:

INP, 2024-இல் பழைய First Input Delay அளவீட்டை மாற்றியது. ஒரு கருவி இன்னும் FID-ஐ அறிவித்தால், அது காலாவதியானது.

உங்கள் தொடக்க எண்களை எழுதி வையுங்கள். ஒவ்வொரு சரிசெய்தலுக்குப் பின்னும் மீண்டும் சோதியுங்கள், எது உதவியது என்று தெரிந்துகொள்ள.

நேரம் எங்கே போகிறது: வழிகளும் பரிமாற்றங்களும்

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

படங்கள்

படங்கள்தான் மிகவும் பொதுவான பிரச்சினை, சரிசெய்வதும் எளிது. 4,000 பிக்சல் புகைப்படம் 800 பிக்சல் அகலத்தில் காட்டப்பட்டால், ஒவ்வொரு பார்வையாளரும் அவர்கள் பார்க்கும் அளவை விட ஐந்து மடங்கு அதிகமாகப் பதிவிறக்குகிறார்கள்.

• படங்களை அவை காட்டப்படும் அளவிலேயே வழங்குங்கள், கைப்பேசி மற்றும் டெஸ்க்டாப்புக்கு பதிலளிக்கும் srcset அளவுகளுடன்.
• நவீன வடிவங்களையும் (WebP அல்லது AVIF) நியாயமான அழுத்தத்தையும் பயன்படுத்துங்கள்.
• ஒவ்வொரு படத்திலும் width மற்றும் height அமையுங்கள், இதனால் உலாவி இடத்தை ஒதுக்கும். இதுவே பெரும்பாலான அமைப்பு நகர்வைச் சரிசெய்யும்.
• மடிப்புக்குக் கீழே உள்ள படங்களை loading="lazy" மூலம் lazy-load செய்யுங்கள்.
• பக்கத்தின் மேலே உள்ள முக்கிய படத்தை ஒருபோதும் lazy-load செய்யாதீர்கள். Google-இன் LCP வழிகாட்டுதல் இதில் தெளிவாக உள்ளது: LCP படத்தை lazy-load செய்வது அதை எப்போதும் தாமதப்படுத்தும். அதற்கு பதிலாக fetchpriority="high" கொடுங்கள்.

JavaScript

AI-ஆல் கட்டப்பட்ட பல தளங்கள் ஒற்றைப்-பக்க ஆப்கள் (SPA): உலாவி ஒரு JavaScript தொகுப்பைப் பதிவிறக்கி பின்னர் பக்கத்தை வரைகிறது. தொகுப்பு பெரிதாக இருந்தால், வெற்றுத் திரை நீடிக்கும். முயற்சியின் வரிசையில் சரிசெய்தல்கள்:

1. பயன்படுத்தாதவற்றை நீக்குங்கள். சார்புகளின் பட்டியலைக் கேளுங்கள்; ஒருமுறை சேர்க்கப்பட்டு மறக்கப்பட்ட நூலகங்களை நீக்குங்கள் - ஒரு தேதிக்காக ஒரு முழு date நூலகம், ஐந்து ஐகான்களுக்காக ஒரு முழு icon தொகுப்பு.
2. பாதைக்கு ஏற்ப பிரிக்கவும். நிர்வாக டாஷ்போர்டை யாராவது திறக்கும்போது மட்டும் அதன் கோடை ஏற்றுங்கள், முகப்புப் பக்கத்தில் அல்ல.
3. பொதுப் பக்கங்களை முன்-ரெண்டர் செய்யுங்கள். JavaScript இயங்குவதற்கு முன்பே உண்மையான HTML ஆக வரும் ஒரு சந்தைப்படுத்தல் பக்கம் தோன்றும். இது தேடுபொறிகளுக்கும் உதவும்; AI-ஆல் கட்டப்பட்ட இணையதளங்களுக்கான SEO பாருங்கள்.

மெதுவான INP பெரும்பாலும் ஒரு நீண்ட பணி பக்கத்தைத் தடுப்பதைக் குறிக்கும் - ஒவ்வொரு விசையழுத்தத்திலும் பெரிய பட்டியலை வடிகட்டுவது, அல்லது ஒரு கலம் மாறும்போது முழு அட்டவணையையும் மீண்டும் ரெண்டர் செய்வது. Chrome DevTools-இன் Performance பலகம் எது என்று காட்டும்.

எழுத்துருக்கள்

ஒவ்வொரு எழுத்துக் குடும்பமும் எடையும் ஒரு கோப்பு. இரண்டு குடும்பங்களும் மூன்று நான்கு எடைகளும் பொதுவாகப் போதும். மடிப்புக்கு மேலுள்ள எழுத்துருவை preload செய்யுங்கள், உரை உடனே தெரிய font-display: swap பயன்படுத்துங்கள், வெளிப்புற எழுத்துரு சேவை உங்கள் பார்வையாளர்களுக்கு மெதுவாக இருந்தால் எழுத்துருக்களை நீங்களே ஹோஸ்ட் செய்யுங்கள்.

மூன்றாம் தரப்பு ஸ்கிரிப்ட்கள்

Chat விட்ஜெட்கள், பகுப்பாய்வு, heatmap-கள், விளம்பர pixel-கள், உட்பொதிக்கப்பட்ட வீடியோக்கள், சமூக ஊட்டங்கள் எல்லாம் மற்ற சேவையகங்களிலிருந்து கோடை ஏற்றுகின்றன. ஒவ்வொன்றும் சிறியதாகத் தெரியும்; சேர்த்துப் பார்த்தால் பெரும்பாலும் பக்கத்தின் மெதுவான பகுதி அவைதான். நீங்கள் உண்மையில் பார்ப்பவற்றை வைத்திருங்கள். மற்றவற்றைப் பக்கம் செயல்படத் தொடங்கிய பின் ஏற்றுங்கள்; YouTube பிளேயர், வரைபடம் போன்ற கனமான உட்பொதிவுகளை, கிளிக்கில் உண்மையானதை ஏற்றும் ஒரு இலகுவான முன்னோட்டத்தால் மாற்றுங்கள்.

சர்வர் பதில்

Time to first byte (TTFB) - சர்வர் பதிலளிக்கத் தொடங்க எவ்வளவு நேரம் எடுக்கிறது - மற்ற எல்லா அளவீடுகளுக்கும் அடியில் உள்ளது. CDN (உங்கள் பார்வையாளர்களுக்கு அருகிலுள்ள சர்வர்களின் வலையமைப்பு; CDN என்றால் என்ன பாருங்கள்) மூலம் வழங்கப்படும் நிலையான பக்கங்கள் எல்லா இடங்களிலும் வேகமாக இருக்கும். ஒவ்வொரு கோரிக்கையிலும் ஒரு சர்வர் உருவாக்கும் பக்கங்கள் அந்த சர்வரையும் அதன் டேட்டாபேஸையும் சார்ந்திருக்கும். Caching மூலம் மீண்டும் மீண்டும் நடக்கும் வேலையைத் தவிர்ப்பது, மெதுவான வினவல்களுக்கு டேட்டாபேஸ் indexes சேர்ப்பது ஆகியவை வழக்கமான தீர்வுகள்.

வேலை செய்யும் கேள்விகள்

குறிப்பாக இருங்கள்: பக்கம், அளவீடு, கட்டுப்பாடு ஆகியவற்றைக் குறிப்பிடுங்கள். உங்களிடம் PageSpeed Insights கண்டுபிடிப்புகள் இருந்தால் அவற்றை ஒட்டுங்கள்.

PageSpeed Insights, முகப்புப் பக்கத்திற்கு கைப்பேசியில் 4.8 வி LCP-ஐக் காட்டுகிறது, LCP உறுப்பு hero படம். Hero படத்தின் அளவை மாற்றி WebP ஆக மாற்றுங்கள், பதிலளிக்கும் அளவுகளை வழங்குங்கள், width மற்றும் height அமையுங்கள், fetchpriority="high" கொடுங்கள், அது lazy-load ஆகாமல் பாருங்கள். மடிப்புக்குக் கீழ் உள்ள ஒவ்வொரு படத்தையும் lazy-load செய்யுங்கள். வடிவமைப்பை மாற்றாதீர்கள்.

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

/products-இல் தேடல் பெட்டி மெதுவாக உணர்கிறது. வடிகட்டலை debounce செய்யுங்கள், ஒவ்வொரு விசையழுத்தத்திலும் முழுப் பட்டியலையும் மீண்டும் ரெண்டர் செய்வதைத் தவிர்க்கவும், பட்டியலில் 200-க்கு மேல் உருப்படிகள் இருந்தால் பக்கங்களாகப் பிரிக்கவும் அல்லது virtualise செய்யவும்.

படிப்படியாக

1. நேரடிப் பக்கத்தை சோதியுங்கள் PageSpeed Insights-இல் கைப்பேசி பயன்முறையில். LCP, INP, CLS, பட்டியலிடப்பட்ட முதல் மூன்று பிரச்சினைகளைக் குறித்துக்கொள்ளுங்கள்.
2. படங்களை முதலில் சரிசெய்யுங்கள்: அளவுகள், வடிவங்கள், பரிமாணங்கள், மடிப்புக்குக் கீழ் lazy loading, hero-வுக்கு முன்னுரிமை.
3. நீங்கள் பயன்படுத்தாத மூன்றாம் தரப்பு ஸ்கிரிப்ட்களை வெட்டுங்கள், மற்றவற்றை தாமதமாக ஏற்றுங்கள்.
4. எழுத்துருக்களைக் வடிவமைப்புக்குத் தேவையானதற்கு குறையுங்கள்.
5. JavaScript-ஐக் குறையுங்கள்: பயன்படுத்தாத தொகுப்புகளை நீக்குங்கள், பாதைக்கு ஏற்பப் பிரியுங்கள்.
6. பொதுப் பக்கங்கள் இன்னும் கிளையண்டில் ரெண்டர் ஆகின்றன என்றும், LCP இன்னும் மெதுவாக இருந்தாலும் அவற்றை முன்-ரெண்டர் செய்யுங்கள்.
7. சர்வரைச் சரிபாருங்கள்: caching, டேட்டாபேஸ் indexes, அரிதாக மாறும் உள்ளடக்கத்திற்கு நிலையான ஹோஸ்டிங்.
8. மீண்டும் வெளியிட்டு மீண்டும் சோதியுங்கள். PageSpeed Insights-இல் field data, உண்மையான வருகைகள் வரும்போது வாரங்களில் புதுப்பிக்கப்படும்; எனவே ஆரம்ப முடிவுகளை lab data-வின் அடிப்படையில் மதிப்பிடுங்கள்.

பொதுவான தவறுகள்

• வேகமான லேப்டாப்பில் மட்டும் சோதிப்பது. உங்கள் பார்வையாளர்கள் நடுத்தர விலை கைப்பேசிகளிலும் நிலையற்ற மொபைல் டேட்டாவிலும் இருப்பார்கள். கைப்பேசி பயன்முறையில் சோதியுங்கள்.
• சரியான 100-ஐத் துரத்துவது. ஆய்வக மதிப்பெண் ஒரு வழிகாட்டி மட்டுமே. Core Web Vitals நல்ல வரம்பில் வந்ததும், கடைசி சில புள்ளிகளை விட உள்ளடக்கமும் பயன்பாட்டுத்தன்மையும் முக்கியம்.
• எல்லாவற்றையும் lazy-load செய்வது, hero படம் உட்பட. அது LCP-ஐ மோசமாக்கும்.
• மேல் ஒரு வேக plugin அல்லது நூலகத்தைச் சேர்ப்பது. எடையைக் குறைப்பது, அதை நிர்வகிக்க கோடு சேர்ப்பதை எப்போதும் வெல்லும்.
• நேரடித் தளத்தை அல்ல, முன்னோட்டத்தை மேம்படுத்துவது. மேம்பாட்டு முன்னோட்டங்கள் மேம்படுத்தப்படாத build-களை இயக்கும். வெளியிடப்பட்ட URL-ஐ அளவிடுங்கள்.
• வேகத்தை ஒருமுறை மட்டும் சரிசெய்வது. ஒவ்வொரு புதிய widget, படம், அம்சமும் எடை சேர்க்கும். பெரிய மாற்றங்களுக்குப் பிறகு மீண்டும் சோதியுங்கள்.

வேகச் சரிபார்ப்புப் பட்டியல்

• கைப்பேசியில் LCP ≤ 2.5 வி, INP ≤ 200 மி.வி, CLS ≤ 0.1
• படங்கள் அளவு மாற்றப்பட்டு, அழுத்தப்பட்டு, நவீன வடிவத்தில், width மற்றும் height உடன்
• Hero படம் lazy-load ஆகவில்லை; மடிப்புக்குக் கீழ் உள்ள படங்கள் lazy-load ஆகின்றன
• பயன்படுத்தாத JavaScript நூலகங்கள் இல்லை; கனமான பாதைகள் தனியாகப் பிரிக்கப்பட்டுள்ளன
• இரண்டு எழுத்துக் குடும்பங்கள் அல்லது குறைவு, முதன்மை எழுத்துரு preload
• நீங்கள் உண்மையில் பயன்படுத்தும் மூன்றாம் தரப்பு ஸ்கிரிப்ட்கள் மட்டும், தாமதமாக ஏற்றப்படுகின்றன
• பொதுப் பக்கங்கள் முன்-ரெண்டர் அல்லது முடிந்தவரை நிலையானவை
• வெளியிட்ட பிறகு நேரடி URL-இல் மீண்டும் சோதிக்கப்பட்டது

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

Mythex-இல் வேகம்

Mythex-இல் இந்த மாற்றங்களை நீங்கள் அரட்டையில் கேட்டுச் செய்கிறீர்கள், அல்லது Pro-வில் code editor-இல். Preview ஒரு development சர்வரை இயக்குவதால், Preview அல்ல, வெளியிடப்பட்ட URL-ஐச் சரிபாருங்கள். நிலையான முன்-முனைகள் வெளியிடும்போது நிலையான தளங்களாகவே வெளியாகின்றன (நிலையான இணையதளங்கள்), இது உள்ளடக்கப் பக்கங்களுக்குப் பொருந்தும். சர்வருடன் உள்ள ஆப்கள் பூஜ்ஜியத்திற்கு அளவிடப்படுகின்றன: செயலற்றிருக்கும்போது உறங்கி, அடுத்த வருகையில் விழித்தெழுகின்றன; எனவே அமைதியான ஒரு இடைவெளிக்குப் பிறகு முதல் கோரிக்கை மெதுவாக இருக்கும், இணைக்கப்பட்ட டேட்டாபேஸ் 5 நிமிட செயலற்ற நிலைக்குப் பிறகு உறங்கும் (ஹோஸ்டிங் வரம்புகள்). ஒரு பொதுப் பக்கம் முதல் வருகையில் மட்டும் மெதுவாக இருந்தால், அதுதான் சாத்தியமான காரணம். பொதுப் பக்கங்களை நிலையானதாக வைத்திருப்பது உதவும். மாற்றங்களுக்குப் பிறகு மீண்டும் வெளியிட்டு, கடினமாக மீண்டும் ஏற்றுங்கள்.

கேள்விகள்