பத்து வலைத் திட்டங்களில் ஒன்பதை முடக்கும் ஐகான் செயல்திறன் பிரச்சினை

சில வாரங்களுக்கு முன்பு, பன்னிரண்டு சீரற்ற திறந்த மூல ஃபிரண்ட்எண்ட் (frontend) களஞ்சியங்களை (repos) ஆய்வு செய்து, ஒவ்வொன்றும் எவ்வாறு ஐகான்களை வழங்குகின்றன என்பதைச் சரிபார்க்க ஒருவர் தீர்மானித்தார். பார்வை வடிவமைப்பு அல்ல—உண்மையான விநியோக வழிமுறை. முடிவுகள் ஆச்சரியமளிக்கும் வகையில் ஒரே மாதிரியாக இருந்தன, மேலும் செயல்திறன் வரம்புகள் சுருங்கி, பயனர்கள் எல்லா இடங்களிலும் வேகமான இடைமுகங்களை எதிர்பார்க்கும் இன்றைய நாளில் (ஜூன் 30, 2026) இது எப்போதையும் விட மிகவும் முக்கியமானது.

இப்போது ஏன் இதைப் பற்றி கவலைப்பட வேண்டும்? ஏனெனில் ஐகான் விநியோகம் என்பது மக்கள் பெரும்பாலும் புறக்கணிக்கும் "கண்ணுக்குத் தெரியாத" உகப்பாக்கங்களில் (optimizations) ஒன்றாகும். பெரும்பாலான செயல்திறன் சரிபார்ப்புப் பட்டியல்கள் JavaScript பண்டில் அளவு அல்லது பட உகப்பாக்கத்தில் கவனம் செலுத்துகின்றன, ஆனால் ஐகான்கள் அமைதியாக தணிக்கை செய்யப்படாமல் விடுபடுகின்றன. பன்னிரண்டு திட்டங்களில் ஒன்பதில் அதே சிக்கல் இருந்தபோது, அது கவனிக்கப்பட வேண்டிய ஒரு சமிக்ஞையாகும்.

எல்லோருக்கும் ஏற்கனவே தெரிந்த வழக்கமான காரணங்கள்

பெரும்பாலான உருவாக்கலர்கள் (developers) ஏற்கனவே தவிர்க்கக் கற்றுக்கொண்டவற்றில் இருந்து தொடங்குவோம்.

Icon fonts (Font Awesome பற்றி யோசித்துப் பாருங்கள்) பெரிய கோப்புகளை ஈர்க்கின்றன—பெரும்பாலும் 20+ KB, சில சமயங்களில் அதற்கு மேல். சில ஐகான்களை மட்டுமே பயன்படுத்த நீங்கள் முழு எழுத்துருவையும் வழங்குகிறீர்கள். ஆம், உலாவிகள் (browsers) அவற்றை தற்காலிக நினைவகத்தில் (cache) சேமிக்கின்றன, ஆனால் நீங்கள் பயன்படுத்துவதற்கும் வழங்குவதற்கும் இடையிலான ஒப்பீடு சிறந்தது அல்ல. பெரும்பாலான குழுக்கள் இப்போது இதைப் புரிந்து கொண்டுள்ளன.

Inline SVG நவீன தீர்வாகத் தோன்றியது: நீங்கள் SVG குறியீட்டை நேரடியாக உங்கள் HTML இல் உட்படுத்துகிறீர்கள். கூடுதல் HTTP கோரிக்கை இல்லை, ஸ்டைலிங் மீது முழு கட்டுப்பாடு. ஆனால் inline SVG இல் யாரும் அதிகம் பேசாத ஒரு குறைபாடு உள்ளது: ஒவ்வொரு பக்கமும் அதே குறியீடாக இருந்தாலும், ஒவ்வொரு பக்க ஏற்றமும் (page load) அந்தக் குறியீட்டை மீண்டும் பாகுபடுத்தி (re-parses) மீண்டும் ரெண்டர் (re-renders) செய்கிறது. இது உங்கள் HTML அளவையும் பெரிதாக்குகிறது, இது பாகுபடுத்துதலையும் DOM உருவாக்கத்தையும் தாமதப்படுத்துகிறது.

