Honestly, I'm not even sure what modern website are doing when they generate pages. I've had highly dynamic PHP/MySQL websites running on crap hardware, and it was trivial to attain .03 second page generation time. Didn't even need fancy caching, just some common-sense SQL optimizations.

At my last job we had an ad bidding API that would reach out to every advertiser we worked with, got the highest bid, then presented an advertisement to them.

The page was also framework after framework piled on top of each other, so they’d be using React and jQuery at the same time, stuff like that. And so marketing could change whatever they wanted whenever they wanted without breaking the entire site, everything was served from a CMS.

So it’s probably a lot of that.

LOL - oh man... I can relate!

At a previous gig we had a similar situation. It was so bad my coworkers and I would joke that we needed one of those "break in case of emergency" boxes with the glass front and a hammer hanging adjacent. Inside the box: a can of lighter fluid and a match. The purpose: when the crazy got to be too much you just light own hair on fire and then go run around in traffic.

What you just described would definitely be a break the glass kinda situation :-)

It's crappy wordpress themes.

Before going static as well I made a WP theme with Twig, removing most <?php wp_magic_function(); ?> from there. It was fast, way faster, than the usual WP themes. Obviously nowhere close to a static HTML.

I find its the bigger sites that have been introducing the slowest/most clunky front-ends. Thinking new Reddit, Tumblr, etc.

Its not the HTML generation that's slow, it's everything that comes after. Usually lots of Javascript to run media and ads. Unfortunate, but it's driven by business decisions, not tech.

> just some common-sense SQL optimizations.

Thats probably it. Some beginner has written an n+1 query and the page is slow as shit now.

A trillion npm packages will for sure add a couple seconds of delay to your website loading speed.

Hey, when you need to pad a string, what else are you supposed to do?

Yeah, pad it ourselves? What are we, savages?

That depends on whether or not they are required for first render. Whatever scripts you attach will only be requested after the HTML is delivered, unless they're embedded (most aren't). Isomorphic rendering and rehydration can deliver and render just as fast as a static page, because it is a static page... at first. The problem with modern web page load times isn't the number npm packages bundled for the project, it's that developers/companies, through incompetence, laziness, or a desire to make sure that would-be NoScript users have to run their tracking code before being allowed to view content, don't always render basic content and functionality before requesting that bundle. The only exceptions to this I can think of are scripts that require you to run them before first render, like PayPal buttons that want to inspect everything, make sure they aren't in an iframe, etc.

`npm install the-entire-universe`