Why is the performance score low in lighthouse audit?
First, make sure you are auditing a blog post URL (yourwebsite.com/blog/post-abc-123) and not the blog index (yourwebsite.com/blog). Also enter the URL exactly as it is served — if your post URLs have no trailing slash, audit without one, otherwise the audit measures a redirect and loses ~0.5s for no reason. Run the audit 2–3 times: the first run can hit cold CDN caches.
What Superblog already optimizes for you
Every Superblog page ships with the technical optimizations pre-done, so you never have to think about them:
Fonts are self-hosted on your own domain (no Google Fonts round-trip) and render with metric-matched fallbacks, so text appears instantly and never shifts the layout (near-zero CLS).
Your post's hero image is preloaded with high priority, and every below-the-fold image lazy-loads automatically.
HTML and CSS are minified, cached at the edge worldwide, and served with zero render-blocking third-party requests.
Scripts you add via "Miscellaneous Scripts" are automatically kept off the critical path (more below).
A well-configured Superblog post typically scores 90+ on mobile. When a score comes back lower, it is almost always one of the two factors below — both under your control.
1. Heavy hero images (the most common cause)
The first image of your post is usually the largest element on the screen, so Google's LCP metric is essentially measuring how long your hero image takes to download on a throttled mobile connection. A 400–500 KB image adds 2–3 seconds to LCP on its own and can drag an otherwise-perfect page from 95 down to 65.
What to do:
Keep your featured/hero image under ~150 KB — ideally under 100 KB.
Use WebP or JPEG for photos, banners, and AI-generated images. PNG is only appropriate for screenshots and sharp-edged graphics — a photographic PNG is routinely 10× larger than the same image as WebP with no visible difference.
There is no need to upload wider than ~1400px; blog content displays at ~700px.
If you re-export an existing hero as WebP and re-upload it, your score typically recovers on the next audit.
2. Third-party scripts (analytics, pixels, chat widgets)
Tags like Google Tag Manager, Meta Pixel, Microsoft Clarity, HubSpot, and chat widgets run JavaScript on the main thread while the page loads. A typical marketing stack of 4–5 tags adds 500–700 ms of Total Blocking Time — enough to cost 15–20 points by itself.
Superblog gives you two script sections in Dashboard → Settings → Integrations, and the choice between them is the performance contract:
Miscellaneous Scripts (recommended for tags): scripts here are loaded only after the visitor's first interaction (scroll, tap, or key press), or within 10 seconds at the latest. Your analytics still records every engaged visitor — but the scripts no longer run during page load, so they have no effect on your Lighthouse / PageSpeed score and the page stays responsive at the moment the visitor starts reading.
Head Scripts: run immediately, before the page renders. Use this only for scripts that genuinely must execute first — cookie-consent managers and A/B-testing anti-flicker snippets. Any heavy tag placed here will lower your score.
If your score is low and you have tags in Head Scripts that aren't consent or A/B tooling, moving them to Miscellaneous Scripts usually recovers the points immediately after the next publish.
Other things to check
Subdirectory setups (yourwebsite.com/blog): your own server proxies the blog, so its speed sits in front of everything Superblog does. Make sure your reverse proxy is fast and forwards all blog asset paths.
Custom HTML widgets embedded in a post (iframes, third-party embeds) can add their own weight; audit a post without them to compare.
Lab vs field data: the score at the top of PageSpeed Insights is a simulated throttled-mobile lab test. The "Discover what your real users are experiencing" section shows real Chrome-user data — it is common (and fine) for real-user Core Web Vitals to pass even when a lab run scores lower.