[at-fates-hands]

>> That's not the server's fault, it's just Drupal being slow.

Agreed.

I had a static site running on Drupal 7 on Azure and it was really slow. I did a ton of optimizing the front-end code and caching everything I could and it still took between 3-5 seconds to serve pages.

Once I switched to a static site generator, I was floored at how much faster the pages loaded and the performance was night and day; and I was still hosting it on Azure. The only variable that had changed was Drupal.

[geerlingguy]

Something's wrong with either the site architecture (too many modules), the web services used on the front end (something calling a web API on front or backend?), or the infra (slow MySQL?).

I've built some substantial D7 sites and have completely uncached page response times in the median of 100-300ms. Slow, sure, but anything over 1s and I figure out what's causing such abysmal performance.

With PHP 7 on a standard D7 site, those times are down sub-200ms.

And these are sites with over 100 contrib modules, usually 20-30 extra custom modules, and at least a million+ (Mostly anonymous, so those are cached) page views per day.

[aidos]

Surely the only variable that changed was the entire stack? I'm assuming your static generator basically means you're firing a bunch of bytes, probably sitting in RAM out over a socket. No CPU/processing involved, no dynamic anything.

I'll be the last person to defend Drupal, but I don't think it's fair to say that Drupal was the only variable that changed. What about the amount of stuff coming off disk each time, the removal of an interpreted language, the database access?

[ausjke]

While drupal is slow, it is a CMS. How do you do CMS with static html pages? e.g. authentication, classify the content for various access rights, serving dynamic book-module/forum/wiki/nodes/editor/video etc?

I'm not impressed by Drupal's preformance even on a low-traffic site, but then again I could not find a "better" CMS yet.