ਜ਼ਿਆਦਾਤਰ ਵੈੱਬ ਐਪਸ ਅਜੇ ਵੀ ਇਮੇਜ ਅਪਲੋਡ ਨੂੰ ਇੱਕ 'ਬਲੈਕ ਬਾਕਸ' ਵਾਂਗ ਸੰਭਾਲਦੀਆਂ ਹਨ। ਇੱਕ ਯੂਜ਼ਰ ਫਾਈਲ ਡ੍ਰੌਪ ਕਰਦਾ ਹੈ, ਬ੍ਰਾਊਜ਼ਰ ਇਸਨੂੰ ਭੇਜ ਦਿੰਦਾ ਹੈ, ਅਤੇ ਸਰਵਰ ਜਾਂ ਤਾਂ ਪੇਲੋਡ (payload) ਨੂੰ ਸਵੀਕਾਰ ਕਰਦਾ ਹੈ ਜਾਂ 413 ਐਰਰ ਦਿੰਦਾ ਹੈ ਜਿਸ ਲਈ ਕੋਈ ਤਿਆਰ ਨਹੀਂ ਸੀ। ਬ੍ਰਾਊਜ਼ਰ-ਸਾਈਡ ਕੰਪਰੈਸ਼ਨ ਇਸ ਸਥਿਤੀ ਨੂੰ ਬਦਲ ਦਿੰਦੀ ਹੈ। ਇਹ ਤੁਹਾਨੂੰ ਤਾਰਾਂ (network) ਤੱਕ ਪਹੁੰਚਣ ਤੋਂ ਪਹਿਲਾਂ ਪੇਲੋਡ ਨੂੰ ਸੁੰਗੜਨ ਦਾ ਮੌਕਾ ਦਿੰਦੀ ਹੈ, ਜਿਸਦਾ ਮਤਲਬ ਹੈ ਤੇਜ਼ ਅਪਲੋਡ, ਘੱਟ ਬੈਂਡਵਿਡਥ ਬਿੱਲ, ਅਤੇ ਘੱਟ ਸਰਵਰ ਟਾਈਮਆਊਟ। ਪਰ ਇਸ ਕੰਮ ਵਿੱਚ ਗਲਤੀ ਹੋਣਾ ਆਸਾਨ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਕੰਪਰੈਸ਼ਨ ਨੂੰ "quality" ਲੇਬਲ ਵਾਲੇ ਕਿਸੇ ਜਾਦੂਈ ਸਲਾਈਡਰ ਵਾਂਗ ਮੰਨਦੇ ਹੋ, ਤਾਂ ਤੁਸੀਂ ਖਰਾਬ ਤਸਵੀਰਾਂ, ਖਿੱਚੇ ਹੋਏ ਥੰਬਨੇਲ (thumbnails), ਅਤੇ ਉਲਝਣ ਵਾਲਾ ਯੂਜ਼ਰ ਅਨੁਭਵ ਪ੍ਰਦਾਨ ਕਰੋਗੇ। ਬਿਹਤਰ ਤਰੀਕਾ ਇਹ ਹੈ ਕਿ ਪੂਰੇ ਪ੍ਰਵਾਹ (flow) ਨੂੰ ਇੱਕ ਪਾਈਪਲਾਈਨ ਵਜੋਂ ਲਿਆ ਜਾਵੇ।

ਸਲਾਈਡਰਾਂ ਦੀ ਬਜਾਏ ਪਾਈਪਲਾਈਨਾਂ ਬਾਰੇ ਸੋਚੋ

