Skip to content

fix(landing): revert unoptimized removal, compress source images instead#5528

Merged
waleedlatif1 merged 1 commit into
stagingfrom
hotfix-blog-images
Jul 9, 2026
Merged

fix(landing): revert unoptimized removal, compress source images instead#5528
waleedlatif1 merged 1 commit into
stagingfrom
hotfix-blog-images

Conversation

@waleedlatif1

Copy link
Copy Markdown
Collaborator

Summary

  • Fixes the broken blog images on staging. PR fix(landing): fix Core Web Vitals regressions across public marketing pages #5522 removed unoptimized from local blog/library/integration cover images, expecting next/image's runtime optimizer to serve resized AVIF/WebP. That optimizer is failing on staging (root cause still under investigation — /_next/image requests don't go through the app's structured logger, so nothing showed up in application logs). Reverted unoptimized on all 7 spots immediately.
  • Gets the same perf win a different way: compressed the actual source image files (mozjpeg quality 82 for JPEGs, palette PNG for PNGs) at their exact existing pixel dimensions — verified programmatically (dimension mismatch aborts the write) and spot-checked visually. 13 blog/library covers + 3 author avatars + 1 brand logo, ~1.72MB → ~1.02MB combined (~41% smaller), zero resolution change.

Type of Change

  • Bug fix (production/staging regression)

Testing

  • tsc --noEmit clean, biome check clean
  • Verified every recompressed image's width/height matches the original exactly (script aborts on any mismatch)
  • Visually spot-checked several images (a photo avatar, a line-art PNG) for artifacts — none visible

Checklist

  • Code follows project style guidelines
  • Self-reviewed my changes
  • Tests added/updated and passing
  • No new warnings introduced
  • I confirm that I have read and agree to the terms outlined in the Contributor License Agreement (CLA)

…nstead

PR #5522 removed `unoptimized` from local blog/library/integration cover
images, expecting next/image's runtime optimizer to serve resized
AVIF/WebP. On staging, images broke entirely on /blog - the runtime
optimizer is failing there (root cause still under investigation:
_next/image requests aren't captured by the app's structured logger, so
the underlying error wasn't visible in application logs). Reverting
`unoptimized` immediately restores working images.

In its place, this compresses the actual source files (mozjpeg quality 82
for JPEGs, palette PNG for PNGs) at their EXACT existing pixel dimensions -
verified programmatically per-file (dimension mismatch aborts the write)
and spot-checked visually. This gets the same bandwidth/LCP win the
runtime optimizer was meant to provide, without depending on it:

- 13 blog/library cover images + 3 author avatars + 1 brand logo
- ~1.72MB -> ~1.02MB combined (~41% smaller), zero resolution change
@vercel

vercel Bot commented Jul 9, 2026

Copy link
Copy Markdown

The latest updates on your projects. Learn more about Vercel for GitHub.

1 Skipped Deployment
Project Deployment Actions Updated (UTC)
docs Skipped Skipped Jul 9, 2026 1:23am

Request Review

@cursor

cursor Bot commented Jul 9, 2026

Copy link
Copy Markdown

PR Summary

Low Risk
Landing-only display change with no auth, data, or API impact; slightly larger direct image payloads versus a working optimizer.

Overview
Restores unoptimized on seven next/image usages for local landing assets (blog/library author and post covers, integration CTA logo) so images are served directly instead of through /_next/image.

This reverses the prior removal that relied on the Next.js image optimizer on staging, where those optimized requests were failing and cover images broke. Static assets are expected to be kept lean at source (per the PR description’s recompression work) rather than depending on runtime optimization for these paths.

Reviewed by Cursor Bugbot for commit 401d66b. Configure here.

@waleedlatif1 waleedlatif1 changed the title hotfix(landing): revert unoptimized removal, compress source images instead fix(landing): revert unoptimized removal, compress source images instead Jul 9, 2026
@greptile-apps

greptile-apps Bot commented Jul 9, 2026

Copy link
Copy Markdown
Contributor

Greptile Summary

This PR restores direct serving for landing-page images and recompresses the source assets. The main changes are:

  • Added unoptimized back to blog, library, author, and integration images.
  • Replaced public cover, avatar, and logo assets with smaller files at the same paths.
  • Keeps image layout props and public URLs unchanged.

Confidence Score: 5/5

This looks safe to merge.

  • No blocking issues found in the changed code.
  • The only follow-up is a small asset-metadata check for recompressed JPEG avatars.

apps/sim/public/authors/sid.jpg

Important Files Changed

Filename Overview
apps/sim/app/(landing)/components/content-author-page/content-author-page.tsx Restores direct serving for local post-card cover images on author pages.
apps/sim/app/(landing)/components/content-index-page/content-index-page.tsx Restores direct serving for featured and compact content-card images.
apps/sim/app/(landing)/components/content-post-page/content-post-page.tsx Restores direct serving for post hero and related-content images.
apps/sim/app/(landing)/integrations/(shell)/[slug]/page.tsx Restores direct serving for the local brand logo in the integrations CTA.
apps/sim/public/** Recompresses public image assets in place while keeping their paths unchanged.

Comments Outside Diff (1)

  1. apps/sim/public/authors/sid.jpg, line 1 (link)

    P2 Orientation Metadata May Be Dropped

    This avatar was recompressed in place and now bypasses Next's image optimizer because the callers use unoptimized. If the original JPEG depended on EXIF orientation, the browser will render the raw pixels from this file and the author photo can appear rotated or mirrored on author/post pages.

Reviews (1): Last reviewed commit: "hotfix(landing): revert unoptimized remo..." | Re-trigger Greptile

@waleedlatif1

Copy link
Copy Markdown
Collaborator Author

Re: Greptile's EXIF orientation concern on apps/sim/public/authors/sid.jpg — checked all 13 original JPEGs touched in this PR (including sid.jpg) with sharp().metadata() before compressing: every single one reports orientation: undefined, i.e. none carried an EXIF orientation tag to begin with. So there's nothing for the recompression to have dropped/mis-rendered here. Valid category of risk for sharp re-encodes in general, just not applicable to these specific files — verified, not assumed.

@waleedlatif1 waleedlatif1 merged commit 2b09c08 into staging Jul 9, 2026
19 checks passed
@waleedlatif1 waleedlatif1 deleted the hotfix-blog-images branch July 9, 2026 01:28
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant