E:LAB
← Services
Sample report

Preview the result page first.

This is what an unlocked report looks like — modeled on a typical aging WordPress site (Elementor + plugin creep). Your domain will get the same layout with recommendations tailored to your detected stack.

Scenario

5-year-old WordPress site. Elementor + WooCommerce + nine compatibility plugins + a 200KB hero image. The owner knows the site feels slow but has no idea where to start.

example-bakery.com
Performance38/ 100E
Detected stack
WordPress · Elementor · WooCommerce
  • High2
  • Medium2
  • Low1
Estimated impact
Fixing all 5 items shaves about 3,600ms — roughly +25 points on the Lighthouse Performance score.
  • HighJavaScript · ~1,400ms

    1.2MB of unused JavaScript is being loaded

    Elementor and a stack of compatibility plugins inject their full JS bundles on every page — code that's actually needed on the homepage gets downloaded on every other page too.

    ↳ Use the Asset CleanUp plugin to disable plugin assets per page. If only specific pages use Elementor, you can fully turn off Elementor scripts everywhere else.

    4 files Lighthouse flagged ▸
    • Elementor/wp-content/plugins/elementor/assets/js/frontend.min.js320KB saved
    • Elementor Pro/wp-content/plugins/elementor-pro/assets/js/frontend.min.js280KB saved
    • WooCommerce/wp-content/plugins/woocommerce/assets/js/frontend/woocommerce.min.js180KB saved
    • jQuery Migrate/wp-includes/js/jquery/jquery-migrate.min.js50KB saved
  • HighImages · ~980ms

    Hero image is shipped uncompressed

    The large top-of-page image is served at ~2.4MB without compression — the primary driver of poor mobile LCP.

    ↳ Enable Smush or ShortPixel for automatic compression, and switch on WebP conversion. Add loading="eager" + fetchpriority="high" on the hero image to push it up the LCP queue.

    2 files Lighthouse flagged ▸
    • WebP/wp-content/uploads/2023/hero-main.jpg1.9MB saved
    • WebP/wp-content/uploads/2023/section-2-bg.jpg640KB saved
  • MediumRender-blocking · ~620ms

    CSS and JS block first paint

    Elementor CSS and WooCommerce scripts load synchronously at the top of the page, adding ~600ms of wait before the first paint.

    ↳ Enable WP Rocket's "Delay JavaScript Execution" so JS loading defers until the first user interaction. Turn on Critical CSS generation to inline the above-the-fold styles.

    2 files Lighthouse flagged ▸
    • CSS/wp-content/plugins/elementor/assets/css/frontend.min.css120KB saved
    • CSS/wp-content/themes/astra/assets/css/minified/style.min.css65KB saved
  • MediumCaching · ~420ms

    Static assets have no cache headers

    Images / CSS / JS responses are missing Cache-Control, so even returning visitors re-download every asset.

    ↳ Enable WP Rocket's "Browser Cache" option, or add Cache-Control: max-age=31536000 in .htaccess. Pair with Cloudflare's free CDN tier for compound effect.

    2 files Lighthouse flagged ▸
    • no-cache/wp-content/uploads/2023/logo.pngsaved on return saved
    • no-cache/wp-content/themes/astra/assets/js/minified/style.min.jssaved on return saved
  • LowFonts · ~180ms

    Google Fonts loaded synchronously

    Synchronous Google Fonts CSS delays first-text-paint by ~180ms and contributes to CLS.

    ↳ Apply the media="print" onload="this.media='all'" trick in your theme's wp_enqueue_style call, or move font files local with OMGF.

    1 file Lighthouse flagged ▸
    • Google Fontshttps://fonts.googleapis.com/css2?family=Noto+Sans+KR:wght@400;700&display=swap

If the sample feels right, run it against your domain. Score in 5 seconds, full result in 40.

Run an audit →