ਕੰਮ ਨੂੰ ਵੱਖ-ਵੱਖ ਪੜਾਵਾਂ ਵਿੱਚ ਵੰਡੋ। ਇਨਪੁਟ ਐਲੀਮੈਂਟ ਤੋਂ ਫਾਈਲ ਪੜ੍ਹੋ। ਤਸਵੀਰ ਨੂੰ ਆਪਣੇ ਨਿਰਧਾਰਤ ਡਾਇਮੈਂਸ਼ਨਾਂ (dimensions) ਤੱਕ ਛੋਟਾ ਕਰੋ। ਇੱਕ ਨਵਾਂ Blob ਇਨਕੋਡ ਕਰੋ। ਫਿਰ ਨਤੀਜੇ ਨੂੰ ਯੂਜ਼ਰ ਨੂੰ ਦਿਖਾਓ। ਹਰੇਕ ਪੜਾਅ ਇੱਕ ਕੰਮ ਕਰਦਾ ਹੈ ਅਤੇ ਆਪਣਾ ਆਉਟਪੁੱਟ ਅਗਲੇ ਪੜਾਅ ਨੂੰ ਭੇਜ ਦਿੰਦਾ ਹੈ। ਇਹ ਵੱਖਰੇਕਰਣ ਸਿਰਫ਼ ਕੋਡ ਨੂੰ ਸਾਫ਼ ਹੀ ਨਹੀਂ ਬਣਾਉਂਦਾ, ਸਗੋਂ ਯੂਨਿਟ ਟੈਸਟਿੰਗ (unit testing) ਨੂੰ ਵੀ ਸੌਖਾ ਬਣਾਉਂਦਾ ਹੈ। ਤੁਸੀਂ ਫਾਈਲ ਇਨਪੁਟ ਨੂੰ ਛੇੜੇ ਬਿਨਾਂ ਸਕੇਲਿੰਗ ਪੜਾਅ ਵਿੱਚ ਇੱਕ ਜਾਣੇ-ਪਛਾਣੇ ਬਫਰ (buffer) ਨੂੰ ਭੇਜ ਸਕਦੇ ਹੋ। ਤੁਸੀਂ ਸਰਵਰ ਦੇ ਰਿਸਪਾਂਸ ਦੀ ਉਡੀਕ ਕੀਤੇ ਬਿਨਾਂ ਇਹ ਪੁਸ਼ਟੀ ਕਰ ਸਕਦੇ ਹੋ ਕਿ ਤੁਹਾਡਾ ਇਨਕੋਡਰ 200 KB ਤੋਂ ਘੱਟ ਦਾ JPEG ਬਣਾ ਰਿਹਾ ਹੈ। ਜਦੋਂ ਕੁਝ ਖਰਾਬ ਹੁੰਦਾ ਹੈ, ਤਾਂ ਤੁਹਾਨੂੰ ਪਤਾ ਹੁੰਦਾ ਹੈ ਕਿ ਕਿਹੜਾ ਕਦਮ ਫੇਲ ਹੋਇਆ ਹੈ।

ਇਹਨਾਂ ਡਿਊਟੀਆਂ ਨੂੰ ਵੱਖ ਰੱਖਣ ਨਾਲ ਅਪਲੋਡ ਦੌਰਾਨ ਅਚਾਨਕ ਆਉਣ ਵਾਲੀਆਂ ਮੁਸ਼ਕਲਾਂ ਤੋਂ ਵੀ ਬਚਿਆ ਜਾ ਸਕਦਾ ਹੈ। ਜੇਕਰ ਤੁਸੀਂ ਸਕੇਲਿੰਗ ਅਤੇ ਇਨਕੋਡਿੰਗ ਨੂੰ ਇੱਕ ਉਲਝੇ ਹੋਏ ਫੰਕਸ਼ਨ ਵਿੱਚ ਬੰਨ੍ਹ ਦਿੰਦੇ ਹੋ, ਤਾਂ ਅੱਧ ਵਿਚਕਾਰ ਹੋਣ ਵਾਲੀ ਡੀਕੋਡਿੰਗ ਗਲਤੀ ਤੁਹਾਡੀ ਅਪਲੋਡ ਕਿਊ (upload queue) ਨੂੰ ਅਸਥਿਰ ਸਥਿਤੀ ਵਿੱਚ ਛੱਡ ਸਕਦੀ ਹੈ। ਇੱਕ ਪਾਈਪਲਾਈਨ ਤੁਹਾਨੂੰ ਹਰ ਸੀਮਾ 'ਤੇ ਵੈਲੀਡੇਸ਼ਨ (validation) ਕਰਨ ਲਈ ਮਜਬੂਰ ਕਰਦੀ ਹੈ। ਜੇਕਰ ਫਾਈਲ ਨੂੰ ਡੀਕੋਡ ਨਹੀਂ ਕੀਤਾ ਜਾ ਸਕਦਾ, ਤਾਂ ਤੁਸੀਂ ਕੈਨਵਸ (canvas) ਬਣਾਉਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਫੜ ਲੈਂਦੇ ਹੋ। ਜੇਕਰ ਇਨਕੋਡ ਕੀਤਾ Blob ਬਹੁਤ ਵੱਡਾ ਹੈ, ਤਾਂ ਤੁਸੀਂ ਸਰਵਰ ਨੂੰ ਇਸਨੂੰ ਸਟੋਰ ਕਰਨ ਲਈ ਕਹਿਣ ਤੋਂ ਪਹਿਲਾਂ ਹੀ ਇਸਨੂੰ ਫੜ ਲੈਂਦੇ ਹੋ।

ਕੋਡ ਲਿਖਣ ਤੋਂ ਪਹਿਲਾਂ ਇੱਕ ਸਮਝੌਤਾ (Contract) ਤੈਅ ਕਰੋ

