Exchange Promo Shop is slow because it ships a 13 MB homepage

Who can change what

SAGE is the CMS and the host. If a row says you cannot change it, it belongs on a SAGE ticket — not in the page builder.

Measured performance

Google Lighthouse 12, mobile emulation, simulated Slow 4G, August 27, 2026. Time to First Byte from this environment was fine (~170–520 ms). The site does not feel slow because the server is “down.” It feels slow because the first screen cannot paint until megabytes of tile images finish.

LCP element: Bags category image (1.png), displayed ~330×330px. 82% of that 59 s is render delay while a 6.81 MB neighboring PNG saturates the connection.

Homepage capture, August 27, 2026. Those three tiles look like small cards. Two of them are multi-megabyte PNGs.

The homepage image bill

Lighthouse estimated 10,176 KB of savings from sizing images to their display size, and 9,315 KB from using JPEG/WebP instead of PNG. Those two audits overlap — they are the same files.

Ten reasons the site is slow

Ranked by how much they hurt real users, not by how interesting they are. Reasons 1 and 2 are the same fire: the homepage tiles.

1. 01Critical impactEasy to fixYou (images)

   Homepage tiles are full-resolution product photos, not web images

   The homepage is a grid of category tiles, but several tiles are original camera/PNG files. Give-aways For Kids uses kcb33.png: a 2700×3495 PNG weighing 6.81 MB. Military Star Bags is 1.52 MB. Lighthouse estimates 10,176 KB of savings from sizing images to the pixels they actually display. On a Slow 4G phone that is the difference between a 3-second page and a 60-second page. This is the one high-impact fix you can make without SAGE: export web-sized JPEGs and replace the files in the CMS.

   • Homepage transfer size: 13.1 MB. Images are 11.6 MB of that (89%).
   • LCP 59.2 s; TTI 59.9 s. Main-thread blocking is only 50 ms — this is a download problem, not a JavaScript problem.
   • kcb33.png is displayed in a column that is a few hundred pixels wide. The file is 9.4 megapixels.
2. 02Critical impactEasy to fixYou (images)

   Photographs are served as PNG instead of JPEG or WebP

   PNG is a lossless format meant for graphics with sharp edges or transparency. Product photos should be JPEG or WebP. Lighthouse’s next-gen format audit estimates 9,315 KB of extra weight from the current files. Re-export the same pictures at 70–80 JPEG quality, 600–800 px on the long side, and land under 80 KB each. SAGE would have to add WebP negotiation; you do not need it if the JPEGs are small.

   • 7 of 8 heavy homepage assets are PNG.
   • The well-behaved tiles (drinkware.jpg, events.jpg, office-products.jpg) are already 11–21 KB JPEGs at 300×300 — proof the platform can serve small images.
   • No srcset, no WebP/AVIF, no width/height attributes, no loading="lazy".
3. 03High impactPolicy, not engineering to fixYou own the zone · SAGE blocked the proxy

   You own Cloudflare, SAGE forbade the proxy, and nobody is running a CDN

   The zone is yours. Nameservers are Cloudflare, but www is grey-clouded to 208.215.218.15 (Quick Technologies origin in Dallas, hostname www.promoplace.com) because SAGE explicitly told you not to turn the proxy on. That leaves the storefront with no CDN, no edge cache, no Brotli at the edge, and no HTTP/3. SAGE also did not put their own CDN in front. The instruction is not crazy from their side — PromoPlace is sticky-IIS, we.dll cookies, and client-IP logic that breaks if they have never tested orange-cloud — but it is not a reason to have zero CDN. It is a reason for SAGE to either bless a Cloudflare config or provide theirs. Do not orange-cloud www against their written instruction; they will blame Cloudflare on the next outage and close the ticket. Do push back in writing.

   • No cf-ray header. HTTP/2 from origin, serverid rotating 2–11 — PromoPlace IIS farm, not Cloudflare.
   • Images get max-age=1209600 (14 days) but still come from Dallas with no edge copy.
   • Apex myexchangepromos.com 301-redirects to www, adding a round trip before the heavy page even starts.
   • Hosting a static report on webreport.myexchangepromos.com via Cloudflare Pages is unrelated: it does not proxy SAGE’s origin.
