Page speed and PDF embeds: when a document slows the page

An embedded PDF viewer downloads the whole file and a block of JavaScript before the page can settle, so it often becomes the LCP element. On a marketing page, link the file or show a preview from PDF to JPG after you shrink it with Compress PDF. Embed only when someone must read the document on the page, and put that embed below the fold.

One homepage <iframe> for an annual report scored an LCP of 6.2 seconds in Lighthouse because the PDF plugin loaded 4.1 MB before any headline. Moving the file to a download link and compressing it cut LCP in half. The document was still there for anyone who needed it.

Contracts, whitepapers, and scanned forms are normal PDF jobs. They rarely belong in the first paint of a marketing page.

Why the embed is slow

A typical viewer does four things:

1. Downloads the full PDF, often 1 to 10 MB or more.
2. Loads viewer JavaScript (PDF.js, a browser plugin, or a third-party widget).
3. Renders the first page on the main thread, next to the hero image and React hydration.
4. Resizes when the toolbar appears, which shifts the layout.

| Embed type | Typical impact | | --- | --- | | Browser native <embed> | Large download; little control | | iframe to /files/report.pdf | Full file fetch on page load | | Third-party viewer SaaS | Extra DNS, scripts, and cookies | | PDF.js custom viewer | A heavy JS bundle plus WASM decode |

Core Web Vitals and images covers image LCP. A PDF embed is the same kind of problem when the document is the LCP element and the file is huge.

Link or embed

| Scenario | Recommendation | | --- | --- | | Blog citing a whitepaper | Text link, with an optional footnote | | Legal terms people must accept | Link that opens in a new tab. Do not iframe it on the homepage | | Product datasheet on a landing page | Thumbnail that links to the PDF | | Course material people read inline | Embed below the fold, lazy loaded | | Portfolio sample | Preview images from PDF to JPG |

The HTML page carries the titles, internal links, and structured data. A slow embed adds a poor experience score on top of that. The PDF URL may rank on its own for document queries. The wrapper page does not need to give up speed to repeat the same content.

Shrink the file before anyone complains

Most of the slowness is the file size:

1. Look at the source. Scan-heavy files grow fast (scan documents to PDF properly).
2. Run Compress PDF at a medium setting and check that the text is still readable.
3. Split PDF when the landing page only needs chapter one.
4. Compare the size with email attachment limits. A file that fails email will fail on a phone browser too.

How PDF compression works covers what changes inside the file. Downsampling images is usually the part that matters.

Publish the useful part as HTML

Google handles HTML better for mixed search results. For a page you expect to keep:

• Export the key pages to Word, edit them, and publish HTML, or write the page in HTML from the start.
• PDF to Word is a rough conversion. Expect cleanup, as in when PDF to Word fails.
• Summarize the PDF on the page and link the full file.

These posts are HTML. PDFs here are files people make, not documents embedded in the hero.

Thumbnail plus a link

This pattern is easier to use than a raw iframe:

<a href="/downloads/product-guide.pdf">
  <img
    src="/downloads/product-guide-preview.webp"
    alt="Preview of product guide cover and table of contents"
    width="400"
    height="520"
    loading="lazy"
  />
  Download product guide (PDF, 890 KB)
</a>

Make the preview from the first page with PDF to JPG, then shrink it with Compress Image. Write alt text that helps SEO on the preview.

If you do have to embed

• Put the embed below the fold so it is not the LCP element.
• Use loading="lazy" on the iframe where the browser supports it.
• Show a static preview first and inject the iframe on click.
• Serve the PDF from a CDN with Cache-Control and range requests.

Measure INP on that click. A heavy viewer still costs time after it loads.

Third-party PDF hosts

A hosted viewer often adds:

• More JavaScript trackers
• A cookie banner inside the iframe
• Cross-origin delay

Check privacy (how browser PDF tools protect privacy) and speed separately. A compressed PDF on your own CDN is often faster than the widget.

PDF.js on the wrong route

A custom viewer bundles PDF.js, on the order of hundreds of KB gzipped. That cost is reasonable on a tool page where working with the PDF is the product, such as Merge PDF or Rotate PDF. It is a poor fit on a marketing page where the PDF is a side document.

Code-split the viewer and load it only on tool routes, not in the site-wide layout.

Phones

Mobile browsers struggle with a large embed:

• Pinch-zoom fights the page scroll.
• Memory pressure kills a background tab mid-read.
• An automatic download burns through a data cap.

The usual mobile pattern is a download link that states the file size, then the phone's own viewer.

How to measure the embed

1. Run Lighthouse on the page with the embed and note the LCP element.
2. Remove or replace the embed.
3. Run it again and compare LCP, TBT, and INP.
4. Check the WebPageTest filmstrip.
5. Check the Search Console Core Web Vitals group for that URL.

Also look at server logs. A PDF linked from the footer of every page can get crawled a lot.

Linked PDFs and embedded PDFs in search

A linked PDF:

• Leaves the page fast, and the anchor text describes the document.
• Can rank in document search from its own title metadata.
• Should have a descriptive filename, such as vertex-solutions-security-whitepaper-2026.pdf.

An embedded PDF:

• Hands the slow vitals to the page URL.
• Can duplicate content if the same file is embedded on many URLs. See duplicate content on tool pages.

Add X-Robots-Tag or a robots.txt rule only when the PDF should not be indexed. That is rare for a public whitepaper.

CMS defaults

A "Media embed PDF" block often iframes the whole file on insert. Change the theme default:

• Turn off auto-embed for the PDF mime type.
• Use a custom block: a button plus the file size.
• Compress on the way into the media library (when should you compress a PDF).

Link the document in the sentence

See our [merge workflow guide](/pdf/merge-pdf) before combining scanned attachments.

Internal linking content clusters is the same idea: these posts link to compression and split tools without embedding a sample file.

Accessibility

Embedded viewers often fail keyboard use and screen readers in ways HTML does not. A link that says what the file is ("Download annual report, PDF") plus a short HTML summary covers both access and speed.

PDF accessibility basics: if the PDF stays public, fix the tags in the source. Embedding does not repair a bad structure.

Related articles

• How to Compress PDF
• Core Web Vitals and Images
• Email Attachment PDF Limits
• Sitemap Priorities Explained

Limits

Reader plugins, CDN settings, and crawl rules differ by host. Test the page with the embed and again with the link, and keep the original PDF.

Treat an embed as the last option. Compress the file, prefer a download link or an image preview, lazy-load anything below the fold, and keep heavy viewers on tool routes where people expect the overhead. A fast HTML page is a better place for the summary than a page carrying a 4 MB iframe.