सीधे कंटेंट पर जाएं
Images और media

आपका WordPress uploads फ़ोल्डर इतना बड़ा क्यों है

आपका WordPress uploads फ़ोल्डर इसलिए बड़ा है क्योंकि WordPress कभी भी हर इमेज के लिए एक ही फ़ाइल स्टोर नहीं करता। हर अपलोड पर original के साथ resized copies का एक तय सेट बनता है।

Published

आपका WordPress uploads फ़ोल्डर इसलिए बड़ा है क्योंकि WordPress कभी भी हर इमेज के लिए एक ही फ़ाइल स्टोर नहीं करता। हर अपलोड पर original के साथ-साथ resized copies का एक तय सेट बन जाता है — एक आम कैमरा-साइज़ फ़ोटो के लिए सात, वो भी किसी theme या plugin के कुछ जोड़ने से पहले। कुछ भी corrupt नहीं हुआ है; आप बस वो गुणा (multiplication) देख रहे हैं जो हर एक अपलोड पर होता है। इसका हल है कि जो sizes आप कभी serve नहीं करते उन्हें बनाना बंद करें, फिर regenerate करें ताकि पुरानी copies disk से delete हो जाएँ।

हिसाब लगाकर देखिए

एक 4000×3000 JPEG अपलोड करें और /wp-content/uploads/2026/07/ के अंदर झाँकें। आपको एक फ़ाइल नहीं मिलेगी। आपको ये मिलेंगी:

  • photo.jpg — original, बिना छेड़छाड़ के
  • photo-scaled.jpg — 2560px की copy जिसे WordPress original की जगह serve करता है
  • photo-150x150.jpgthumbnail
  • photo-300x225.jpgmedium
  • photo-768x576.jpgmedium_large
  • photo-1024x768.jpglarge
  • photo-1536x1152.jpg — 2× medium_large
  • photo-2048x1536.jpg — 2× large

यानी original के अलावा सात derivatives, अकेले core से। एक 3 MB का अपलोड, किसी plugin के चलने से पहले ही, disk पर 5–6 MB बन सकता है। अब एक ऐसा theme जोड़ें जो अपने चार sizes register करता है और WooCommerce (तीन और) — और एक अपलोड चौदह-पंद्रह फ़ाइलों में बदल जाता है। इसे कुछ हज़ार images की library से गुणा करें और फ़ोल्डर का साइज़ अब कोई रहस्य नहीं रहता।

अगर आप अपनी खुद की dimensions और registered sizes के लिए सटीक संख्या चाहते हैं, तो image storage calculator यह गुणा आपके लिए कर देता है।

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

जब आप अपलोड करते हैं, तो wp_generate_attachment_metadata(), wp_create_image_subsizes() को call करता है, जो get_intermediate_image_sizes() से लौटने वाले हर size पर loop चलाता है और हर उस size के लिए एक फ़ाइल लिखता है जिसे बनाने के लिए original काफ़ी बड़ा हो। Core thumbnail, medium, medium_large, large register करता है, साथ ही WP 5.3 में जुड़े 1536x1536 और 2048x2048 retina sizes भी। कोई भी theme या plugin जो add_image_size() call करता है, उसी loop में जुड़ जाता है — हमेशा के लिए, हर भविष्य के अपलोड के लिए।

-scaled फ़ाइल एक अलग तंत्र से आती है: big_image_size_threshold filter, जिसका default 2560px है। इससे चौड़ी कोई भी चीज़ की एक scaled copy बनती है जो serve की जाने वाली “full” इमेज बन जाती है, जबकि original disk पर ही रहता है। यानी एक बड़ा अपलोड दोनों रखता है — विशाल original और 2560px वाला version।

आप किसी दी हुई इमेज के लिए अपना setup ठीक-ठीक क्या बनाता है, यह image sizes inspector से देख सकते हैं।

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

1. कुछ भी छेड़ने से पहले माप लें। अंदाज़ा लगाने में समय बर्बाद होता है। site root से:

du -sh wp-content/uploads
find wp-content/uploads -type f \( -name '*.jpg' -o -name '*.webp' -o -name '*.png' \) | wc -l
du -ah wp-content/uploads | sort -rh | head -20

