I moved my own store off Elementor

I run page-speed audits for clients, so it was past time to eat my own cooking. My polymer-clay shop, Itty Bitty Nifty Gifties, was fast on a laptop and fell apart on a phone. Here is exactly what was wrong, what I changed, and the one number I decided to leave alone.

I’ll start with the part most case studies bury: this is my own store, not a client’s, so I get to show you the ugly numbers and the fix that only half worked. That’s the whole point of doing it on my own site first.

What was broken.

Itty Bitty Nifty Gifties ran on WordPress with Elementor, Elementor Pro, and a stack of add-ons on top. On a desktop it looked fine. The homepage scored 88 out of 100 on Google’s PageSpeed test and painted its main content in under a second. On a phone, the same homepage scored 49 and took 16.7 seconds to show that content. The product page was worse: 19.2 seconds on mobile. The cleanest tell was a plain blog post, a text article with no shopping code at all, that scored 99 on desktop and 52 on mobile. A simple article has no business being slow on a phone.

When one page is near-perfect on a laptop and crawls on a phone, the problem usually isn’t the server and it isn’t the photos. I checked both. The server answered in 10 milliseconds (it sits on a VPS behind Cloudflare), and the total image savings the test could find came to about 106 KB, which is nothing. The weight was JavaScript, and most of it didn’t belong on the pages it was loading on.

The 1.7 MB nobody asked for.

About 1.7 MB of third-party JavaScript was loading on every page, whether the page used it or not:

• PayPal’s fraud-detection stack (~797 KB), the single heaviest item. It loads reCAPTCHA and a fraud script that only need to run at checkout. It was running on the homepage, the product pages, and the blog.
• Google Analytics, firing twice (~425 KB), because both the tag plugin and a second tag inside the container were sending the same page view.
• The PayPal checkout SDK (~157 KB), again on pages with no cart in sight.
• The full FontAwesome icon library (~308 KB) for what amounted to a handful of icons.

Almost all of it traced back to the page builder and its add-ons. That is the page-builder cost I keep writing about, made concrete on my own store.

What I changed.

I moved the whole site off Elementor onto a block theme built into WordPress (no builder, no yearly license, nothing sitting between me and the pages). Then I scoped the heavy scripts to where they run: PayPal’s fraud stack and checkout SDK now load on the cart and checkout only, Analytics fires once, and FontAwesome is gone.

I also slimmed the store itself. I had been listing one product per item, which left 206 retired listings and their photos sitting in the library doing nothing. I deleted them, which took the media library from 1.6 GB down to about 674 MB and the catalog down to 52 live products.

Then there was the product page jumping around as it loaded. WooCommerce’s image gallery uses a slider that briefly collapses to almost no height while it starts up, which shoved the rest of the page up and then back down. Measured directly on a phone-sized browser, that shift scored 0.47 (Google wants it under 0.1). The store has one or two photos per product, so I dropped the slider and let the images stack. The shift went to 0. Worth noting: PageSpeed’s averaged mobile run never caught that jump; I only saw it by measuring layout shift directly in a throttled browser, which is a good argument for not trusting a single lab score.

The part where the images didn’t matter.

I spent real time on WebP, the “modern, smaller” image format everyone recommends. On my photos it saved about 10 percent, not the 30 you hear about, because the images were already small. Worse, the only way to serve it without risking the wrong format getting cached was a JavaScript swap that delayed the main image and dragged the mobile score down. So I pulled WebP back out entirely. The store serves regular JPEGs.

Here’s the useful part: when I removed WebP, the page got heavier (the payload went up) and the mobile load time barely moved. That is the cleanest proof I have that the images were never the bottleneck. Anyone who “optimizes the images” and calls a slow site fixed is solving the wrong problem.

What changed, in numbers.

Same pages, same tool (Google PageSpeed Insights), mobile and desktop, before and after:

The homepage and the blog post are real wins, on desktop and on mobile. The blog post in particular went from 52 to 87 on a phone, which is roughly the difference between “people leave” and “people stay.”

The product page is the honest one. Its layout shift is fixed (0.47 to 0), its weight is cut almost in half, and on desktop it’s solid. On mobile it’s better than it was, but it still loads its main image in 8 to 10 seconds, and that number bounces run to run. That’s not “fast.” The remaining delay isn’t the image anymore (the image loads fine); it’s the critical render path, the render-blocking code and the server’s first response under a throttled phone connection. Getting it into the green would mean inlining critical styles, deferring more scripts, and shaving server response time, which is a separate project measured in hours.

Why I stopped there.

I decided not to chase the last few seconds on the product page, on purpose. This store sells most of its work in person at craft shows, so the online traffic is low, and the work-to-payoff on a fully green mobile score didn’t justify itself today. I’d rather tell you that plainly than publish a “we made everything fast” story that doesn’t survive you opening the page on your own phone.

If your site is fast on your laptop and you’ve never checked it on a phone, that gap is worth knowing about, and it’s usually not what you’d guess. If you want me to find where yours lives, that’s a Site Triage.