For a large photo delivery, three numbers are more useful than a promise of “fast internet”: the bytes you need to upload, the sustained upload rate, and the time left before the client needs the work. Keep the required image quality fixed, then remove unnecessary transfer and waiting.
This guide uses hypothetical file sizes and transparent arithmetic, not a SendPhoto performance benchmark. It separates uploading files, preparing gallery previews, browsing images and downloading the finished set. Each can have a different bottleneck.
The Night 600 Photos Almost Did Not Make It
Consider a hypothetical wedding delivery: it is late, the client wants a first look the next morning, and the photographer has 600 selected images plus larger working files. The venue connection is slow or shared. There is no measured hotel case or assumed 2 GB throttling threshold behind this example.
First confirm what was promised. A small preview set may be enough for the morning, while the finished gallery has a later deadline. If the agreement calls for the complete final files, do not quietly substitute small viewing copies. Change the delivery plan with the client or find a suitable connection.
The controllable part of the ratio
You can control the selection, export dimensions, compression, upload order and clarity of the handoff. You may also be able to pause unrelated cloud backups or use a stable wired connection. You cannot guarantee the venue's network capacity or the client's mobile reception.
Separate three file roles:
- Viewing copy: enough detail for the intended gallery view and zoom level.
- Client deliverable: the resolution, format and quality agreed for printing, publishing or other use.
- Working master: the RAW files, layered edits or other originals you retain separately with backups.
These are workflow categories, not a promise that a gallery platform generates every version for you. Smaller viewing copies should not replace required client files or the only master copy.
What Bandwidth Efficiency Actually Means
Here, efficiency means avoiding unnecessary bytes and repeated work while delivering the required result. Measure file size in bytes, transfer rate in bits per second, and elapsed time in seconds or minutes. One byte contains eight bits. A connection labeled 25 Mbit/s is not transferring 25 megabytes each second.
Radio spectral efficiency uses bits per second per hertz. It is a different quantity: a gallery's file size, upload speed and client count do not supply the radio bandwidth needed to calculate it. You do not need that metric to plan a photo upload.
Translating the ratio into delivery work
Ask four practical questions:
- Payload: which files must arrive for the current task?
- Capacity: what sustained upload rate is available on the actual path?
- Cost: how much time, mobile data and repeated transfer will this require?
- Outcome: can the client view the intended images and retrieve the agreed files?
A slow first image does not always mean a large upload. The gallery may still be preparing previews, the browser may be waiting on another request, or the client may be on a weak connection. Diagnose the stage before changing every export.
The Ceiling and the Targets Behind the Number
An advertised connection rate is not an end-to-end delivery promise. Wi-Fi contention, other uploads, provider limits and the path to the service can change the sustained rate. Upload and download rates can also differ substantially.
Use a recent ordinary transfer as a planning reference and allow time for export, server processing, checking the gallery and retries. If the available connection changes, recalculate with the new rate. A faster client download connection does not repair the photographer's slow initial upload.
Why the photographer can't optimize the ceiling
Resizing a JPEG changes the bytes to transfer; it does not upgrade the connection. Starting many parallel uploads does not multiply a fixed upstream capacity. Choose supported uploader settings, leave headroom for other work, and avoid repeatedly restarting a transfer because its progress looks slow.
Once files are hosted, clients normally retrieve them from the service rather than from the photographer's laptop. Forty gallery viewers therefore do not automatically divide the photographer's 25 Mbit/s upload rate into forty equal portions. Service capacity and each recipient's path are separate considerations.
Measuring Bandwidth Efficiency in Your Gallery Workflow
Four measurements that reveal waste
- Export payload: record the actual total bytes, image count, format and dimensions for each delivery set. Do not estimate a mixed RAW/JPEG/video package from image count alone.
- Upload elapsed time: note when transfer starts and completes. Record processing time separately if the interface distinguishes it. A whole-workflow average that includes idle time is not a pure network rate.
- First-view experience: record when a useful photo appears, then whether browsing remains responsive. Use the same device, page state and connection conditions when comparing versions.
- Client download: check the intended file size and whether the recipient can save and open it. Preparing a ZIP is different from completing its download.
For browser inspection, Chrome DevTools' Network reference explains request timing, image filtering and transferred-resource totals. Open the panel before reloading; earlier requests are not counted. Compare a fresh-browser-cache load with a normal repeat visit. Keep the same throttling setting when comparing runs, and restore normal settings afterward. Simulated throttling is useful for a comparison, but it is not a measurement of every real phone network.
A sample calculation
Use decimal units here: 1 MB = 1,000,000 bytes and 1 GB = 1,000 MB. A MiB or GiB value needs a different conversion.
Transfer seconds = file bytes × 8 ÷ sustained bits per second.
Suppose 600 exported photos average 2 MB each. The set is 1,200 MB, or 1.2 GB. At an assumed constant payload rate of 25 Mbit/s:
1,200 × 8 ÷ 25 = 384 seconds = 6 minutes 24 seconds.
For the same assumed rate:
- 60 GB of working files: 60,000 × 8 ÷ 25 = 19,200 seconds, or 5 hours 20 minutes.
- 600 photos averaging 2 MB: 1,200 × 8 ÷ 25 = 384 seconds, or 6 minutes 24 seconds.
- 600 photos averaging 1 MB: 600 × 8 ÷ 25 = 192 seconds, or 3 minutes 12 seconds.
These are calculated transfer times, not measured exports or quality-equivalent results. There is no claim that every photo can be halved without a visible change. If 25 Mbit/s is merely the advertised link rate, protocol overhead and interruptions can make the transfer longer. If it is a measured payload rate for a comparable transfer, do not add the same overhead again. Export, preview preparation and checking still take additional time.
For comparison, 500 MB at 10 Mbit/s takes 500 × 8 ÷ 10 = 400 seconds, or 6 minutes 40 seconds, under the same assumptions. Replace these inputs with your real file totals and observed rate.
Preparing Assets to Move Less and Show More
Start with the display, not the sensor
Choose dimensions from the viewing task, including expected zoom and screen density. A 2048-pixel long edge can be a candidate for a screen preview, but it is not a universal limit or a print specification. Pixel dimensions, color treatment and output quality need to match the deliverable.
In Lightroom Classic, Adobe's export documentation describes File Settings, Image Sizing, output sharpening and Metadata controls. Long Edge retains the aspect ratio; Don't Enlarge avoids upscaling smaller images. Create and inspect a separate export before applying a saved preset across the set. A quality-slider number is a candidate setting to inspect, not a guarantee that all pictures or encoders produce the same result.
Choose metadata deliberately. The same Adobe documentation provides Copyright Only, Copyright & Contact Info Only and Remove Location Info options for applicable exports. Preserve required attribution and delivery information; remove sensitive location data when appropriate. Do not strip all EXIF/IPTC merely to chase an invented saving percentage. Keep masters separate and use the metadata-management guide for a removal-and-readback workflow.
Use compression where the network is the bottleneck
Compare total time and visible quality. A smaller file that requires a long extra encoding pass may not shorten the deadline. Repeatedly resaving a lossy file is also a poor substitute for exporting a new derivative from the working source.
For stills, consider the recipient as well as the browser:
- JPEG: a practical starting point for widely readable photographic viewing and delivery copies, when the agreed workflow accepts lossy compression.
- TIFF: useful when a lab or editing workflow asks for it; it is not a broadly supported browser-gallery preview format.
- AVIF or WebP: possible web-image choices when the hosting service and target browsers support them. Browser support does not by itself establish that the gallery accepts an upload or that the client's print software accepts the download.
MDN's image-format guide describes the format and browser-support tradeoffs. Test representative portraits, dark scenes, smooth skies, fine fabric and group details at the intended viewing size. Inspect the actual delivered copy as well as the local export. No fixed percentage saving applies to every set.
For video, resolution alone is not a file-size specification. Duration, average bitrate, codec, audio and container matter. As arithmetic, a four-minute file with a combined average bitrate of 20 Mbit/s contains about 600 MB of encoded media before container overhead: 240 × 20 ÷ 8. Confirm the receiving platform's accepted format and the client's playback needs rather than changing codecs solely for a smaller number.
Delivery Architecture Client UX and Monitoring
A browser cache can avoid transferring an unchanged resource again on that device. A shared cache or CDN can reduce repeated origin retrievals when the response is cacheable, but bytes still travel from that cache to the client. These are different savings. MDN's caching guide distinguishes private and shared caches.
For private galleries, access rules take priority over cache hit rates. A hosted-gallery customer should not weaken authentication or change caching policy to imitate a public website. Ask the provider for help if repeat loads or failed requests suggest a service issue.
Design the gallery around the next client action
Lead with a clear cover, manageable collections and an explanation of what to view or download. Let the recipient know which files are previews and which are the agreed final set. An organized set can reduce unnecessary searching without promising a particular bandwidth saving.
When comparing gallery services or configuring your own site, check whether the initial view requests suitable thumbnails, whether offscreen images wait until needed, and whether larger views and downloads are requested intentionally. Treat responsive variants, video streaming and interrupted-transfer recovery as capabilities to verify for that service and file type.
In SendPhoto, use the documented upload, collection and download controls in the getting-started guide. Prepare your chosen export in your editor before upload. This workflow does not depend on automatic export presets, guaranteed resumable transfers or a per-gallery efficiency dashboard. Keep required originals backed up independently.
Monitor outcomes instead of only transfer rates
Keep a small comparison record: file count and total bytes, export settings, upload duration, processing wait, first-view conditions and final download result. Repeat comparable observations before deciding that a change helped; one warm-cache visit is not a fair comparison with a first visit.
If you operate the hosting infrastructure, server or CDN logs can add origin traffic and cache hit information. Those logs are not automatically available in a photographer's gallery account, and browser transfer totals are not a provider's billing report. Define “usable gallery” consistently before comparing load times.
A useful support report includes the affected gallery, approximate time, device, connection and the specific failure. Share it privately with the provider; request logs and exported network captures can contain sensitive links or account information.
When More Efficiency Is Not the Right Answer
Saving bytes is worthwhile only if the delivered work still meets its purpose. A small preview that hides retouching defects is not a substitute for a proper final review. A print lab's requirements or a commercial client's handoff specification should govern those files.
A quality-first decision check
Before processing the whole job, answer four questions:
- Final medium: is this for a phone preview, large display, print or further editing?
- Required detail: what dimensions, format, color profile and bit depth were requested?
- Visible quality: are faces, gradients, text and fine details acceptable in the exported copy?
- Agreement and preservation: does this deliver what was promised, while keeping the required originals and backups?
If a smaller candidate fails any of those checks, raise its quality, change the export approach or allow more transfer time. Keep a viewing preset, a client-delivery preset and a master-preservation policy in the tools you actually use. Their purpose is to make the handoff repeatable, not to force every file into the smallest size.
Create a SendPhoto gallery when the intended delivery set is ready. Upload the appropriate files, organize them clearly, and check the client-facing result before sending the link.