2. जो sizes आप serve नहीं करते उन्हें deregister करें। ज़्यादातर themes 1536 और 2048 sizes कभी output नहीं करते, और कई medium_large कभी इस्तेमाल नहीं करते। इन्हें हटा दें:

// functions.php — stop generating sizes this site never outputs
add_action( 'init', function () {
    remove_image_size( '1536x1536' );
    remove_image_size( '2048x2048' );
} );

// Drop medium_large too, if your theme doesn't use the 768px size
add_filter( 'intermediate_image_sizes_advanced', function ( $sizes ) {
    unset( $sizes['medium_large'] );
    return $sizes;
} );

3. पुरानी copies delete करने के लिए regenerate करें। Deregister करने से सिर्फ़ आगे की generation रुकती है — जो फ़ाइलें पहले से disk पर हैं वे तब तक रहती हैं जब तक आप regenerate नहीं करते:

wp media regenerate --yes

हाल के WP-CLI versions चलते-चलते उन sizes की फ़ाइलें delete कर देते हैं जो अब register नहीं हैं। अगर आप इसके बजाय Regenerate Thumbnails plugin पर हैं, तो उसका “delete unregistered sizes” विकल्प tick करें — वह box चेक किए बिना, पुरानी फ़ाइलें बनी रहती हैं।

4. orphaned फ़ाइलें ढूँढें। Theme बदलने पर पुराने theme के register किए sizes कभी साफ़ नहीं होते। Posts delete करने से भी हमेशा उनके derivatives नहीं हटते। step 3 के बाद, अगर du -sh अब भी calculator के अनुमान से कहीं ज़्यादा है, तो आपके पास orphans हैं — disk पर पड़ी फ़ाइलें जिन्हें कोई attachment reference नहीं करता।

क्या न करें

जगह “बचाने” के लिए scaled images को disable न करें। -scaled फ़ाइल आपके original से छोटी होती है। big_image_size_threshold बंद करने से कुछ delete नहीं होता — यह बस WordPress को हर visitor को full multi-megabyte original serve करने पर मजबूर कर देता है। यह bandwidth और quality का फ़ैसला है, storage cleanup नहीं, और आम तौर पर page weight और बिगाड़ देता है। disable-scaled-images tool बताता है कि यह कब सही निर्णय है; uploads फ़ोल्डर छोटा करना उनमें से एक नहीं है।

SFTP के ज़रिए uploads से सीधे फ़ाइलें delete न करें। हर attachment की subsize सूची उसके _wp_attachment_metadata में रहती है। हाथ से फ़ाइलें delete करने से टूटे हुए references रह जाते हैं, और अगर आपने वह original हटा दिया जिससे कोई size बनी थी, तो regeneration उसे दोबारा नहीं बना सकता। Original delete किया, तो वह इमेज हमेशा के लिए गई।

Settings → Media में thumbnail/medium/large को 0 सेट करके यह उम्मीद न करें कि फ़ोल्डर सिकुड़ जाएगा। किसी size को zero करने से आगे की generation रुकती है पर disk पर पहले से मौजूद किसी चीज़ को यह नहीं छूता, और UI medium_large, 1536, 2048, या किसी theme/plugin size तक पहुँच ही नहीं सकता — वे वहाँ हैं ही नहीं।

database को दोष न दें। भारी uploads फ़ोल्डर image फ़ाइलों का होता है, लगभग कभी DB का नहीं। Tables optimize करने से यह संख्या नहीं बदलेगी।

फिर भी अटके हैं?

अगर regenerate करने के बाद भी फ़ोल्डर उम्मीद से बड़ा है, तो अपनी असली image dimensions और registered sizes को storage calculator में डालें और उसकी संख्या की तुलना du -sh wp-content/uploads से करें। बड़ा अंतर मतलब किसी पुराने theme या delete किए गए posts से orphaned फ़ाइलें — न core, और न ही कुछ ऐसा जिसे और regenerate करने से ठीक किया जा सके। छोटा अंतर मतलब हिसाब बस वही है जो है: हर अपलोड पर सात-प्लस फ़ाइलें, बिल्कुल जैसा design किया गया है वैसे काम करती हुईं।