UI: No image fallback/loading states for hero section images #197

New Issue

Closed

opened 2026-05-29 16:45:56 -05:00 by null · 1 comment

null commented

2026-05-29 16:45:56 -05:00

Owner

Severity: Minor

Description: All hero sections embed images directly without onError fallback or skeleton loading. If assets fail, users see broken image placeholders.

Files: src/pages/Home.jsx, src/pages/About.jsx, src/pages/Services.jsx, src/pages/Industries.jsx, src/pages/Support.jsx, src/pages/NotFound.jsx

Fix direction: Add fallback images or CSS background gradients to prevent empty space.

**Severity:** Minor **Description:** All hero sections embed images directly without `onError` fallback or skeleton loading. If assets fail, users see broken image placeholders. **Files:** `src/pages/Home.jsx`, `src/pages/About.jsx`, `src/pages/Services.jsx`, `src/pages/Industries.jsx`, `src/pages/Support.jsx`, `src/pages/NotFound.jsx` **Fix direction:** Add fallback images or CSS background gradients to prevent empty space.

null added the

enhancement

labels 2026-05-29 16:45:56 -05:00

null added this to the Batch 11 — UI defects on narrow viewports milestone 2026-08-18 01:24:54 -05:00

null commented

2026-08-18 03:53:38 -05:00

Author

Owner

Closing as no change required — the failure this guards against does not occur, and I checked rather than assumed.

The concern is 'if assets fail, users see broken image placeholders'. Measured against the live site (v0.9.4):

Every image the issue's files reference returns HTTP 200: hero-tech.webp, about-image.webp, local-networking.webp, modern-call-center.webp, 8x8-logo-dark-gray.png, cisco-partner-logo-midnight.svg, veteran-owned-certified-mark.webp, logo.png.
Zero broken images after a full page scroll. document.images filtered on !(complete && naturalWidth > 0) returns 0 of 7 on Home once every lazy image has been scrolled into view.
Layout shift is effectively nil: CLS 0 on Home, 0 on Support, 0.0084 on About, at a 390px viewport. The 'good' threshold is 0.1, so the missing width/height attributes — 5 of 7 images on Home lack them — are not costing anything measurable. That was the strongest argument for touching these tags and it does not hold.
LCP is 220ms and the LCP element is the hero image itself, which already carries loading="eager". Nothing to improve there either.

One honest correction to my own method: an intermediate measurement reported 1 broken image on Home. That was veteran-owned-certified.webp, and it was a false positive in my check — the image is loading="lazy" and below the fold, so the browser had not requested it yet and naturalWidth was legitimately 0. It loads fine when scrolled to, and the URL returns 200. Recording that because the same check will mislead the next person who runs it.

So: there is genuinely no onError handler anywhere in the codebase, and that remains true. But adding fallbacks to ten images to guard a failure that does not happen — on images served from the same origin as the app, where a 404 would mean the deploy itself was broken — is work with no defect behind it.

If image robustness is wanted as a policy rather than a bug fix, that is a different issue and should say so.

Verify: load https://queuenorth.com/, scroll to the bottom, and evaluate [...document.images].filter(i => !(i.complete && i.naturalWidth > 0)).length — it is 0.

Closing as no change required — the failure this guards against does not occur, and I checked rather than assumed. The concern is 'if assets fail, users see broken image placeholders'. Measured against the live site (v0.9.4): - **Every image the issue's files reference returns HTTP 200**: hero-tech.webp, about-image.webp, local-networking.webp, modern-call-center.webp, 8x8-logo-dark-gray.png, cisco-partner-logo-midnight.svg, veteran-owned-certified-mark.webp, logo.png. - **Zero broken images after a full page scroll.** `document.images` filtered on `!(complete && naturalWidth > 0)` returns 0 of 7 on Home once every lazy image has been scrolled into view. - **Layout shift is effectively nil**: CLS 0 on Home, 0 on Support, 0.0084 on About, at a 390px viewport. The 'good' threshold is 0.1, so the missing width/height attributes — 5 of 7 images on Home lack them — are not costing anything measurable. That was the strongest argument for touching these tags and it does not hold. - **LCP is 220ms** and the LCP element is the hero image itself, which already carries `loading="eager"`. Nothing to improve there either. One honest correction to my own method: an intermediate measurement reported 1 broken image on Home. That was `veteran-owned-certified.webp`, and it was a **false positive in my check** — the image is `loading="lazy"` and below the fold, so the browser had not requested it yet and `naturalWidth` was legitimately 0. It loads fine when scrolled to, and the URL returns 200. Recording that because the same check will mislead the next person who runs it. So: there is genuinely no `onError` handler anywhere in the codebase, and that remains true. But adding fallbacks to ten images to guard a failure that does not happen — on images served from the same origin as the app, where a 404 would mean the deploy itself was broken — is work with no defect behind it. If image robustness is wanted as a policy rather than a bug fix, that is a different issue and should say so. Verify: load https://queuenorth.com/, scroll to the bottom, and evaluate `[...document.images].filter(i => !(i.complete && i.naturalWidth > 0)).length` — it is 0.

null closed this issue

2026-08-18 03:53:38 -05:00