Sprite sheets (பல ஐகான்களைக் கொண்ட ஒரு பெரிய SVG அல்லது PNG) HTTP கோரிக்கைகளைக் குறைக்கின்றன, ஆனால் படத்தின் சரியான பகுதியை பிரித்தெடுப்பது சிக்கலை அதிகரிக்கிறது. மேலும் இது செயல்பட உங்களுக்கு ஒரு பில்ட் படி (build step) அல்லது ரன்டைம் லைப்ரரி (runtime library) தேவை.

Base64 encoding SVGs அல்லது PNGs ஐ நேரடியாக CSS அல்லது தரவுப் பண்புகளில் (data attributes) குறியாக்கம் செய்வதா? இது தற்காலிக சேமிப்பை (caching) பாதிக்கிறது என்பதை நீங்கள் உணரும் வரை வசதியாகத் தோன்றும். ஒவ்வொரு ஸ்டைல்ஷீட் மாற்றமும் ஒவ்வொரு ஐகானையும் மீண்டும் அனுப்புகிறது.

உண்மையில் விஷயங்களை முடக்கும் அமைப்பு

ஆய்வில் கண்டறியப்பட்டது இதோ: பெரும்பாலான திட்டங்கள் ஐகான் அமைப்புகளை பயன்பாட்டுக் குறியீட்டுடன் (application code) பண்டில் செய்யும் விதத்தில் வழங்குகின்றன.

நீங்கள் ஒரு டேஷ்போர்டை உருவாக்குகிறீர்கள் என்று வைத்துக்கொள்வோம். உங்களிடம் ஒரு Icon கூறு (component) உள்ளது. அந்தக் கூறு உங்கள் அனைத்து SVG ஐகான்களையும் இறக்குமதி செய்கிறது—அல்லது ஒரு பெரிய பொருளில் இருந்து (massive object) அவற்றைக் குறிப்பிடுகிறது. தயாரிப்பிற்காக (production) நீங்கள் பில்ட் செய்யும் ஒவ்வொரு முறையும், உங்கள் பண்ட்லர் (bundler) ஒவ்வொரு ஐகான் கோப்பையும் செயலாக்கி, உகப்பாக்கி, உங்கள் முதன்மை JavaScript இல் பண்டில் செய்கிறது. ஐகான்கள் உங்கள் முக்கிய பாதையின் (critical path) ஒரு பகுதியாக மாறுகின்றன.

நடைமுறையில் இதன் பொருள் என்ன?

ஒன்று: உங்கள் JavaScript ஏறி இயங்கும் வரை உலாவியால் ஐகானைப் பயன்படுத்த முடியாது. 500 KB பண்டிலில் 200 KB ஐகான்களை உட்பொதித்து அனுப்பினால், பயனர்கள் நீண்ட நேரம் வெற்றுப் பக்கத்தைப் பார்ப்பார்கள். ஸ்கிரிப்ட் பாகுபடுத்துதலில் ஐகான் ரெண்டரிங் தடுக்கப்படுகிறது.

இரண்டு: ஐகான் மாற்றங்களுக்கும் குறியீட்டு மாற்றங்களுக்கும் இடையே தற்காலிக சேமிப்பு அழிப்பு (cache-busting) வேறுபாடு எதுவும் இல்லை. நீங்கள் ஒரு ஐகானின் நிறத்தை மாற்றுகிறீர்களா? உங்கள் முழு பண்டில் ஹேஷும் (bundle hash) மாறுகிறது. பயனர்கள் எல்லாவற்றையும் மீண்டும் பதிவிறக்குகிறார்கள்.

