8 ms·

It's interesting that modern web developers don't consider that maybe websites are slow because they keep stuffing them to the brim with every conceivable scrip

It's interesting that modern web developers don't consider that maybe websites are slow because they keep stuffing them to the brim with every conceivable script and other resources from 30 different domains. No, of course that's not why the web is slow. The web is obviously slow because HTTP is too slow.

Animats 12y ago
Right. Multiplexing over one pipe won't help when content is being pulled in from four ad networks, five trackers, three social networks, a site that hosts Jquery, and another site that hosts fonts. This works for Google because their sites load almost entirely from Googleworld.
- icebraining 12y ago
  So HTTP/2 provides an incentive to put the analytics, jQuery, etc on the main server, reducing third-party spying? Sounds like a win-win to me.
  - ddalex 12y ago
    Sounds like the worst idea ever to me. It will stiffle inovation and adoption of technologies developed by those with not-the-biggest-site-in-the-world. Functioning again as a barier against net neutrality, it goes against everything that made the Internet open and great.
    - icebraining 12y ago
      How will it stifle innovation or function as a barrier against net neutrality?
      - TheLoneWolfling 12y ago
        > function as a barrier against net neutrality? Much easier to throttle traffic from a website when it's actually from a website. If many websites reference the same external resources, it's harder to throttle websites individually.
  - bcoates 12y ago
    No, that's awful. Right now "worthless unwanted crap" cleanly self-identifies itself by hostname, so I can opt-out trivially with a browser extension. Hosting it alongside the content makes that much harder.
    - icebraining 12y ago
      Fair enough, that's a good objection. And I suppose nowadays when third-party cookies are commonly blocked, the benefits are more limited anyway.
acqq 12y ago
Even worse, to have the delivery faster with HTTP2, the developers will have to optimize it even more than now. And we know that that phase of optimization was traditionally ignored by most of those who aren't Google, because it's hard and the benefits for most of the producers non-existent or non-obvious. It's economics that will work against the speedups, just like it was without HTTP2. "Hey boss, I need people to work on optimization of the delivery of every page of our site." "Do we save something? Do we win something?" "No, but to some of our clients the content will appear in three instead of four seconds, if don't use the Google analytics and the Facebook button." "Go away!"
- sauere 12y ago
  Might want to show the boss this: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay...
- insertnickname 12y ago
  Aren't there studies that show that slower pages decrease conversion rates though? Managers might like that... but then again, we really need these share buttons and huge image headers and 10 tracking scripts and Raptorize.
  - acqq 12y ago
    And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up. So you can't claim even the 20% you assumed at the start: "Hey boss, we can't even dream to deliver the pages as Google does, let's just pay them for all the things we want to be our internet presence."
    - personZ 12y ago
      And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up. Aside from the fact that choosing to use those sorts of resources is optional, those (facebook/google+ buttons and likes, etc) are virtually always asynchronous loads -- they do not hold up the render of the root page whatsoever. So if your target is displaying the recipe in 200ms, but the Facebook button takes 400ms -- guess what, the recipe page will still be shown in entirety in 200ms.
personZ 12y ago
No, of course that's not why the web is slow. What is the point of this sort of lowbrow sarcasm, fueled by raw cynicism? Web applications have gotten significantly more complex. From a developer perspective, managing resources separately is a lot easier than using image sprites, giant merged CSS files, etc, though such is often forced because of the known inefficiencies of HTTP. Yes, this seems like an improvement. Are there sites that have other problems? Yeah, sure, of course. That doesn't make it less of a benefit.
- insertnickname 12y ago
  Maybe the problem isn't that trucks are too slow, maybe the problem is that you're shipping too much crap, like JavaScript frameworks that reimplement loading a page. Oh the horror of letting the browser load pages! The point is that the modern web is an abomination. The web isn't for applications, it's for documents, but web developers refuse to acknowledge this, so they do everything in their power to circumvent how the web works (or should work) to avoid making a native application. The world would be much better served by plain, unrendered Markdown documents (or something similar) served statically by an FTP server and rendered appropriately by the client. No JavaScript, no CSS! Just a document. In cases where this is insufficient, build something appropriate to deal with it.
  - personZ 12y ago
    Okay, so you have a strong opinion in a field that you are opposed to. I think that can pretty soundly be discounted by anyone who cares about this industry.
    - wtbob 12y ago
      I care deeply about the Internet, and about the web, and I think that the widespread prevalence of JavaScript-only sites is a plague. Users should not be forced to execute code in order to read text. In a way, JavaScript is equivalent to DRM: it's an unnecessary hoop.
      - 12y ago
programminggeek 12y ago
You are 100% correct. If you look around a lot of sites are 1-2 MB page loads, 100+ HTTP requests and do very little if any image compression. As a result page loads take at least a couple seconds on a good connection, but a 5-10 second page load isn't unheard of. This is what we did for our own site to make it fast: http://retromocha.com/learn/how-we-made-our-website-fast/ http://retromocha.com/learn/how-we-made-our-website-fast/ Honestly, a lot of people could get a lot faster sites if they just put the time and effort towards making them fast. It's not even that difficult, but most don't know or care to make the changes. Google is doing a lot to make this stuff easier, but there are plenty of things holding us back, mostly it's lack of care to make things fast by the average website.

