WoodMart Speed Optimization: The Performance Drawers, the Filters and a Faster Checkout

Six drawers under Theme Settings > Performance

xtemos says WoodMart loads only the CSS and JavaScript each page needs, cutting page size by two to three times, and that stores reach PageSpeed scores above 90 without a separate optimization plugin. Its homepage shows a PageSpeed report with Core Web Vitals passed and a score of 100. Those are the vendor's figures from the vendor's stores. We have not reproduced them, and a demo with twenty products is a different animal from your catalog.

What the vendor does document is a Performance section in Theme Settings, which the docs describe as covering CSS and JavaScript loading, fonts and icons, lazy loading, plugin assets, the preloader, and LCP options. Here is how we treat each drawer on a real store.

The WoodMart review covers the theme as a purchase, and WoodMart for WooCommerce covers the store features in depth. This page is about making those features fast.

Preload LCP Image, read the fine print

The setting lives at Theme Settings, Performance, LCP. In what the docs call Automatic Mode, which they recommend, WoodMart tries to detect the largest image on each page and preload it, telling the browser to fetch it first. There is also a per-page control: in the page editor's Page Settings metabox, a Preload image option lets you set the image yourself. The docs advise setting it separately for desktop and mobile, since the largest element often changes with the screen, and they ask you to say whether the image is a content image or a CSS background, so the right file and its srcset get preloaded.

Two details matter in practice. First, the per-page control only appears on Pages. Single products, posts and shop pages do not get it, because the vendor treats their layouts as predictable. Second, automatic detection guesses. On a homepage built around a slider, check in PageSpeed Insights that the preloaded image is the element reported as LCP. Preloading the wrong image costs bandwidth and delays the right one.

Fonts and images: two defaults worth checking

Load Google Fonts locally sits under Theme Settings, Performance, Fonts & Icons, and the docs say it is enabled by default. It downloads the Google Fonts chosen in Theme Settings to wp-content/uploads/woodmart/google-fonts/fonts and serves them from your server. A companion option sets font-display for text fonts. The fine print: fonts chosen only inside Elementor, WPBakery or Gutenberg blocks may still come from Google's servers, and WoodMart falls back to Google for variants it has not stored. View the page source and search for fonts.googleapis.com. If it is there, WoodMart fonts not loading explains the cleanup.

Images get help from the WoodMart Images Optimizer, a separate plugin installed from the WoodMart plugins screen. It compresses JPEG and PNG files and can generate WebP versions, one at a time or in bulk from the Media Library. As of October 2026 the docs list a free quota of 100 MB, then $3.99 a month for 5 GB. If an image service or CDN already converts your images, do not run both. On lazy loading, the options are lazy loading for images and for block background images, an offset from 0 to 1,000 pixels, a None or Fade appearance effect, a custom placeholder, and a switch to disable WordPress's native lazy loading. The docs say to run only one primary lazy-loading system and never to lazy-load the LCP image.

Filters, swatches and the queries nobody caches

WoodMart's AJAX filters are a selling point: shoppers narrow a category by color, size or price without a full reload. Every combination they choose is a fresh database query, and filtered URLs look like new pages to a page cache, so most are built from scratch. On a large catalog with many attributes, filter traffic, including crawlers following every filter link, can keep the server busy while real shoppers wait. Decide which filtered views deserve indexing and keep the rest out of the crawl.

Swatches have their own settings under Theme Settings, Shop, Variable products. Grid swatch attribute to display chooses which attribute shows on category grids, and Use images from product variations turns swatches into small images. Each swatch on a grid of 48 products is markup the browser has to lay out, and image swatches are extra image requests on the page where shoppers browse most. Show one attribute on grids, prefer color swatches to image swatches there, and save the full set for the product page.

• Do not double up. The vendor's compatibility policy warns about plugins that replace or modify WoodMart's AJAX filters, or duplicate its swatches and wishlists. Two systems doing one job is two sets of scripts and a conflict waiting for an update.
• Watch filter widgets on every page. A sidebar of filters belongs on archives, not on the blog.
• Count variations. Products with dozens of variations make the product page and its swatches heavier. Split very large variable products where the business allows.

When filters or variations misbehave rather than lag, WoodMart WooCommerce issues covers the common faults.

Cart and checkout, the pages the cache cannot touch

WooCommerce cart, checkout and account pages are personal to each shopper, so page caching skips them. Every load there is real PHP and database work, which is why the vendor's server recommendations matter most on these pages: PHP 8.3 or newer, a 256M memory limit, max_execution_time of 180, max_input_vars of 10000 and 64M upload and post sizes. Ask your host what you actually have.