4. 04High impactEasy for SAGE to fixSAGE / QTI

   HTML and the theme stylesheet are not gzipped or Brotli-compressed

   Requesting the homepage with Accept-Encoding: gzip or br still returns 36,634 bytes of uncompressed HTML. The generated theme CSS (/we/we.dll/StyleSheet) is 173 KB uncompressed. Lighthouse estimates 195 KB of text-compression savings. Static files under /distsite/ often are gzipped; the dynamically generated we.dll and ws.dll responses are not. That is a server-config gap, not a content issue.

   • Homepage HTML: Content-Length 36634, no Content-Encoding, Cache-Control: no-cache.
   • Theme CSS: 173,076 bytes, no Content-Encoding, even though it is public and cacheable for 14 days.
   • Font CSS files (source-sans-3.css, archivo.css) are also uncompressed.
5. 05High impactMedium to fixSAGE theme

   Render-blocking CSS waterfall: 10 stylesheets plus chained @imports

   The <head> loads Bootstrap, Owl Carousel, Flexslider, the entire Font Awesome Pro kit, Slick, Lightbox, Yamm, jQuery UI, Glider, then a 173 KB generated theme sheet. That theme @imports Source Sans 3, Archivo, and webexpress.css. The browser cannot paint until this chain finishes. Lighthouse: 5,920 ms of render-blocking time. 94% of the theme CSS and 99.6% of Font Awesome CSS is unused on the homepage.

   • 13 stylesheet requests, 341 KB transferred.
   • Theme CSS is unminified (Lighthouse: 45 KB of minify savings on CSS alone).
   • CSS references a dead Unsplash URL (source.unsplash.com/… returns 503) and a dozen we.dll/Pic background slots.
6. 06High impactMedium to fixSAGE theme

   Font Awesome Pro is loaded in full — three icon fonts for a handful of icons

   all.min.css is the complete Font Awesome Pro stylesheet (~98 KB compressed). The homepage actually uses a few solid, regular, and brand icons (search, sign-in, cart, card logos). The browser therefore downloads fa-regular-400.woff2 (386 KB), fa-solid-900.woff2 (320 KB), and fa-brands-400.woff2 (108 KB) — 814 KB of icon fonts. Those fonts also lack font-display: swap, so they delay first paint. Two additional display fonts (Source Sans 3 with weights 200–900, Archivo 100–900) are imported for body text.

   • Fonts are the second-largest resource class: 878 KB across 5 files.
   • Lighthouse font-display insight: 220 ms + 150 ms + 35 ms of invisible text.
   • Light, thin, duotone, and v4-compatibility files exist on the server (another ~1.3 MB) even if unused today.
7. 07Medium-High impactMedium to fixSAGE theme

   Every page ships a 20-file jQuery plugin kitchen sink

   Homepage JavaScript is 20 separate files: jQuery, jQuery UI (67 KB, ~89% unused), jquery-migrate, Bootstrap, Slick, Owl Carousel, Flexslider, Lightbox, Highslide, Superfish, hoverIntent, Validate, Backstretch, iframeResizer, a French-Canadian datepicker (datepicker-fr-ca.js) on an English US store, plus custom/builder scripts. Most of these power widgets that are not on the homepage. They still parse, and they still compete with images for connections. Product pages add AddToAny, ElevateZoom, Noty, html5shiv from oss.maxcdn.com, and another Highslide copy inside the iframe.

   • 20 script requests / 208 KB on the homepage. Unused JS audit flags jQuery UI at 59 KB wasted.
   • Three empty <video autoplay muted loop> tags with blank src sit in the page-builder output.
   • Main-thread work is only 0.8 s — JS is not the primary slowness, but it is dead weight on every navigation.
8. 08High on browse/PDP impactHard to fixSAGE platform

   Catalog and product pages load twice: chrome document + iframe storefront

   bags.html (and every category and product URL) is a full WebExpress chrome page that then embeds an iframe to /ws/ws.dll/Showroom or ShowroomDtl. The iframe re-downloads Bootstrap, Font Awesome, the theme CSS (twice — WETheme and WETheme-PS), jQuery, and iframe-resizer. Visitors pay for two documents, two JS runtimes, and a resizer that keeps measuring height. Product detail also pulls third-party AddToAny. This is why category pages feel slow even when they only list two products.

   • bags.html → iframe Showroom?UID=1044294&PageID=23738058&StoreID=457118.
   • PDP /si/3311974233/… → iframe ShowroomDtl?siteID=1044294&ProdID=11974233 (56 KB inner HTML, 18 scripts).
   • iframe HTML is also uncompressed and uncached.
