My free PDF tools site PdfWord had a problem: the installed PWA took forever to open on phones. Users complained. Here's the 20-minute fix that cut 98.5% of the weight.
The diagnosis
I measured what the homepage actually downloads:
| Library | Size |
|---|---|
| html2pdf.bundle.min.js | 884 KB |
| xlsx.full.min.js | 861 KB |
| docx.min.js | 725 KB |
| pdf-lib.min.js | 512 KB |
| pptxgen.bundle.js | 466 KB |
| jspdf.umd.min.js | 410 KB |
| pdf.min.js | 312 KB |
| …plus 25 more scripts | … |
Total: 4.8 MB of JavaScript — on a landing page.
The homepage is just cards that link to tool pages. It needed none of these. Every library was loaded "just in case," plus 22 dead inline tool panels from an older design.
The fix
- Deleted the 22 dead tool panels from the homepage (dedicated tool pages already existed — 25 KB of dead HTML gone).
-
Removed all 33 heavy
<script>tags from the homepage. Each tool page still loads only the libraries it needs (selective per-page loading). -
Kept one file:
common.js(15 KB) for navigation, theme toggle, and filters.
Result: 54 KB HTML + 15 KB JS = ~70 KB total. Down from 4.8 MB.
The service worker lesson
I also found the service worker was precaching ~2 MB of libraries on install. Trimmed the precache to the app shell only (~120 KB); heavy libs now cache on-demand when their tool page is first opened. And HTML uses a network-first strategy so updates reach installed apps without reinstalls.
Rule I now follow: bump the SW cache version on every deploy, or installed apps serve stale files forever.
Results
- Page load: 422 ms (Cloudflare Web Analytics, real devices)
- Core Web Vitals: 100% Good across LCP, INP, CLS
- PWA opens instantly on 4G
The takeaway: audit what your landing page actually needs. "Just in case" script tags are the silent killer of mobile performance.
PdfWord is a free, no-signup, client-side PDF toolkit — 27 tools, installable as a PWA, works offline. Built with vanilla JS and pdf-lib.
Top comments (0)