WoodMart's docs describe two cart setups, the Classic Cart built on the WooCommerce cart shortcode and the Block Cart built from blocks, and note that options under Theme Settings, Shop, Cart do not apply to the block cart. On the classic side, extras stack up: Update cart on quantity change sends a request each time a shopper changes a number, and the free shipping progress bar, free gifts and estimated delivery each add their own work to the page. All are useful. Keep the ones that measurably sell, and test cart response time after each one you enable.

Checkout carries the payment gateway's scripts, which you cannot trim, so trim everything else: chat widgets, popups, review badges and marketing pixels that do not need to run while a card number is typed. If checkout fails rather than drags, see WooCommerce checkout not working. Layouts Builder templates for cart and checkout should stay simple; a checkout page is not the place for a carousel.

Eight steps for a faster WoodMart store, by money at stake

1. 1

   Measure the money pages

   Test the homepage, one category page, one product page, the cart and checkout on a phone profile. Record LCP, CLS and INP, plus server response time for cart and checkout.

2. 2

   Check the server against the vendor's list

   PHP version, memory limit, max_input_vars and execution time. A store below the recommendations will be slow and unstable whatever else you tune.

3. 3

   Settle lazy loading

   Choose WoodMart's lazy loading or your optimization plugin's, never both, and make sure the hero and main product image are excluded.

4. 4

   Turn on Preload LCP Image and verify it

   Use Automatic Mode, then set desktop and mobile images by hand on key Pages where detection guessed wrong.

5. 5

   Close the font leaks

   Keep Load Google Fonts locally on and remove fonts set only in the page builder that still load from Google.

6. 6

   Lighten category grids

   One swatch attribute on grids, color over image swatches, and sensible products per page.

7. 7

   Keep filtered pages out of the crawl

   Index the category and key filtered views that earn traffic; keep the endless combinations away from crawlers.

8. 8

   Strip checkout to essentials

   Remove third-party scripts from cart and checkout and review each cart extra against its sales.

Do this on a staging copy, one step at a time, and retest after each. Our theme speed optimization service runs the same list with a changelog, and WoodMart slow website is the repair route when a store is already struggling. If an update undid your settings, see WoodMart update problems.

Core Web Vitals on category, product and checkout pages

LCP: the hero on Pages, the main photo on products

On Pages, Preload LCP Image does most of the work once it picks the right file. Product pages do not get the per-page control, so their main image must be well sized and never lazy-loaded. A slider hero is the common culprit on store homepages. Slow LCP on WordPress themes and WordPress vs Next.js on LCP explain the mechanics.

CLS: header rows, promo bars and filtered grids

A Header Builder header that changes height after the page loads, a promo bar injected at the top, and AJAX filter results replacing a grid of different height all move content. Reserve space for banners and keep header rows fixed in height. See layout shift on WordPress themes and the CLS comparison.

INP: every tap on a store does something

Filter clicks, swatch taps, quick view, add to cart and mega menus all run JavaScript, and store pages often add chat and review scripts on top. Fewer swatches and fewer third-party scripts help most. If the mobile menu fails outright, see WoodMart mobile menu not working; for the metric, WordPress vs Next.js on INP.

What tuning cannot reach, and when a store should move

• Uncacheable pages. Cart, checkout, account and most filtered views are built per request by PHP. Only server power and lighter pages help.
• The builder you picked. Elementor, WPBakery or Gutenberg sets the markup weight of every layout, and changing builders means rebuilding the store's pages.
• Feature weight. Wishlist, compare, quick view, swatches and filters each bring code. WoodMart loads it selectively, by the vendor's account, but the features still run where they appear.
• One vendor, every feature. An update that touches filters, cart and header at once is a single risk across the whole store.

A cache can serve the shop window. Nobody can cache the till.

For most stores, the steps above are the right investment. Speed becomes a reason to leave when catalog size, paid traffic or sale-day spikes make the uncacheable pages the bottleneck. A Next.js storefront prerenders product and category pages, refreshes them when price or stock changes, runs filtering against a prepared index and keeps checkout to a short dedicated path. It costs more to build and needs a developer for structural changes. Compare in WoodMart vs Next.js and WooCommerce vs Next.js for ecommerce, plan with moving a WoodMart store to Next.js, or weigh a sibling theme in WoodMart vs Flatsome. Every theme we cover is listed in the WordPress themes hub, and the WoodMart repair hub has the rest.