Two caveats from doing this, because it does not behave identically everywhere.
On some runtimes it does much less than you expect. If the platform bundles everything and evaluates it up front, a dynamic import may already have been loaded and you save only the evaluation, not the parse. On others the saving is large. This is exactly why the measurement in the first answer matters more than the theory: check the number before and after on one route rather than trusting that it helped.
Dynamic imports change your error surface. An import failure now happens during a request instead of at startup, so a broken dependency reaches a user as a five hundred rather than as a failed deploy. Worth having a smoke test that touches each lazily-loaded route after deploy, since you have removed the check that used to happen implicitly.
And the honest framing for your situation: the biggest win is usually not paying for the PDF library at all on the eleven routes that do not make PDFs - which you can also get by splitting the heavy route into its own deployment unit if your platform makes that easy. That is a larger change and it is the cleanest version, because the cold start of the ordinary routes then has nothing to do with the expensive one at all.