Flatsome Speed Optimization: Product Grids, Lazy Loading and the Uncacheable Checkout

How Flatsome Classic ships CSS, scripts, images and fonts

UX-Themes makes three speed claims for Classic: its CSS was written for minimum file size, it is the fastest multi-purpose theme on ThemeForest, and its Smart Lazy Loading delays images and backgrounds until they are needed. For the new Site Builder beta, the vendor says page speed is up by a wide margin with better Core Web Vitals out of the box. All of those are the vendor's words. What follows is what you can find, set and check yourself on Classic 3.20.11.

Two things are missing from that table on purpose. Flatsome's public docs do not describe a jQuery option or a choice between inline and file-based CSS, so we will not invent one. If your waterfall shows jQuery and several WooCommerce scripts, assume they are needed until a staging test proves otherwise. Our list of themes with the least CSS and JavaScript puts Flatsome's footprint in context.

Why a Flatsome store slows down in its second year

A new Flatsome store usually tests well. The slowdown arrives with success: more products per category, more apps on the product page, and a homepage that every campaign adds a section to. The usual suspects, in the order we find them:

Our repair checklist for a store that is already crawling is Flatsome slow website. This page is the tuning plan for owners who want to stay ahead of it.

Smart Lazy Loading, by the vendor's description and on your store

Lazy loading is a trade. Images below the fold wait, so the first screen gets the bandwidth. That is a good trade for a category grid. It is a bad one for the image a shopper came to see. If the main banner or the first product photo is lazy-loaded, the browser learns about it late, and Largest Contentful Paint waits. The fix is to look at what your LCP element is on each template, then make sure that one element loads immediately.

Because banner and section backgrounds have their own lazy-load option, you can keep image lazy loading on for grids while turning background lazy loading off if your hero is a banner. Test the change on the homepage and a category page and keep whichever measures better.

Run one lazy-loading system, not three. WordPress adds native lazy loading to content images, and many optimization plugins add their own. Stacking them can leave images waiting on two scripts, or never appearing. Lazy loading can also clash with content that updates without a page reload: one store owner reported a payment provider's logo vanishing from the cart after quantities changed with Flatsome's lazy loading on. If something disappears, switch lazy loading off on staging and see whether it comes back.

Cart and checkout: the pages no cache can hold

Page caching is the cheapest speed win WordPress has, and WooCommerce takes it away exactly where money changes hands. Cart, checkout and account pages show one shopper's data, so every cache plugin worth installing excludes them. Each of those visits runs PHP and database queries from scratch. A header mini-cart that updates live typically adds a background request too; look for get_refreshed_fragments in your browser's network panel.

• Hosting decides these pages. PHP version, PHP workers and an object cache matter more at checkout than any theme option.
• Payment scripts load where they please. Each gateway and payment-messaging widget brings its own code, often on product pages as well as checkout.
• Fewer checkout plugins, faster checkout. Field editors, upsell popups and address autocomplete all run on the slowest page you have.
• Catalog Mode removes the problem outright for businesses that take inquiries instead of orders, because it hides the cart and checkout.

Flatsome's shop settings by name are in our Flatsome WooCommerce guide. If checkout is failing rather than slow, go to Flatsome WooCommerce checkout issues. The structural argument about stores on WordPress versus a coded front end is in WooCommerce vs Next.js.

Tuning a Flatsome store, ten steps in order

Work on a staging copy of the store, change one thing at a time, and retest the same pages after each step. A store is no place for a batch of changes nobody can unpick.

1. 1

   Measure four store templates

   Run a category page, a product page, the cart and checkout through PageSpeed Insights, plus the homepage. Record field data where Google has it. Our guide to running a fair theme speed test keeps the runs comparable.

2. 2

   Update Classic and clear template warnings

   Move to the current Classic release and fix any outdated WooCommerce template warnings before tuning. If registration blocks the update, see Flatsome update and registration problems.

3. 3

   Settle on one cache and one optimizer

   One page cache with cart, checkout and account excluded, and one minify layer. If styles stop changing afterwards, work through Flatsome CSS not updating.

