Start with field data, not a screenshot
A perfect Lighthouse run on your laptop tells you almost nothing about a visitor on a mid-range phone over a congested mobile network. Field data, the kind collected by the Chrome User Experience Report or a real-user monitoring script, describes what people actually experience. Treat lab scores as a debugging tool and field data as the scoreboard.
Before changing a single plugin, write down the three numbers that matter: Largest Contentful Paint, Interaction to Next Paint, and Cumulative Layout Shift. Segment them by template. A site rarely has one performance problem; it usually has a slow homepage, an acceptable archive, and a heavy single-post template, each with a different cause.
Find the slow template
Group your measurements by page type instead of looking at a site-wide average. Averages hide the worst offenders, and the worst offenders are where your readers bounce.
- Homepage: usually a hero image, a slider, or a page builder loading every module at once.
- Single post: often a large featured image plus embeds, related-posts widgets and a comment form.
- Archive: commonly a grid that requests full-size images and then shrinks them in CSS.
- WooCommerce or membership pages: frequently uncachable, so every millisecond of server time is exposed.
Fix the biggest offender first
For most WordPress sites the largest win is still the image pipeline. Serve correctly sized files, use modern formats, and never let the browser download a 1600-pixel image to display it at 360 pixels. Preload the one image that is actually the LCP candidate and leave everything else lazy.
add_image_size( 'card', 360, 200, true );
the_post_thumbnail( 'card', array( 'loading' => 'lazy' ) );Then remove work rather than adding plugins. Each extra font weight, slider library and tracking script competes for the same main thread. Re-measure after every change so you know which edit earned its keep.