WordPress में upload के बाद image blurry क्यों दिखती है (और इसका fix)

दस में से नौ बार आपकी image असल में blurry होती ही नहीं — WordPress ने उसे upload पर downscale कर दिया और अब वही capped copy serve कर रहा है। WordPress 5.3 के बाद, 2560px से ज़्यादा चौड़ी या लंबी कोई भी image चुपचाप एक -scaled version से बदल दी जाती है जिसका सबसे लंबा edge 2560px पर cap हो जाता है, और वही छोटी file आपकी theme खींचकर hero, full-width block, या retina display भरने के लिए इस्तेमाल करती है। इसका fix यह है कि पहले साबित कीजिए कि यही हुआ है, फिर या तो threshold बढ़ा दीजिए या ऐसी images upload करना बंद कर दीजिए जिन्हें अपने box से बड़ा होना ज़रूरी है।

ऐसा होता क्यों है

जब आप कोई photo upload करते हैं, तो WordPress wp_create_image_subsizes() चलाता है (जो wp-admin/includes/image.php में है)। अगर सबसे लंबा edge big_image_size_threshold — default 2560px — से ज़्यादा है, तो यह _wp_image_meta_replace_original() को call करता है, your-photo-scaled.jpg बनाता है, और attachment metadata दोबारा लिख देता है ताकि अब full size scaled copy की तरफ़ point करे। आपकी असली original file disk पर your-photo.jpg के रूप में रखी रहती है और wp_get_original_image_path() से reference होती है, लेकिन front end पर उसे कुछ भी serve नहीं करता। हर intermediate size और हर srcset candidate उसी 2560px scaled file से generate होता है, उस चीज़ से नहीं जो आपने upload की थी।

तो blur की वजह यहाँ है। आप एक full-bleed header के लिए crisp 4000px image upload करते हैं। WordPress उसे 2560px पर cap कर देता है। किसी standard display पर 1600px चौड़े container में यह ठीक है। लेकिन 2x retina screen पर browser को उस container को sharp भरने के लिए लगभग 3200 असली pixel चाहिए, उसे सिर्फ़ 2560 मिलते हैं, और बाक़ी फ़र्क़ को वह upscale कर देता है। Soft edges, image के अंदर का धुँधला text — बिल्कुल वही “upload के बाद blurry” वाला लक्षण।

इसी समस्या का दूसरा आधा हिस्सा है srcset का ऐसा size चुनना जो बहुत छोटा हो। अगर आपकी theme ऐसी content width report करती है जो असली rendered box से मेल नहीं खाती, तो WordPress browser को -1024x683 या -1536x1024 वाला intermediate दे देता है और वह खिंच जाता है। वजह वही — display box उपलब्ध pixels से बड़ा — लेकिन trigger अलग।

देखिए WordPress ने असल में serve क्या किया

अंदाज़ा मत लगाइए। Blurry image पर right-click कीजिए, उसे नए tab में खोलिए, और URL में filename देखिए। अगर वह -scaled.jpg पर या -1024x683.jpg जैसे dimension suffix पर ख़त्म होती है, तो आपने पुष्टि कर ली: browser एक downscaled derivative render कर रहा है, आपकी upload की हुई file नहीं। आप element inspect करके currentSrc भी पढ़ सकते हैं यह देखने के लिए कि browser ने असल में कौन-सा candidate चुना।

कुछ भी दोबारा upload करने से पहले पूरी तस्वीर देखने के लिए, image को WordPress image sizes tool में डालिए — यह दिखाता है कि उसी exact file से WordPress हर derivative क्या generate करेगा, इसमें यह भी कि -scaled copy बनती है या नहीं और किस dimension पर, ताकि आपको पहले से पता हो कि आपका source उस जगह के लिए काफ़ी बड़ा है या नहीं जहाँ आप उसे रख रहे हैं।

Server पर आप हर capped file list कर सकते हैं:

find wp-content/uploads -name '*-scaled.*'

इसे कैसे ठीक करें, क्रम से

