Turn a speed test report into a prioritized fix list
A scenario prompt that diagnoses a real 41/100 PageSpeed report against a specific shared-hosting, page-builder stack, ranking fixes by what's actually feasible, not just what the report lists first.
Works with Claude / GPT720 uses★ 4.5
The prompt
pagespeed-report-to-fix-list
A client's WooCommerce store just scored 41/100 mobile on PageSpeed Insights. Here's
what the Diagnostics section flagged:
[- Eliminate render-blocking resources: 1.2s savings, mostly from a slider plugin's
CSS loading in <head> on every page including ones without a slider
- Reduce unused JavaScript: 800ms, largely from a page builder's frontend bundle
loading sitewide
- Largest Contentful Paint image not preloaded: hero image on homepage]
HOSTING: [shared hosting, no server-level caching, PHP 8.1]
ACTIVE PLUGINS: [WooCommerce, Elementor, a slider plugin, a caching plugin set to
default settings]
Work through this as a performance consultant would, not by relisting the report:
1. Rank the three findings by real-world impact versus how risky the fix is to
implement, given this is shared hosting with no dev-level server access. That
changes which fixes are even available compared to a VPS.
2. For each, name the specific likely cause given the plugin stack. The slider CSS
loading sitewide, for example, is almost certainly the slider plugin not
conditionally enqueuing its assets, so name the setting or code fix, not just
"check the slider plugin."
3. Give the exact fix: a plugin setting, a snippet using `wp_dequeue_style` or
`wp_dequeue_script` scoped correctly so it doesn't break the slider where it's
actually used, or a caching plugin setting to enable.
4. Flag which of these, if any, actually need a hosting upgrade (if the caching
plugin is already maxed out and TTFB is still slow, for example) versus which are
fixable purely from wp-admin.
5. Warn specifically about the risk of over-aggressively dequeuing the page builder's
JS sitewide. Elementor-built pages elsewhere on the site could break if the fix
isn't scoped per-template.
Two sites with the identical “eliminate render-blocking resources” warning can need
completely different fixes depending on hosting and plugin stack. That’s why this
reasons from the stack, not the raw score, and why step 5 exists: the most common way
these fixes go wrong is a global JS deferral that quietly breaks a builder-made page
somewhere else on the site.
Pro tip: paste the full “Diagnostics” section from PageSpeed Insights, not just the
score. The score alone gives this nothing to reason about.