மூன்று: பயன்படுத்தப்படாத ஐகான்களும் வழங்கப்படுகின்றன. பயன்படுத்தப்படாத JavaScript செயல்பாடுகளை ட்ரீ-ஷேக்கிங் (tree-shaking) செய்வதில் பண்ட்லர்கள் சிறந்தவை, ஆனால் ஒரு பெரிய மேனிஃபெஸ்ட்டில் குறிப்பிடப்பட்டுள்ள பயன்படுத்தப்படாத SVG கோப்புகளில் அல்ல. அந்த சுமையை நீங்களே சுமக்கிறீர்கள்.

நான்கு: ஐகான்கள் ரெண்டரிங்கைத் தடுப்பவையாக (render-blocking) மாறுகின்றன. மெதுவான நெட்வொர்க்குகளில், முழு பண்டிலும் வரும் வரை காத்திருப்பது என்பது ஐகான்களுக்காகவும் காத்திருப்பதாகும். அவை ஒரு தனி வளத்தில் இணையாக (in parallel) ஏற்றப்படுவதில்லை; அவை ஸ்கிரிப்டுக்குப் பின்னால் வரிசைப்படுத்தப்படுகின்றன.

சிறந்த அமைப்பு: குறியீட்டிலிருந்து ஐகான்களைப் பிரித்தல்

நன்றாகச் செயல்பட்ட திட்டங்கள் ஒரு விஷயத்தை வித்தியாசமாகச் செய்தன: அவை பயன்பாட்டு JavaScript இலிருந்து ஐகான்களைத் தனியாக வழங்கின.

வெளிப்புற SVG கோப்புகளாக. ஐகான் இது போன்ற ஒரு URL இல் உள்ளது /assets/icons/check.svg. தேவைப்படும்போது உலாவி அதைக் கோருகிறது, சுயாதீனமாக தற்காலிக நினைவகத்தில் சேமிக்கிறது, மேலும் மற்ற நிலையான சொத்துகளைப் (static asset) போலக் கருதுகிறது. பில்ட் நேரத்தில் HTML இல் ஐகானை இன்லைன் செய்யலாம் அல்லது ரன்டைமில் லேசி-லோட் (lazy-load) செய்யலாம். எதுவாக இருந்தாலும், அது உங்கள் பயன்பாட்டுக் குறியீட்டுடன் பண்டில் செய்யப்படாது.

இது ஏன் வேலை செய்கிறது?

• இணை ஏற்றம் (Parallel loading). ஐகான்கள் தங்களின் சொந்த நேரக்கட்டுப்பாட்டில் பெறப்படுகின்றன, JavaScript ஆல் தடுக்கப்படுவதில்லை.
• தற்காலிக சேமிப்பு தனிமைப்படுத்தல் (Cache isolation). உங்கள் ஐகானை மாற்றினால் அந்த ஐகான் மட்டுமே மீண்டும் பதிவிறக்கப்படும். உங்கள் பயன்பாட்டு பண்டில் பாதிக்கப்படாது.
• பில்ட் திறன் (Build efficiency). உங்கள் பண்ட்லர் ஐகான்களைச் செயலாக்குவதில்லை. இது குறியீட்டில் கவனம் செலுத்துகிறது. வேகமான பில்ட்கள்.
• விருப்பப் பூர்வமான லேசி-லோட் (Optional lazy-load). சில ஐகான்கள் சில ஓட்டங்களில் (flows) மட்டுமே தோன்றும். முன்பே ஏற்றுவதற்குப் பதிலாகத் தேவைக்கேற்ப அவற்றை ஏற்றலாம்.

உங்கள் சொந்த திட்டத்தை எவ்வாறு தணிக்கை செய்வது

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

படி 1: ஐகான்கள் எங்கு வரையறுக்கப்பட்டுள்ளன என்பதைக் கண்டறியவும்