1. अगर आपकी images को सचमुच 2560px से बड़ी होना ज़रूरी है (बड़े heroes, retina, print-quality galleries), तो threshold बढ़ा दीजिए:

// functions.php or a small mu-plugin
add_filter( 'big_image_size_threshold', function () {
    return 3840; // longest edge, in pixels
} );

या cap को पूरी तरह बंद कर दीजिए:

add_filter( 'big_image_size_threshold', '__return_false' );

2. प्रभावित images को दोबारा upload कीजिए। यही step लोग छोड़ देते हैं। Threshold बदलने का असर सिर्फ़ नए uploads पर पड़ता है। आपकी library में पहले से मौजूद images अपना पुराना metadata रखती हैं, और thumbnails regenerate करने से intermediate sizes उसी capped -scaled file से दोबारा बनती हैं — यह उस resolution को वापस नहीं लाता जो फेंकी जा चुकी है। भरोसेमंद तरीक़ा यह है: filter बदलिए, attachment delete कीजिए, फिर से upload कीजिए।

3. अगर आपका source पहले से ही ≤2560px है और फिर भी blurry है, तो threshold आपकी समस्या नहीं है — display box image से बड़ा है। बड़ा source upload कीजिए, या container छोटा कीजिए। Retina sharpness के लिए, आपका source उस box की CSS pixel width से लगभग दोगुना होना चाहिए जिसे वह भरती है।

4. ऊपर वाला सब कुछ हो जाने के बाद ही thumbnails regenerate कीजिए ताकि intermediate sizes एक जैसी रहें — लेकिन समझ लीजिए कि यह cleanup है, इलाज नहीं।

क्या नहीं करना चाहिए

JPEG quality को 100 तक मत बढ़ाइए। WordPress wp_editor_set_quality के ज़रिए default 82 quality पर compress करता है, और online आधी सलाह आपको इसे override करने को कहती है:

add_filter( 'wp_editor_set_quality', function () { return 90; } );

Compression artifacts कम करने के लिए यह ठीक है, लेकिन खिंची हुई, upscaled image एक resolution की समस्या है, compression की नहीं। 82 से 100 पर जाने से आपकी files फूल जाती हैं और जो softness आप देख रहे हैं उसके लिए लगभग कुछ नहीं करतीं।

आदतन -scaled को disable मत कीजिए। Cap बंद करना (इसके लिए एक tool है) सही फ़ैसला है अगर आप 2560px से बड़ी images serve करते हैं — लेकिन अगर आपकी असली दिक़्क़त किसी बहुत छोटे intermediate का खिंचना है, तो इसे disable करने से कुछ नहीं बदलता और आप बेवजह bandwidth की बचत खो देते हैं। पहले diagnose कीजिए।

Cache को दोष मत दीजिए और सबसे पहले thumbnails regenerate मत कीजिए। Regeneration उसी capped source से पढ़ता है, इसलिए वह detail वापस नहीं ला सकता। CDN या page cache clear करना उस file को छुएगा भी नहीं जो disk पर शुरू से ही छोटी थी।

Theme की CSS या object-fit की तरफ़ मत भागिए। कितनी भी styling pixels नहीं जोड़ेगी। अगर serve की गई file -scaled पर या dimension suffix पर ख़त्म होती है, तो file समस्या है, layout नहीं।

अब भी अटके हुए हैं?

अगर आपने पुष्टि कर ली है कि serve की गई file आपका full-resolution upload ही है — न -scaled, न कोई dimension suffix — और फिर भी वह soft है, तो देखिए कि कोई plugin (कोई optimizer, CDN image-resizer, या lazy-load library) आपके src को किसी compressed proxy में तो दोबारा नहीं लिख रहा। Image को image sizes tool से चलाइए यह पुष्टि करने के लिए कि WordPress को असल में क्या generate करना चाहिए, फिर उसकी तुलना उससे कीजिए जो browser सचमुच load करता है। जब ये दोनों आपस में न मिलें, तो WordPress और browser के बीच में ही कोई चीज़ गुनहगार है।