9. 09Medium impactHard to fixSAGE platform

   Images and CSS are generated through we.dll / ws.dll instead of static files

   Logos, theme CSS, and product thumbs are URLs like /we/we.dll/Pic?UN=1044294&F=C&T=801 and /ws/ws.dll/ShowroomPic?…. That is a Windows ISAPI/DLL pipeline on origin, not a file on a CDN. It adds origin CPU, makes caching headers inconsistent, and prevents easy format negotiation (WebP). Combined with no CDN, every new visitor hits application servers for bytes that should be objects in an edge cache.

   • Logo: /we/we.dll/Pic?UN=1044294&F=C&T=801&Age=1554282924 (18 KB PNG, 455×125).
   • Showroom thumbs are 300×300 JPEGs (~12 KB) — the DLL can resize, the homepage builder just is not using it.
   • CSS still references we.dll/Pic HomeSection1–10 and Age=-1 placeholders (1×1 GIFs).
10. 10Medium impactEasy–Medium for SAGE to fixSAGE (headers) · you (only if the builder exposes img attributes)

    HTML is uncacheable, static cache is short, and LCP is not prioritized

    Every HTML document is Cache-Control: no-cache, so browsers and any future CDN must re-fetch the page on every visit. Versioned /distsite/ assets are only cached 4 hours. The LCP image has no fetchpriority="high", no preload, and no dimensions. SAGE’s page builder does not expose those attributes as copy/image fields, so this is a platform ticket unless you find an HTML widget. Lighthouse’s LCP breakdown: 82% of the 59 s is render delay after the Bags image has started loading — the 7 MB Kids PNG is clogging the pipe in front of it. Replacing that PNG (step 1) does more for LCP than fetchpriority ever will.

    • All sampled HTML routes (/, /bags.html, /signin.htm, /cart.htm, PDP) send no-cache.
    • Lighthouse: “fetchpriority=high should be applied” on the LCP <img>.
    • Images missing width/height: every homepage tile.

What should be done, in order

Ordered by a mix of ease, cost, and impact — and by who can actually do the work. Steps 1–2 are yours this week. Step 4 is the Cloudflare fight: do not proxy www against SAGE’s instruction; make them own the “no CDN” outcome. Everything else is SAGE.

Your image work, then the SAGE ticket

Replace the tiles yourselves. Then send SAGE the platform list. Do not ask them for permission to resize JPEGs, and do not orange-cloud www until they put a supported config in writing.

Do this in the SAGE page builder. SAGE is not required.

Replace these homepage tiles with JPEGs, ~800px on the long side, quality ~75, under 80 KB each:

• files/kcb33.png — 6.81 MB, 2700×3495 — Give-aways For Kids
• files/m2180-04.png — 1.52 MB — Military Star Bags
• files/joinourfamilybanner.png — 1.00 MB — Events (hiring poster)
• files/k9714.png — 669 KB — Office Products
• files/1.png — 577 KB — Bags (this is the LCP image)
• files/ktk102_navy.png — 326 KB — Health, Fitness & Safety

Copy the pattern of the small Military Star JPEGs (drinkware.jpg, events.jpg, ~11–21 KB). Keep PNG only for the logo.

Subject: myexchangepromos.com (WebExpress site 1044294) — performance, compression, and CDN

We measured the new Exchange Promo Shop on 27 Aug 2026 (Lighthouse mobile, Slow 4G): Performance 55, Largest Contentful Paint 59.2 s, page weight 13 MB. Time to First Byte was fine (~170 ms). This is payload and platform, not an outage.

We will replace the oversized homepage PNGs ourselves. We need SAGE for everything else.

Please:
1. Enable gzip/Brotli on HTML and on /we/we.dll/StyleSheet and ws.dll responses. Static /distsite/ files already compress; dynamic responses do not. Theme CSS is 173 KB uncompressed.
2. Provide a CDN. You asked us not to orange-cloud www on our Cloudflare zone. We will not do that against your instruction. You also are not running a CDN of your own, so every visitor hits Dallas origin 208.215.218.15. Please either (a) bless a Cloudflare proxy config (Full Strict SSL, cache /files/ and /distsite/, bypass HTML/POST/cart/signin, restore client IP) or (b) put PromoPlace behind your CDN.
3. Add loading="lazy", width/height, and fetchpriority on page-builder images. Those attributes are not available to us as copy/image fields.
4. Stop shipping unused homepage JS/CSS: Owl, Flexslider, Slick, Glider, jQuery UI, Highslide, Backstretch, datepicker-fr-ca.js, and the empty autoplay <video> tags. Replace Font Awesome Pro all.min.css (three font files, 814 KB) with a subset.
5. Confirm whether showrooms can render inline instead of in an iframe (ws.dll/Showroom). Category and PDP currently load the theme twice.

We are not asking for a redesign. Item 1 is a server setting. Item 2 is the gap your “don’t use Cloudflare” policy created.