உங்கள் கோட்பேஸில் (codebase), ஒரு Icon கூறு அல்லது ஒரு மைய ஐகான் கோப்பைத் தேடுங்கள். அது src/components/Icon.tsx, src/icons/index.tsஇல் அல்லது இதே போன்ற இடத்தில் இருக்கலாம். உங்கள் அனைத்து SVG ஐகான்களையும் இறக்குமதி செய்யும் அல்லது குறிப்பிடும் கோப்புகளைத் தேடுங்கள்.

படி 2: எது பண்டில் செய்யப்படுகிறது என்பதைச் சரிபார்க்கவும்

தயாரிப்பிற்காக (production) உங்கள் திட்டத்தை பில்ட் செய்து வெளியீட்டு பண்டிலை ஆய்வு செய்யுங்கள். இது போன்ற ஒரு கருவியைப் பயன்படுத்துங்கள் webpack-bundle-analyzer அல்லது உங்கள் சோர்ஸ் மேப்புகளைப் (source maps) பாருங்கள். உங்கள் ஐகான்கள் JavaScript பண்டிலுக்குள் தோன்றுமா அல்லது அவை வெளிப்புற கோப்புகளா?

பண்டிலில் SVG உள்ளடக்கம் குறியாக்கம் செய்யப்பட்டிருப்பதை நீங்கள் கண்டால், அந்த அமைப்பைக் கண்டுபிடித்துவிட்டீர்கள் என்று அர்த்தம்.

படி 3: ஏற்றும் நேரப் பாதிப்பை அளவிடுங்கள்

மெதுவான 3G இணைப்பில் உங்கள் பயன்பாட்டை ஏற்றவும் (browser DevTools இல் throttle செய்யவும்). Network டேபைக் கவனியுங்கள். எந்த ஐகான்களும் தோன்றுவதற்கு முன் உங்கள் முதன்மை JavaScript பண்டில் முடிவடைகிறதா? ஆம் என்றால், உங்கள் ஐகான்கள் பண்டில் செய்யப்பட்டுத் தடுக்கப்படுகின்றன.

படி 4: தற்காலிக சேமிப்பு நடத்தையைச் சரிபார்க்கவும்

ஒரு ஐகானில் சிறிய மாற்றம் செய்யுங்கள் (நிறத்தை மட்டும் மாற்றுவது கூட). மீண்டும் பில்ட் செய்து வரிசைப்படுத்துங்கள் (deploy). முன்னும் பின்னும் உள்ள பண்டில் ஹேஷை ஒப்பிடுக. முழு பயன்பாட்டு பண்டில் ஹேஷும் மாறினால், ஐகான்கள் உங்கள் குறியீட்டுடன் பிணைக்கப்பட்டுள்ளன.

அதை எவ்வாறு சரிசெய்வது

படி 1: ஐகான்களை ஒரு தனி கோப்பகத்திற்கு நகர்த்தவும்

இது போன்ற ஒரு கோப்புறையை (folder) உருவாக்கவும் public/icons/ (நிலையான சொத்து கோப்பகத்தைப் பயன்படுத்தினால்) அல்லது src/assets/icons/. ஒவ்வொரு ஐகானையும் அதன் சொந்த SVG கோப்பாக சேமிக்கவும்: check.svg, close.svg, arrow.svg, மற்றும் பல. அவற்றை உங்கள் கூறுக் குறியீட்டிலிருந்து (component code) தனியாக வைத்திருங்கள்.

படி 2: உங்கள் ஐகான் கூறைப் புதுப்பிக்கவும்

SVG உள்ளடக்கத்தை இறக்குமதி செய்வதற்குப் பதிலாக, கோப்புப் பெயரால் ஐகானைக் குறிப்பிடவும்:

function Icon({ name, size = 24 }) {
  return <img src={`/icons/${name}.svg`} alt={name} width={size} height={size} />;
}

அல்லது உங்களுக்கு SVG ஸ்டைலிங் (நிறம் அல்லது ஸ்ட்ரோக் மாற்றங்கள் போன்றவை) தேவைப்பட்டால்:

function Icon({ name, size = 24, color = 'currentColor' }) {
  return <svg width={size} height={size} className="icon"><use href={`/icons/${name}.svg#${name}`} /></svg>;
}

படி 3: தயாரிப்பிற்காக SVGகளை உகப்பாக்குங்கள்

இது போன்ற ஒரு கருவியின் மூலம் உங்கள் ஐகான்களை இயக்குங்கள் svgo (ஒரு கட்டளை வரி உகப்பாக்கி). இது பயன்படுத்தப்படாத மெட்டாடேட்டாவை அகற்றி, பாதைகளை எளிமையாக்கி, தோற்றத்தை மாற்றாமல் கோப்பின் அளவைச் சுருக்குகிறது.

npx svgo public/icons/*.svg

படி 4: சோதனை செய்து அளவிடவும்

தயாரிப்பிற்காக பில்ட் செய்யுங்கள். பண்டில் அளவை ஆய்வு செய்யுங்கள்—அது சுருங்க வேண்டும். மெதுவான இணைப்பில் பயன்பாட்டை ஏற்றவும். உங்கள் முழு JavaScript ஏறிய பிறகு அல்லாமல், அவற்றின் HTTP கோரிக்கைகள் முடிவடைந்தவுடன் ஐகான்கள் தோன்ற வேண்டும்.

முடிவுரை

ஐகான் விநியோகம் என்பது பெரும்பாலும் சிக்கல் வரும் வரை கண்ணுக்குத் தெரியாமல் இருக்கும். பயன்பாட்டுக் குறியீட்டுடன் ஐகான்களை பண்டில் செய்வது, சுயாதீனமாக இருக்க வேண்டிய இரண்டை ஒன்றாக இணைக்கிறது: உங்கள் குறியீட்டு மாற்றங்கள் மற்றும் உங்கள் காட்சி சொத்துகள் (visual assets). ஐகான்களைத் தனித்தனி நிலையான கோப்புகளாக வழங்குவதன் மூலம் அவற்றைப் பிரிப்பது—குறைந்த முயற்சியுடன் செயல்திறன், தற்காலிக சேமிப்பு மற்றும் பில்ட் நேரங்களை மேம்படுத்துகிறது. பெரும்பாலான அதிக செயல்திறன் கொண்ட திட்டங்கள் இதை இயல்பாகவே செய்கின்றன; ஏன் என்று இப்போது உங்களுக்குத் தெரியும்.

நன்மைகள்

• ஐகான்கள் பயன்பாட்டுக் குறியீட்டிற்குப் பிறகு வரிசையாக அல்லாமல், அதனுடன் இணையாக (in parallel) ஏற்றப்படுகின்றன.
• ஒரு ஐகானை மாற்றுவது உங்கள் முழு பயன்பாட்டு பண்டில் கேஷையும் (bundle cache) செல்லாததாக்காது.
• சிறிய பயன்பாட்டு JavaScript பண்டில்கள் வேகமாக பாகுபடுத்தப்பட்டு இயக்கப்படுகின்றன.
• ஐகான்கள் உங்கள் பண்ட்லரால் செயலாக்கப்படாததால் பில்ட் நேரங்கள் மேம்படுகின்றன.
• புதிய ஐகான்களைச் சேர்ப்பது எளிது—கோப்பகத்தில் ஒரு SVG கோப்பை போட்டால் போதும்.
• விருப்பப் பூர்வமான UI ஓட்டங்களுக்கு ஐகான்களை லேசி-லோட் (lazy-load) செய்வது எளிதாகிறது.

குறைபாடுகள்

• ஒவ்வொரு தனித்துவமான ஐகானுக்கும் ஒரு கூடுதல் HTTP கோரிக்கை தேவைப்படுகிறது (உலாவிகள் இணையாக இயக்கி தீவிரமாக தற்காலிக சேமிப்பு செய்தாலும்).
• கோட்பேஸ் முழுவதும் கோப்புப் பாதைகள் மற்றும் பெயரிடும் மரபுகளை நிர்வகிக்க வேண்டும்.
• பில்ட் படி அல்லது ரன்டைம் ஃபீச் (runtime fetch) இல்லாமல் கூறுகள் பண்புகளைப் (component props) பொறுத்து அமையும் SVG ஸ்டைல்களை எளிதாக இன்லைன் செய்ய முடியாது.
• நிலையான சொத்து சேவைகளில் (static asset serving) பழக்கமில்லாத குழுக்களுக்கு இது ஒரு கூறுகளை இறக்குமதி செய்வதை விட சற்று வசதி குறைவாகத் தோன்றலாம்.
• சரியான கேச் தலைப்புகள் (cache headers) இல்லாத பழைய வரிசைப்படுத்துதல்கள் பழைய ஐகான் கோப்புகளை வழங்கும் அபாயத்தைக் கொண்டுள்ளன.

எச்சரிக்கை

மேலே உள்ள எடுத்துக்காட்டுகள் மற்றும் கோப்புப் பாதைகள் (/icons/, check.svg, Icon கூறு பெயர்கள்) விளக்கமான இடப்பிடிப்பான்கள்—அவற்றை உங்கள் திட்டத்தின் அமைப்பிற்கு ஏற்ப மாற்றியமைக்கவும். தயாரிப்பிற்கு வழங்குவதற்கு முன் டெஸ்க்டாப் மற்றும் மொபைல் உலாவிகள் இரண்டிலும் ஐகான் ரெண்டரிங்கை முழுமையாகச் சோதிக்கவும். உங்கள் வெப் சர்வர் அல்லது CDN சரியான கேச் தலைப்புகளை அனுப்புகிறதா என்பதை உறுதிப்படுத்திக் கொள்ளுங்கள் (Cache-Control: public, max-age=31536000) ஐகான் கோப்புகளில் அனுப்பப்படுவதை உறுதிசெய்யவும், இதனால் செயல்திறன் நன்மைகள் உண்மையில் கிடைக்கும். உங்கள் சொந்த ஆபத்தில் தொடரவும் மற்றும் உங்கள் குறிப்பிட்ட நெட்வொர்க் மற்றும் சாதன நிலைகளில் செயல்திறன் மேம்பாட்டைச் சரிபார்க்கவும்.

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

• வலை செயல்திறனுக்காக SVG மற்றும் PNG ஐகான்களுக்கு இடையே உள்ள வேறுபாடு என்ன?
• நான் Font Awesome போன்ற ஐகான் லைப்ரரியைப் பயன்படுத்த வேண்டுமா அல்லது எனது சொந்த ஐகான் அமைப்பை உருவாக்க வேண்டுமா?
• சாத்தியமான அதிவேக ஏற்றும் நேரங்களுக்கு SVG கோப்புகளை எவ்வாறு உகப்பாக்குவது?
• ஐகான்கள் வெளிப்புற கோப்புகளாக வழங்கப்பட்டால், CSS மூலம் தனிப்பட்ட ஐகான்களை ஸ்டைல் செய்ய முடியுமா?
• பயனர் தொடர்புகளின் அடிப்படையில் நிறத்தை மாற்ற வேண்டிய ஐகான்களைக் கையாள சிறந்த வழி எது?
• செயல்திறன் பாதிப்பதற்கு முன்பு ஐகான்களுக்காக எத்தனை HTTP கோரிக்கைகளைச் செய்வது பரவாயில்லை?
• முதல் வருகையிலேயே ஐகான்களை உள்ளூரில் தற்காலிக சேமிப்பு செய்ய Service Worker ஐப் பயன்படுத்த வேண்டுமா?
• எனது தற்போதைய ஐகான் விநியோக முறையை ஆய்வு செய்து செயல்திறன் சிக்கல்களைக் கண்டறிய நான் என்ன கருவியைப் பயன்படுத்தலாம்?

குறிச்சொற்கள்

#svg #web-performance #frontend-optimization #icon-systems #asset-management #caching-strategy #web-development #performance-audit