4. 4

   Check fonts are local

   Confirm font files load from /wp-content/fonts/ and that the fallback to the old loading method is off. Cut families and weights in Theme Options > Style > Typography, or turn Google Fonts off and use system fonts. Missing typefaces afterwards: Flatsome fonts not loading.

5. 5

   Set lazy loading per template

   Keep image lazy loading on for grids. If the homepage hero is a banner background, test with background lazy loading off. Remove any second lazy-load plugin.

6. 6

   Resize product photos

   Upload photos close to the largest size the theme displays, regenerate thumbnails and serve WebP through one image plugin.

7. 7

   Put the homepage on a diet

   Replace the slider with one banner, delete sections no campaign uses, and keep the mega menu UX Block to text links and one small image.

8. 8

   Audit product-page apps

   List every script on a product page and who added it. Keep what sells; remove or delay the rest.

9. 9

   Give uncached pages a better server

   Current PHP, enough workers for peak traffic and an object cache. Ask your host what the plan includes before buying a bigger one.

10. 10

    Retest, then watch

    Run the same pages again. Field data lags by up to 28 days, so check again next month.

Core Web Vitals on product and category pages

LCP: the product photo or the banner

On product pages the LCP element is almost always the main photo; on the homepage and categories, a banner. Make it a correctly sized image, keep it out of lazy loading and give it a stable box. Our slow LCP checklist has the mechanics, and LCP on WordPress versus Next.js shows how a framework handles the same image.

CLS: widgets that arrive late

Store layout shift comes from content that shows up after the page: payment messaging under the price, review stars, free-shipping bars, cookie notices and lazy images without dimensions. Reserve space for each one. Theme layout shift explains the fix, and CLS compared with Next.js explains why it keeps coming back on plugin-built pages.

INP: swatches, quick view and add to cart

Interaction delay shows up when a shopper taps a variation swatch, opens quick view or adds to cart while tracking and chat scripts still hold the main thread. Measure on a mid-range phone, not a laptop. INP on WordPress versus Next.js covers the structural side.

Limits inside Flatsome, and what Site Builder changes

• Uncached checkout. No theme setting makes WooCommerce's dynamic pages cacheable.
• WooCommerce and gateway scripts. They load on WooCommerce's terms, not Flatsome's.
• UX Builder markup. Shortcode layouts render into nested wrappers; only rebuilding the page with fewer elements reduces them.
• Third-party apps. Reviews, chat, pixels and payment widgets bring their own weight.
• The server. Slow PHP or a starved database slows every uncached request.

The Site Builder beta, announced September 30, 2026, is UX-Themes' answer to some of this: native blocks and theme.json instead of shortcodes, with the vendor promising faster first paint and less layout shift. It is beta, sold yearly per site, and moving to it means rebuilding UX Builder pages. Test it on staging if you are curious. Do not move a live store for speed alone until it reaches 1.0 and you have measured it on your own catalog. When you would rather have experts tune Classic, our theme speed optimization service and our Flatsome developers do that work; the Flatsome repair hub collects the fixes.

Every cache plugin skips the checkout, which is the one page a store cannot afford to be slow.

When store speed justifies leaving Flatsome for Next.js

Most Flatsome stores should tune, not move. A catalog in the hundreds, a short plugin list and decent hosting can pass Core Web Vitals on Classic. The case for a rebuild is a store where paid traffic lands on product pages, where mobile conversion lags desktop and the limits above are why, or where a redesign is coming anyway and rebuilding UX Builder pages is unavoidable either way.

A Next.js storefront prerenders category and product pages, sizes every photo with next/image and sends cart logic only where it is used. It costs more up front and needs a developer for structural changes. Flatsome vs Next.js lays out the three roads, Flatsome to Next.js covers products, orders and every product URL, and WooCommerce to Next.js explains the commerce side.

Our stores run on Athena CMS, which includes e-commerce, plain fields and every version kept, with Picasso keeping product photos described and sized. Start with a free site audit to see which road costs less, browse the other WordPress theme reviews, or ask about financing for ecommerce builds.