Fixing QAJourney.net with PageSpeed & Lighthouse: A QA-Led Debugging Breakdown

I. The Real Use of PageSpeed and Lighthouse in QA

PageSpeed and Lighthouse aren’t gospel. They’re signal tools — good at finding symptoms, but terrible at telling you what actually matters. If you treat their output like a checklist, you’ll optimize your site into the ground and still fail your users.

At QAJourney.net, we used both tools. But we didn’t blindly follow the recommendations. We debugged like QA: trace behavior, confirm root causes, then decide if it’s even worth fixing.

We approached this the same way we debug real systems — not with hype, but with logic. (See: Why Manual Testing and AI Assistance Still Matter)

II. Baseline: What QAJ Looked Like Before the Fix

• Theme: GeneratePress parent, with manual edits (mistake #1)
• Jetpack enabled, plus block plugins we weren’t using
• Lazy loading enabled across the board — including above-the-fold images
• Ad slots prepped, but not inserted yet
• Scores on PageSpeed ranged between 80–90% before the site refresh
• CLS and LCP errors flagged inconsistently depending on browser

Tools said it was fine. But we knew better. QA doesn’t stop when a tool says “pass.”

III. The Debugging Process (QA First, Not Dev First)

1. Cross-Browser Baseline Testing
Ran Lighthouse across Chrome, Firefox, and OperaGX. Chrome showed the worst scores. Firefox felt fastest. OperaGX matched PageSpeed’s layout shift complaints.

QA Takeaway: Simulated scores don’t equal real load. Observe behavior.

2. Traceability Breakdown
We traced layout shift triggers. Most came from leftover Jetpack CSS and dynamic height elements with no static containers. Some issues only happened after cache.

QA Takeaway: Reproduce across sessions. Then confirm root causes — don’t guess.

IV. Fixes That Actually Worked (Per QA Diagnosis)

✅ Moved to a GeneratePress Child Theme
We rebuilt from scratch using a child theme. All previous fixes on the parent were wiped by updates. Not again.

• Moved all layout and performance logic to child theme files
• Built reusable, testable asset handling through functions.php
• Update-safe and regression-free

✅ Eager Load Critical Elements Only
PageSpeed flagged LCP delays due to lazy loading on hero sections. We updated image tags above the fold to use loading="eager".

✅ Dequeued Dead Scripts and Styles
Jetpack bloat, emoji scripts, block libraries — all disabled. Nothing loaded unless we needed it.

// Remove emoji support
remove_action('wp_head', 'print_emoji_detection_script', 7);
remove_action('wp_print_styles', 'print_emoji_styles');

// Disable Gutenberg block styles
function qaj_dequeue_block_styles() {
    wp_dequeue_style('wp-block-library');
    wp_dequeue_style('wp-block-library-theme');
}
add_action('wp_enqueue_scripts', 'qaj_dequeue_block_styles', 100);

// Remove Jetpack CSS
function qaj_remove_jetpack_css() {
    wp_deregister_style('jetpack_css');
}
add_action('wp_enqueue_scripts', 'qaj_remove_jetpack_css', 100);

V. What the Tools Reported After the Fix

📊 PageSpeed Insights Report (May 26, 2025)

We retested using PageSpeed Insights after the rebuild. The desktop score dropped to 49, revealing deeper problems now surfaced by the new layout.

Top Issues Flagged:

• LCP: 3.1s
• CLS: 1 (Critical)
• JS Execution: 1.8s
• Total JS Payload: 3.2MB
• Image optimization: lacking WebP/fallback tagging

🔦 Lighthouse Audit via Chrome DevTools (Post-Refresh)

We ran Lighthouse from DevTools after the refresh. It flagged a performance score of 36, with LCP at 6.1s and nearly 1.0 CLS.

Page fonts (Google Fonts) were flagged, unused JS weight hit 1.4MB, and render-blocking resources stacked up.

📉 GTmetrix Report (Bonus Run)

To validate across tools, we ran GTmetrix after the rebuild. It gave us a C (64%) for performance, with structure at 97%.

Web Vitals showed:

• LCP: 2.2s
• TBT: 82ms
• CLS: 0.8

QA Insight: Before the rebuild, we only checked PageSpeed — and it looked fine. After the rebuild, we ran deeper tests. The truth came out.

VI. Before & After (QA-Level Comparison)

We didn’t chase numbers — we chased stability and trust in system behavior.

VII. QA Takeaways for Any Live Site

• Don’t treat PageSpeed as truth — it’s a lab environment, not field data
• Always test across multiple browsers and caching states
• Fix above-the-fold loading issues only where it matters
• Use a child theme — never touch the parent
• Kill plugin bloat at the code level, not just in the dashboard
• Don’t optimize what you haven’t debugged

VIII. Final Notes

QAJourney.net is now debugged and prepared for AdSense review — but this wasn’t just about monetization.

This was about QA taking ownership of the stack. Not just the test cases. Not just the product. But the platform.

We QA everything — including the blog that tells the story.

We’ve also been thinking a lot about what not to trust in the SEO space — especially with AI content flooding the web. Here’s our take. and prepared for AdSense review — but this wasn’t just about monetization.

This was about QA taking ownership of the stack. Not just the test cases. Not just the product. But the platform.

We QA everything — including the blog that tells the story.