How to Optimize Page Resources: Complete Guide (2026)

Why Total Page Weight Matters

Every byte your page serves has a cost — measured in time, battery, data plan, and ranking position. Page weight directly drives the chain that ends in user experience metrics:

• Bytes drive LCP. Time to First Byte → First Contentful Paint → Largest Contentful Paint all scale with how much the network and main thread have to chew through. The hero image alone often determines LCP on content-driven sites.
• Mobile networks are the floor. On a slow 3G connection, a 1 MB page can take 5–20 seconds to download depending on conditions. Most of the world is not browsing on fiber.
• Google ranks on Core Web Vitals.LCP < 2.5 s, CLS < 0.1, INP < 200 ms. Failing pages lose ground in competitive queries.
• AI search visibility tracks ranking. Generative answer engines preferentially cite pages that already rank well — so page weight is a quiet input into AI citation odds, not just classic SEO.
• Conversions follow speed. Industry analysis consistently finds that every additional second of load time correlates with a measurable drop in conversion rate.

How a Typical Page Breaks Down

Knowing where the bytes go tells you where to spend optimization effort. Based on HTTP Archive data, the typical page weight distribution looks like this:

Images and JavaScript together are 60–85% of the typical page. Optimizing them first delivers the biggest wins by a wide margin.

The Four Levers (In Order)

Pull them in this sequence. Reordering wastes effort — you don't want to compress a script you're about to delete.

1. Cut what's not needed.Remove unused JavaScript, dead CSS rules, fonts you no longer use, and third-party scripts that don't earn their seat. Deletion is always the cheapest performance win.
2. Compress what stays. Minify HTML, CSS, and JavaScript. Choose modern image formats (WebP / AVIF). Enable Brotli or gzip on the server for all text resources.
3. Right-size what's served. Use srcset and sizesso mobile users don't download desktop-sized images. Subset fonts to ship only the glyphs your content actually uses.
4. Prioritize what's critical. Preload the LCP image and critical fonts. Defer non-critical scripts. Lazy-load below-the-fold images and embeds.

How to Audit Before Optimizing

Optimization without measurement is guesswork. Run an audit first so you know which 20% of the page is causing 80% of the weight.

• Greadme deep scan — surfaces oversized images, unused JavaScript, render-blocking CSS, and missing preloads alongside Core Web Vitals, with an AI-generated fix attached to every finding.
• Greadme crawler scan — runs the same audit across every indexable page so you can see which templates are heaviest.
• Greadme AI visibility analyzer — checks how AI answer engines surface your pages, which is downstream of how fast they load.
• Google Search Console → Core Web Vitals report — real-user (CrUX) data on which URLs are failing LCP / CLS / INP.
• Chrome DevTools → Network tab — sort by size to see the largest individual files; the "Coverage" tab shows unused CSS and JavaScript.
• web.dev Measure — quick lab-test report against Core Web Vitals thresholds.

9 High-Impact Optimization Tactics

<picture>
  <source srcset="hero.avif" type="image/avif">
  <source srcset="hero.webp" type="image/webp">
  <img
    src="hero.jpg"
    alt="Product hero"
    width="1200"
    height="600"
    srcset="hero-480.jpg 480w, hero-768.jpg 768w, hero-1200.jpg 1200w"
    sizes="(max-width: 480px) 100vw, (max-width: 768px) 50vw, 1200px"
    fetchpriority="high"
  >
</picture>

<link
  rel="preload"
  as="image"
  href="/hero-1200.webp"
  imagesrcset="/hero-480.webp 480w, /hero-1200.webp 1200w"
  imagesizes="(max-width: 480px) 100vw, 1200px"
>

<img src="below-fold.jpg" alt="..." loading="lazy" width="800" height="600">
<iframe src="https://example.com/embed" loading="lazy" title="..."></iframe>

<!-- Independent, can run any time -->
<script src="/analytics.js" async></script>

<!-- Needs the DOM, but not critical for first paint -->
<script src="/interactive.js" defer></script>

<link
  rel="preload"
  as="font"
  type="font/woff2"
  href="/fonts/inter-regular-subset.woff2"
  crossorigin
>

<style>
  @font-face {
    font-family: 'Inter';
    src: url('/fonts/inter-regular-subset.woff2') format('woff2');
    font-display: swap;
  }
</style>

<style>/* critical above-the-fold rules, ~10 KB */</style>

<link
  rel="preload"
  href="/styles/main.css"
  as="style"
  onload="this.onload=null;this.rel='stylesheet'"
>
<noscript><link rel="stylesheet" href="/styles/main.css"></noscript>

<video
  poster="/video-poster.jpg"
  preload="none"
  controls
  width="1280"
  height="720"
>
  <source src="/clip.av1.mp4" type="video/mp4; codecs=av01.0.05M.08">
  <source src="/clip.h264.mp4" type="video/mp4">
</video>

Common Resource Problems and Fixes

FAQ

What page weight is too heavy?

Performance audits flag pages above 1.6 MB compressed. The HTTP Archive median is around 2.6–2.8 MB, but median is not a goal — most of those pages fail Core Web Vitals on real-user data. Target ≤ 1 MB compressed for content pages and ≤ 1.5 MB for app-like experiences.

Which optimization gives the biggest gain?

For most sites, image optimization. Images are 40–55% of typical page bytes, and converting to modern formats with responsive sources commonly cuts image weight by 50–70% with no visible quality loss.

Should I preload everything?

No. Preload the LCP image and one or two critical fonts — that's it. Over-preloading floods the network and can make LCP worse by competing with the actually-critical resources.

Async vs. defer — which should I use?

Use defer when the script needs the DOM and execution order matters (most app code). Use async for fully independent scripts (analytics, error reporting). Never block first paint with a synchronous <script> tag in the head.

Does optimizing resources actually move Core Web Vitals?

Yes — directly. LCP is the time to render the largest visible element, which is gated by bytes and priority. INP is gated by main-thread work, which is gated by JavaScript size. CLS is gated by reserved space and font-swap behavior. Resource optimization moves all three.

Do AI search engines like ChatGPT and Perplexity care about page weight?

Indirectly. Generative search systems preferentially cite pages that already rank well, and ranking depends on Core Web Vitals — which depend on resource weight. A bloated page quietly hurts both your ranking and your odds of being chosen as an AI citation.

How often should I re-audit?

Quarterly at minimum, plus after any major release or template change. Better: wire performance budgets into CI so a build fails when total JavaScript or image weight crosses a threshold.