Case study · Our own site · Audit and fix pass

Mobile load time cut from 6.0 seconds to 2.4.

JewSA.com is our cultural-pride content and merch site, with a directory, holiday guides and a small store. We ran the same full technical audit we run for clients, fixed what we found, measured again, and then fixed the store problems the audit surfaced.

Get your own baselineAll case studies

One of our own websites. Every number below comes from our own audit and build records.

JewSA.com homepage on a laptop, a site we built and run
JewSA.com on a phone
Mobile Performance, blog postUp from 77 after the fix pass
jewsa.com · one of our own sites · captured live Oct 9, 2026
6.0s2.4s

mobile Largest Contentful Paint on a blog post

7798

mobile Lighthouse Performance on a blog post

1,2430

pages telling social and AI crawlers they were the homepage

BA-

our audit grade on the technical layer

Lighthouse CLI runs against the live site before and after, plus a crawl of all 1,620 sitemap URLs and 2,689 internal links.

Our sitePublishing and ecommerceTechnical audit and fix pass
The situation

A healthy site with real leaks.

JewSA was in better shape than most sites we audit: clean builds, self-referencing canonical tags on all 1,620 sitemap URLs and zero redirect chains. That made the problems easy to miss.

Blog heroes up to 400 KB loaded as CSS backgrounds, so mobile visitors waited 6.0 seconds for the main content. 1,243 pages told social networks and AI crawlers they were the homepage. The contact form had no spam protection. And in the store, the payment webhook pointed at a URL that redirected, which payment processors treat as a failed delivery.

What we did

Mobile load time on blog posts cut from 6.0 seconds to 2.4.

Lighthouse 98 to 100 across the tested pages after the fix pass, zero broken links across 2,689 internal links, and our own audit grade moved from B to A- on the technical layer.

01 · Speed

Blog posts load in 2.4 seconds.

We converted 14 hero images to WebP, cutting them from 3.2 MB to 0.93 MB, and told the browser to fetch the hero first. We also self-hosted the fonts, which removed a render-blocking request Lighthouse measured at about 790 ms on mobile.

  • Mobile LCP on a blog post: 6.0s to 2.4s
  • Hero images: 3.2 MB to 0.93 MB across 14 files
  • Every tested page scored 98 to 100 on Lighthouse afterward

Mobile load time (LCP), blog post

Lighthouse mobile, before and after the fix pass
Before6.0s
6.0s
After2.4s
2.4s

Lighthouse Performance, before and after

Live site, Lighthouse CLI
02 · Tags and links

Every page says what it actually is.

1,243 of 1,620 sitemap pages inherited the homepage's social preview URL, title and description. Shared on social media or read by an AI crawler, a synagogue listing looked like the homepage. We gave every page its own preview tags and fixed the two broken internal links the crawl found.

  • Wrong social URLs: 1,243 to 0 on the live re-crawl
  • Broken internal links: 2 to 0 across 2,689 links
  • Valid structured data on all 1,620 pages, with no invented ratings
A directory page's social tagsSimplified
Before inherited from the homepage
og:url = jewsa.com/og:title = homepage titleog:description = homepage text
After the page's own
og:url = this page's URLog:title = this page's titleog:description = this page's summary
Simplified. The same fix covered 43 page templates.
03 · Security

Forms and routes locked down.

The contact form now checks where a request came from, uses a hidden honeypot field and a minimum fill time, rate-limits by IP and escapes everything before it reaches an inbox. The content security policy only allows the services the site actually uses, and two high-severity dependency vulnerabilities were patched.

From the JewSA auditReal findings
  • HIGH1,243 pages told social and AI crawlers they were the homepageFixed
  • HIGHContact form had no spam protectionFixed
  • HIGHContent security policy allowed far more than the site neededFixed
  • MEDBlog post mobile LCP of 6.0s from heavy hero imagesFixed
  • MED2 high-severity dependency vulnerabilitiesFixed
  • MED2 broken internal linksFixed
Selected findings, worded for this page. Severity is ours: critical, high, medium, low.
04 · The store

Orders reach fulfillment again.

The audit found the payment processor sending order notifications to a URL that redirected, and processors do not follow redirects on those calls. We pointed it at the final URL. Checkout was also charging $0 shipping while the store paid for it, so with the owner's sign-off we moved to free US and Canada shipping built into the price, updated the cart, product pages, FAQ and product structured data to match.

Where a paid order goesIllustration
Customer pays at checkoutThe payment processor confirms the order.
Before: notification sent to a redirecting URLThe redirect counts as a failed delivery, so the order notice never lands.Failed
After: notification sent to the final URLThe site verifies the signature and passes the order on.Delivered
Print partner makes and ships itFree shipping to the US and Canada, built into the price.
Diagram of the fix, not a dashboard capture.
Process

How the work actually ran.

The same order every time: measure, rank, fix, then measure again and report the result either way.

  1. 01

    Audit

    Crawl, Lighthouse, security, structured data and 18 templates in a real browser at phone and desktop widths.

    Crawled
    Sitemap URLs1,620
    Internal links2,689
  2. 02

    Rank the findings

    Critical, high, medium and low, each with a fix or an owner decision.

    Grade before
    Technical layerB
  3. 03

    Fix pass

    Images, fonts, tags, forms, security policy and dependencies, shipped and live.

    Mobile LCP
    Blog post6.0s to 2.4s
  4. 04

    Store decisions

    The owner signed off on the webhook change and on free shipping built into the price.

    Shipping
    US and CanadaFree
  5. 05

    Measure again

    Same tools, same pages, live.

    Grade after
    Technical layerA-
The honest part

What this pass did not do.

The A- is our own grade of the site's code, not a third-party certification. Lighthouse numbers come from the Lighthouse CLI against the live site, not from Google's field data.

This was a speed, security and tagging pass, not a traffic campaign. We are not claiming a traffic result from it.

Services used

The work on this project maps to these services.

Questions

Case study FAQ

How was the 6.0 to 2.4 second improvement measured?

With Lighthouse on mobile, against the same live blog post before and after the fix pass. Mobile Performance on that page went from 77 to 98.

What caused the slow blog posts?

Hero images up to 400 KB loading as CSS backgrounds, plus render-blocking web fonts. We converted 14 heroes to WebP (3.2 MB down to 0.93 MB), preloaded the hero and self-hosted the fonts.

What does the B to A- grade mean?

It is our own grade of the site's technical layer, from the same audit we run for clients. It is not a third-party score.

What was wrong with the store?

The payment processor's order notifications went to a URL that redirected, which counts as a failed delivery, and checkout charged $0 shipping while the store paid for it. We pointed the notifications at the final URL and moved to free US and Canada shipping built into the price.

Can you run this audit on my site?

Yes. Start with the free live audit and we will show you what we see, then you can decide whether a full audit and fix pass makes sense.

Start free

Want numbers like these for your site?

Book the free live audit. We measure where your site stands today and show you what we would fix first. Or call (702) 609-0182.

Book your free audit →See all results