ஒரு நல்ல முடிவுக்குப் பின்னால் உள்ள வேலைப்பாடு, வடிவங்கள் மற்றும் சிறிய தேர்வுகள் குறித்த எங்கள் குழுவின் குறிப்புகள்.
ஒரு படம் browser-இல் எப்படி மாற்றப்படுகிறது, பலவற்றுக்கு என்ன மாறுகிறது
நீங்கள் ஒரு JPEG-ஐப் பக்கத்தில் போடும்போது, browser கோப்பை memory-க்கு வாசித்து, தன் உள்ளமைந்த JPEG reader-உடன் சுருக்கப்பட்ட தரவை மீண்டும் raw pixel ஆக decode செய்து, அந்த pixel-களை திரைக்கு வெளியே ஒரு பரப்பில் வரைந்து, அவற்றை WebP ஆக மீண்டும் எழுதச் சொல்லி platform-ஐக் கேட்கிறது. ஒவ்வொரு படியும் browser-இல், உங்கள் சொந்த hardware-இல் நடக்கிறது, எனவே எந்த byte-உம் network-ஐக் கடப்பதில்லை. எங்கள் சோதனைகளில் 1024 x 768 அளவிலான JPEG சுமார் 54 மில்லி வினாடிகளிலும், 3840 x 2160 அளவிலான படம் சுமார் 550 மில்லி வினாடிகளிலும் முடிந்தது. பல படங்களை ஒரே நேரத்தில் மாற்றும்போது, வேலை எங்கள் server-க்கு மாறி, அவற்றை சேர்ந்து encode செய்து ஒரே download-ஐத் திருப்பித் தரும், அதன் இணைப்பு சுமார் 2 மணி நேரத்தில் நீக்கப்படும்.
EXIF மற்றும் metadata-வுக்கு என்ன நடக்கிறது
JPEG கோப்புகள் உண்மையான metadata சுமைகளைச் சுமக்கலாம். EXIF camera model, GPS ஆயங்கள், shutter வேகம், திசையமைப்பு ஆகியவற்றைப் பதிவு செய்கிறது. IPTC field-கள் copyright-ஐயும் தலைப்பையும் வைத்திருக்கின்றன. XMP packet-கள் edit வரலாற்றைக் கண்காணிக்கின்றன, ICC profile-கள் color-managed வேலையை உள்ளடக்குகின்றன. இங்குள்ள மாற்றம் அவற்றில் எதையும் வைத்திருக்காது. WebP output காணக்கூடிய pixel-களை மட்டுமே வைத்திருக்கும் ஒரு சுத்தமான கோப்பு. browser வழியாக வரையும் image கருவிகளுக்கு இது இயல்பான நடத்தை, Chromium, Firefox, WebKit முழுவதிலும் ஒரே மாதிரி. பெரும்பாலான web வெளியீட்டுக்கு metadata-வை நீக்குவது ஒரு நன்மை: இது சில byte-களைக் குறைத்து, GPS அல்லது தனிப்பட்ட தரவு ஒரு பொது படத்துக்குள் கசிவதைத் தடுக்கிறது. உங்களுக்கு ஒரு குறிப்பிட்ட field வைத்திருக்க வேண்டுமானால், திசையமைப்பு பொதுவானது, படத்தை முதலில் சுழற்றுங்கள் அல்லது மாற்றுவதற்கு முன் metadata-aware editor-ஐ பயன்படுத்துங்கள். அசல் metadata அப்படியே நிலைக்க வேண்டிய archival வேலைக்கு இந்த கருவியை சார்ந்திருக்காதீர்கள்.
WebP எதிராக JPEG: சுருக்கம் எப்படி வேறுபடுகிறது
ஒரு படத்தை JPEG 8 x 8 கட்டங்களாகப் பிரிக்கிறது, ஒரு Discrete Cosine Transform மூலம் வெளி விவரத்தை அதிர்வெண் தரவாக மாற்றுகிறது, பிறகு மேல் அதிர்வெண்களை இறுக்கமாக quantise செய்கிறது. WebP-இன் வழிமுறை வேறு, VP8 video-விலிருந்து வரும் ஒரு கணிப்பு திட்டத்தைப் பயன்படுத்தி, ஏற்கனவே decode ஆன அண்டை கட்டங்களிலிருந்து ஒவ்வொன்றையும் கணித்து மீதி வித்தியாசத்தை மட்டும் வைக்கிறது. இதனால் ஒரே கோப்பு அளவில் block குறைபாடுகள் குறைகின்றன, மென்மையான நிற மாற்றங்களிலும் முகத் தோல் பகுதிகளிலும் இது தெளிவாகத் தெரிகிறது, அங்குதான் JPEG-இன் grid ஒரு வலைப் போர்வை போல வெளிப்படும். q80-க்கு மேலான தரத்தில் வேறுபாட்டைக் கண் கண்டுபிடிப்பது அரிது, ஆனால் அளவு நன்மை மாறாது நிற்கிறது. q60-க்குக் கீழே சென்றால் WebP மேலும் முன்னேறி, குறைபாட்டின் தன்மையும் மாறுகிறது, JPEG தனது அறியப்பட்ட கட்டங்களைக் காட்ட WebP ஒரு மென் மங்கலாக நெகிழ்கிறது. ஒவ்வொரு படத்திலும் ஒன்று வெல்வதில்லை, புல்வெளி இலைகள் போன்ற நெருக்கமான texture-கள் சில வேளை இரு வடிவத்திலும் கிட்டத்தட்ட ஒரே அளவில் சுருங்குகின்றன.
Core Web Vitals மற்றும் WebP-க்கான வாதம்
Largest Contentful Paint, அல்லது LCP, viewport-இல் மிகப்பெரிய காணக்கூடிய element எவ்வளவு வேகமாக load முடிக்கிறது என்பதை அளவிடுகிறது. பெரும்பாலான marketing பக்கங்களில் அந்த element ஒரு hero படம். Core Web Vitals Search-இல் ஒரு தரவரிசை காரணியாகச் செயல்படுகிறது என்பதை Google உறுதிப்படுத்தியுள்ளது. hero ஒரு JPEG ஆக இருக்கும்போது, அது ஒரு நடுத்தர mobile இணைப்பில் LCP-ஐ 2.5 second வரம்பைத் தாண்டித் தள்ளலாம். அதே படத்தை சுமார் -இல் WebP ஆக மாற்றுங்கள், பக்கத்தில் வேறு எந்த மாற்றமும் இல்லாமல் LCP பச்சை மண்டலத்துக்குள் திரும்பி நழுவலாம். 25 முதல் 34 சதவீத சேமிப்பு பக்கத்தின் ஒவ்வொரு படத்திலும் கூடிக்கொண்டே போகிறது. மொத்தம் ஆகும் ஆறு JPEG-களைச் சுமக்கும் ஒரு பக்கம் WebP-க்கு மாறுவதன் மூலம் 300 முதல் வரை குறைக்கலாம், இது மெதுவான இணைப்புகளில் முதல் அர்த்தமுள்ள paint-ஐ நேரடியாக வேகப்படுத்துகிறது. content negotiation-ஐ ஆதரிக்கும் CDN-கள் இணக்கமான browser-களுக்கு WebP-ஐ தாமாகவே வழங்குகின்றன, எனவே அசல்கள் இருந்தவுடன் ஒவ்வொரு படத்துக்கும் வேலை எதுவும் இல்லை.
2026-இல் WebP-க்கான browser ஆதரவும் இடைவெளிகளும்
2026-இன்படி, பின்வரும் பதிப்புகளில் WebP decode ஆகிறது, Chrome version 17, Firefox 65, Edge 18, Opera 11.10, மேலும் iOS 14 மற்றும் macOS Big Sur-இல் Safari 14. caniuse.com தரும் எண்களின்படி, ஒட்டுமொத்த decode பரப்பு browser traffic-இல் 97 சதவீதத்தை மீறுகிறது. மிஞ்சுவது பெரும்பாலும் Internet Explorer 11, Catalina-வில் இயங்கும் Safari 13, பின் வயதான Android browser-களின் நீண்ட வால். கிட்டத்தட்ட எல்லா பொதுத் திட்டங்களுக்கும், எல்லோருக்கும் WebP கொடுப்பது ஆபத்தற்றது. ஆனால் முழுமையான பரப்பு தேவை எனில், ஒரு HTML picture element-க்குள் ஒரு WebP source-ஐயும் ஒரு JPEG fallback-ஐயும் சேர்த்து வையுங்கள், browser தான் வாசிக்கக்கூடிய முதல் வடிவத்தை எடுக்கும். image optimization கொண்ட CDN-கள் browser அனுப்பும் Accept header-ஐ வாசித்து வடிவத்தைத் தாங்களாகவே தேர்வு செய்கின்றன, கையால் browser-வாரியாகச் சோதிக்கும் தேவையை அவை இல்லாமலாக்குகின்றன.
WebP-ஐ எப்போது பயன்படுத்தக் கூடாது
நவீன browser-களுக்கு web விநியோகத்தில் WebP பொருத்தமானது, இருப்பினும் சில வழக்கமான இடங்களில் அது சரிவராது. அச்சு வேலைக்கு CMYK நிறம் தேவை, அதை WebP கொண்டிருக்காது, அதனால் அச்சகத்துக்கு JPEG-உம் TIFF-உம் தொடர்ந்து தரநிலையாக உள்ளன. email client-கள் சீரற்றவை, Gmail-உம் Apple Mail-உம் WebP-ஐ காட்ட, Windows-இன் Outlook காட்டாது. கோப்பு பகிர்வும் marketplace-களும் மாறுபடுகின்றன, Google Drive, Dropbox, GitHub WebP-ஐ நன்கு காட்ட, பல சமூக platform-கள், stock agency-கள், e-commerce அமைப்புகள் வரும் படங்களை உள்ளேயே JPEG ஆக மாற்றி WebP படியை வீணடிக்கின்றன. editor ஆதரவும் இன்னும் ஓரளவே, Lightroom, Capture One, Affinity Photo WebP-ஐ திறக்க, பல plugin-களும் export preset-களும் இயல்பாக JPEG-ஐயே எடுக்கின்றன. நீங்கள் கட்டுப்படுத்தாத மூன்றாம் தரப்பு அமைப்புகள் வழியே படங்கள் செல்லும் ஒவ்வொரு workflow-க்கும், ஒரு JPEG master-ஐ வைத்துக்கொண்டு, கடைசி வழங்கல் அடுக்கில் மட்டுமே WebP ஆக மாற்றுங்கள்.