Broken Images After Publishing to a Case-Sensitive Host
A site is developed on Windows (case-insensitive filesystem). All images live in Images/ with a capital I, but many <img> tags reference images/photo1.jpg in lowercase. Locally everything displays. The team publishes via Dreamweaver's FTP to a Linux host (case-sensitive). After upload, roughly 40% of images 404 on the live site, while the same pages look perfect in local preview. Separately, two large hero images (2.8 MB and 3.1 MB each) load slowly on mobile, and the client asks why the site "feels heavy" even though the HTML is small. The site definition's testing server is set to the same remote, and "Check Links Sitewide" was last run before the case mismatch was introduced.
1. Explain why local preview passes but the live host 404s, and why the stale link check gave false confidence.
Read the worked answer
Windows treats Images/ and images/ as the same folder, so every lowercase reference resolves locally. The Linux host treats them as different names, so images/photo1.jpg matches nothing and returns 404. Same HTML, different filesystem semantics - a deployment-environment bug, not a markup bug visible in preview.
The stale Check Links Sitewide result is misleading because it ran before the case mismatch was introduced, against a cache that predates the bad references. A link check is only as current as the site cache; if files were added/renamed since, the report is fiction.
Fix: correct the case in the <img> references to match disk (Images/...), or standardize the folder to all-lowercase and update references, then recreate the site cache and re-run Check Links Sitewide. Going forward, adopt an all-lowercase naming convention so the case-insensitive/case-sensitive gap can't bite again.
2. The HTML is small but the site feels heavy on mobile. What is the most likely cause, and what should be done before and during publishing?
Read the worked answer
The two hero images total ~5.9 MB. Images dominate page weight; small HTML doesn't offset multi-megabyte JPEGs, and mobile connections expose that immediately.
Before publishing:
- Optimize the images - resize to the maximum displayed dimensions, compress (e.g. export at appropriate quality, or use WebP with fallback), targeting well under a few hundred KB each for heroes.
- Consider responsive image techniques (
srcset/sizesor<picture>) so phones download a smaller variant rather than the desktop hero.
During/around publishing:
- Use Dreamweaver's asset/link checking and confirm the optimized files are the ones uploaded (watch for the local cache still pointing at old large files).
- Verify on the live host (not just local preview), since that's where the weight and the case-sensitivity issues both surface.
The judgment call: don't add a CDN or lazy-loading band-aid before fixing the actual payload - a 3 MB hero defeats lazy-loading if it's above the fold.