4 ms·

I am going to guess they are getting a massive surge of traffic about now and yet the site still renders in a fraction of the time it takes most "modern" web ap

by jtms 8y ago

I am going to guess they are getting a massive surge of traffic about now and yet the site still renders in a fraction of the time it takes most "modern" web apps or even just static content sites - this is how it should be.

deleted 8y ago
[deleted]
romaniv 8y ago
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.
- wincy 8y ago
  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.
  - jtms 8y ago
    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 :-)
- pmlnr 8y ago
  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.
  - tootahe45 8y ago
    I find its the bigger sites that have been introducing the slowest/most clunky front-ends. Thinking new Reddit, Tumblr, etc.
- user111233 8y ago
  > 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.
- manigandham 8y ago
  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.
seddin 8y ago
A trillion npm packages will for sure add a couple seconds of delay to your website loading speed.
- acheron 8y ago
  Hey, when you need to pad a string, what else are you supposed to do?
  - coldtea 8y ago
    Yeah, pad it ourselves? What are we, savages?
- blotter_paper 8y ago
  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.
- jtms 8y ago
  `npm install the-entire-universe`

by jtms 8y ago

deleted 8y ago

[deleted]

romaniv 8y ago

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.

wincy 8y ago
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.
- jtms 8y ago
  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 :-)
pmlnr 8y ago
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.
- tootahe45 8y ago
  I find its the bigger sites that have been introducing the slowest/most clunky front-ends. Thinking new Reddit, Tumblr, etc.
user111233 8y ago
> 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.
manigandham 8y ago
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.

seddin 8y ago

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

acheron 8y ago
Hey, when you need to pad a string, what else are you supposed to do?
- coldtea 8y ago
  Yeah, pad it ourselves? What are we, savages?
blotter_paper 8y ago
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.
jtms 8y ago
`npm install the-entire-universe`