Property Image Performance Triage Playbook

Slow property images are almost never a memory problem. They are a read-path problem: a missing index forcing full scans, a media store bloated with pictures for records nobody publishes, images stored inside the database instead of on disk, or a feed that mis-renders images the storage layer served fine. This playbook triages those causes in order and gives you a mitigation menu from least to most invasive.

Use this playbook when property or asset images load slowly, fail intermittently, or when the image store has grown large enough to worry about.

Typical triggers:

• Image panels take 13–20 seconds to render on the portal, website, or CRM. [2348]
• The portal intermittently shows "corrupted image" errors on pictures that exist. [2348]
• The image database has bloated — thousands of pictures stored inside it, growing into the multi-gigabyte range. [2348]
• Image imports fail, or a feed shows only one image where several should appear. [2388][2435]

Classify before you touch anything. The blast radius differs sharply by cause.

The dividing line is whether the fault is in the read path or the render path. A slow panel and corrupted-image errors point at the query and storage model. A feed that drops images can be a render bug that storage changes will not fix.

Keep roles generic and named up front so escalation is not improvised.

• Media / on-call owner: runs this triage, owns the decision to take a backup and change indexes or storage.
• Database escalation: owns the schema, indexes, and any migration off the database.
• Comms lead: owns website/portal-facing messaging while images are degraded.

Work read-only first. Take the backup before any change, and measure speed before and after so you can prove the fix. [2348]

[ ] 1. MEASURE the load, don't guess. Time the panel end to end and
       confirm it sits in the 13-20s range rather than a one-off. [2348]
[ ] 2. Rule OUT memory. Check resource use during a slow load; if memory
       is not the constraint, the query path is. [2348]
[ ] 3. Inspect the picture-lookup query plan. A full scan on the
       picture-lookup column means a missing index, not a slow disk. [2348]
[ ] 4. Size the store. Count pictures and total bytes; distinguish
       published/pending listings from old/unpublished ones. [2348][2366]
[ ] 5. Check WHERE images live. Confirm whether pictures are stored
       inside the database or on the file system. [2348][2388]
[ ] 6. If a specific feed is the complaint, view it on mobile. One image
       where several should show is a render bug, not storage. [2435]

Match the symptom to the cause. Each branch points to one mitigation.

Apply the least invasive fix that resolves the diagnosed branch. Take a full backup of all pictures before any destructive change. [2348]

1. Add the missing index. Index the picture-lookup column so lookups stop scanning the whole table; loads drop from 13–20 seconds to milliseconds and the corrupted-image errors clear. Measure before and after. [2348]
2. Purge media for unpublished records. After backing up all pictures, remove images for the old/unpublished properties while keeping those for published and pending listings — a reversible cut that took one store from ~8.6 GB to ~2.4 GB (~8,800 pictures down to ~2,300). [2348]
3. Resize and compress at write. Bound image weight by resizing to 800×600 at the same step where the watermark is applied and saved, and run a one-off script to compress the existing back catalog. Keep the import that auto-deletes leftover unused images so storage stops creeping. [2433][2366]
4. Migrate images out of the database onto file storage. Stage it low-risk: inventory read-only, stand up file storage, point NEW uploads at files first (the most important step), add an alias/mapping table, bulk-migrate existing images, serve from file with a database fallback, update every consumer, then hold a two-month monitoring window before deleting the old copy. This gives near-instant loads and fixes the slow panel, failed imports, and portal image errors. [2388]
5. Restore the feed's multi-image slider. If the complaint is a single feed showing one image or mis-rendering on mobile, fix the carousel — a storage change will not help a render bug. [2435]

Escalate to the database owner when:

• The fix is a storage migration rather than an index, and consumers (website, CRM, portals) must be re-pointed. [2388]
• A destructive purge risks removing media for a record that is actually published or pending. [2348]
• The migration reaches the stage of deleting the old in-database copy before the monitoring window has passed. [2388]

Rollback criteria: if a change regresses loads or breaks a consumer, restore from the picture backup taken before the change. The purge and the migration are both reversible while the backup and the old copy still exist. [2348][2388]

Verify against measured load times and a working portal, not a single lucky page view.

• Re-time the panel after adding the index and confirm loads are in the milliseconds range and the corrupted-image errors are gone. [2348]
• After a purge, confirm every published and pending listing still shows its pictures and the store shrank as expected. [2348]
• After migration, confirm website, CRM, and portals all serve from file storage with the database fallback intact, across the two-month window before deleting the old copy. [2388]

Recovery is complete only when the measured load is fast and every consumer renders images, not when one page happens to load.

Capture, in the incident record:

• The before/after load times and the query plan showing the full scan. [2348]
• The store size before and after the purge, with the picture counts kept versus removed. [2348]
• The consumer list confirmed against file storage after migration. [2388]

Stakeholder comms template:

We identified why property images were loading slowly and occasionally showing errors, and we have corrected it. Images now load quickly across the website and portals. All pictures were backed up before any change, and no listings lost their images.

Run a retro and link it from the incident record. Lock in prevention:

• Index the picture-lookup column and keep it indexed. [2348]
• Bound image weight at write with the 800×600 resize step, and keep imports auto-deleting unused images. [2433][2366]
• Store listing images on the file system, not inside the database. [2388]
• Treat a "broken images" report as possibly a feed/render bug, and check the feed before touching storage. [2435]