ਇਸ ਤੋਂ ਪਹਿਲਾਂ ਕਿ ਕੋਈ ਵੀ canvas draw call ਲਿਖੇ, ਨਿਯਮ ਲਿਖ ਲਓ ਅਤੇ ਉਹਨਾਂ ਨੂੰ ਟੀਮ ਨਾਲ ਸਾਂਝਾ ਕਰੋ। ਸਵੀਕਾਰ ਕੀਤੇ ਜਾਣ ਵਾਲੇ MIME types ਚੁਣੋ। ਕੀ ਤੁਸੀਂ JPEG, PNG, WebP, ਜਾਂ AVIF ਦੀ ਇਜਾਜ਼ਤ ਦਿਓਗੇ? ਹਰੇਕ ਦੇ ਅਲਫਾ ਚੈਨਲਾਂ (alpha channels), ਬ੍ਰਾਊਜ਼ਰ ਸਪੋਰਟ, ਅਤੇ CPU ਲਾਗਤ 'ਤੇ ਪ੍ਰਭਾਵ ਪੈਂਦੇ ਹਨ। ਵੱਧ ਤੋਂ ਵੱਧ ਇਨਪੁਟ ਸਾਈਜ਼ ਸੈੱਟ ਕਰੋ। ਇੱਕ ਫਲੈਗਸ਼ਿਪ ਫੋਨ ਤੋਂ 30 MB ਦੀ ਰਅਅ (raw) ਫੋਟੋ ਪੁਰਾਣੇ ਲੈਪਟਾਪ ਨੂੰ ਫ੍ਰੀਜ਼ ਜਾਂ ਕ੍ਰੈਸ਼ ਕਰ ਸਕਦੀ ਹੈ ਜੇਕਰ ਤੁਸੀਂ ਇਸਨੂੰ ਪੂਰੀ ਤਰ੍ਹਾਂ ਮੈਮੋਰੀ ਵਿੱਚ ਡੀਕੋਡ ਕਰਨ ਦੀ ਕੋਸ਼ਿਸ਼ ਕਰਦੇ ਹੋ। ਵੱਧ ਤੋਂ ਵੱਧ ਆਉਟਪੁੱਟ ਡਾਇਮੈਂਸ਼ਨਾਂ ਨੂੰ ਪਰਿਭਾਸ਼ਿਤ ਕਰੋ। ਜੇਕਰ ਤੁਹਾਡਾ UI ਕਦੇ ਵੀ 2048 ਪਿਕਸਲ ਤੋਂ ਵੱਧ ਚੌੜੀ ਤਸਵੀਰ ਨਹੀਂ ਦਿਖਾਉਂਦਾ, ਤਾਂ 6000 ਪਿਕਸਲ ਚੌੜੀ ਫੋਟੋ ਨੂੰ ਪਾਈਪਲਾਈਨ ਰਾਹੀਂ ਜਾਣ ਦੇਣ ਦਾ ਕੋਈ ਕਾਰਨ ਨਹੀਂ ਹੈ।

ਸਭ ਤੋਂ ਮਹੱਤਵਪੂਰਨ ਗੱਲ ਇਹ ਹੈ ਕਿ ਡੀਕੋਡਿੰਗ ਦੀਆਂ ਅਸਫਲਤਾਵਾਂ ਲਈ ਯੋਜਨਾ ਬਣਾਓ। ਇੱਕ ਖਰਾਬ ਫਾਈਲ, ਇੱਕ ਅਨੋਖਾ ਕਲਰ ਪ੍ਰੋਫਾਈਲ, ਜਾਂ ਅਧੂਰਾ ਅਪਲੋਡ Image constructor 'ਤੇ ਐਰਰ (error) ਪੈਦਾ ਕਰ ਸਕਦਾ ਹੈ। ਤੁਹਾਡੀ ਪਾਈਪਲਾਈਨ ਨੂੰ ਇੱਕ ਸਪਸ਼ਟ catch block ਅਤੇ ਮਨੁੱਖੀ-ਪੜ੍ਹਨਯੋਗ ਐਰਰ ਮੈਸੇਜ ਦੀ ਲੋੜ ਹੈ। ਬ੍ਰਾਊਜ਼ਰ ਨੂੰ

  • Smaller file: Push quality lower and cap dimensions aggressively for thumbnails or fast previews.
  • Balanced: Target a moderate quality level with sensible dimensions, suitable for social feeds and galleries.
  • More detail: Keep quality high and preserve larger dimensions for photography, artwork, or print previews.

Store the original Blob in memory so the user can switch between presets without stacking generations of loss. Always generate from the source, never from the last output.

Test Like Your Users Upload

Your development machine with a fiber connection and 32 GB of RAM is not reality. Test with the actual files real users carry. Phone photos from iOS and Android use different metadata orientations and may originate from HEIC sources. Transparent assets such as logos and icons behave differently under JPEG conversion because JPEG simply does not support alpha channels. Huge files will expose memory limits on devices with 2 GB of RAM. Slow mobile CPUs will reveal exactly how long that toBlob call really takes.

Use Chrome DevTools to throttle the CPU and network. Try a five-year-old Android phone. If your pipeline locks the UI for three seconds while encoding, you need to move the heavy work into a Web Worker so the interface stays responsive.

Ship the Basics First

It is tempting to support every format and