Animats 12y ago

Right. Multiplexing over one pipe won't help when content is being pulled in from four ad networks, five trackers, three social networks, a site that hosts Jquery, and another site that hosts fonts. This works for Google because their sites load almost entirely from Googleworld.

icebraining 12y ago
So HTTP/2 provides an incentive to put the analytics, jQuery, etc on the main server, reducing third-party spying? Sounds like a win-win to me.
- ddalex 12y ago
  Sounds like the worst idea ever to me. It will stiffle inovation and adoption of technologies developed by those with not-the-biggest-site-in-the-world. Functioning again as a barier against net neutrality, it goes against everything that made the Internet open and great.
  - icebraining 12y ago
    How will it stifle innovation or function as a barrier against net neutrality?
    - TheLoneWolfling 12y ago
      > function as a barrier against net neutrality? Much easier to throttle traffic from a website when it's actually from a website. If many websites reference the same external resources, it's harder to throttle websites individually.
- bcoates 12y ago
  No, that's awful. Right now "worthless unwanted crap" cleanly self-identifies itself by hostname, so I can opt-out trivially with a browser extension. Hosting it alongside the content makes that much harder.
  - icebraining 12y ago
    Fair enough, that's a good objection. And I suppose nowadays when third-party cookies are commonly blocked, the benefits are more limited anyway.

acqq 12y ago

Even worse, to have the delivery faster with HTTP2, the developers will have to optimize it even more than now. And we know that that phase of optimization was traditionally ignored by most of those who aren't Google, because it's hard and the benefits for most of the producers non-existent or non-obvious. It's economics that will work against the speedups, just like it was without HTTP2. "Hey boss, I need people to work on optimization of the delivery of every page of our site." "Do we save something? Do we win something?" "No, but to some of our clients the content will appear in three instead of four seconds, if don't use the Google analytics and the Facebook button." "Go away!"

sauere 12y ago
Might want to show the boss this: http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay-in-page-load-can-cause-7-loss-in-customer-conversions/ http://www.tagman.com/mdp-blog/2012/03/just-one-second-delay...
insertnickname 12y ago
Aren't there studies that show that slower pages decrease conversion rates though? Managers might like that... but then again, we really need these share buttons and huge image headers and 10 tracking scripts and Raptorize.
- acqq 12y ago
  And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up. So you can't claim even the 20% you assumed at the start: "Hey boss, we can't even dream to deliver the pages as Google does, let's just pay them for all the things we want to be our internet presence."
  - personZ 12y ago
    And as soon as the buttons and the scripts are delivered from other servers, you effectively can't speed their delivery up. Aside from the fact that choosing to use those sorts of resources is optional, those (facebook/google+ buttons and likes, etc) are virtually always asynchronous loads -- they do not hold up the render of the root page whatsoever. So if your target is displaying the recipe in 200ms, but the Facebook button takes 400ms -- guess what, the recipe page will still be shown in entirety in 200ms.

personZ 12y ago

No, of course that's not why the web is slow. What is the point of this sort of lowbrow sarcasm, fueled by raw cynicism? Web applications have gotten significantly more complex. From a developer perspective, managing resources separately is a lot easier than using image sprites, giant merged CSS files, etc, though such is often forced because of the known inefficiencies of HTTP. Yes, this seems like an improvement. Are there sites that have other problems? Yeah, sure, of course. That doesn't make it less of a benefit.

insertnickname 12y ago
Maybe the problem isn't that trucks are too slow, maybe the problem is that you're shipping too much crap, like JavaScript frameworks that reimplement loading a page. Oh the horror of letting the browser load pages! The point is that the modern web is an abomination. The web isn't for applications, it's for documents, but web developers refuse to acknowledge this, so they do everything in their power to circumvent how the web works (or should work) to avoid making a native application. The world would be much better served by plain, unrendered Markdown documents (or something similar) served statically by an FTP server and rendered appropriately by the client. No JavaScript, no CSS! Just a document. In cases where this is insufficient, build something appropriate to deal with it.
- personZ 12y ago
  Okay, so you have a strong opinion in a field that you are opposed to. I think that can pretty soundly be discounted by anyone who cares about this industry.
  - wtbob 12y ago
    I care deeply about the Internet, and about the web, and I think that the widespread prevalence of JavaScript-only sites is a plague. Users should not be forced to execute code in order to read text. In a way, JavaScript is equivalent to DRM: it's an unnecessary hoop.
    - 12y ago

programminggeek 12y ago

You are 100% correct. If you look around a lot of sites are 1-2 MB page loads, 100+ HTTP requests and do very little if any image compression. As a result page loads take at least a couple seconds on a good connection, but a 5-10 second page load isn't unheard of. This is what we did for our own site to make it fast: http://retromocha.com/learn/how-we-made-our-website-fast/ http://retromocha.com/learn/how-we-made-our-website-fast/ Honestly, a lot of people could get a lot faster sites if they just put the time and effort towards making them fast. It's not even that difficult, but most don't know or care to make the changes. Google is doing a lot to make this stuff easier, but there are plenty of things holding us back, mostly it's lack of care to make things fast by the average website.