4 ms·

Let's make the web faster

60 points by peter123 17y ago

collint 17y ago
for all of google's "dedication" to HTML5 I still can't watch that video without flash. (I assume, staring a blank white space.)
bbuffone 17y ago
"Many websites can become faster with little effort, and collective attention to performance can speed up the entire web..." This is true - I have been working with many over the last 3 years to help them improve web site performance. Most sites will see a huge performance improvement by just concatenating (bundling) their JavaScript and CSS. Tools like; YUICompressor and www.rockstarapps.com Eclipse tools simplify the process. One issue I have found is that developers always leave performance tuning of all projects to the end.
- CodeMage 17y ago
  One issue I have found is that developers always leave performance tuning of all projects to the end. Yep! Here's how that works: 1) You hear "premature optimization is the root of all evil" parroted everywhere. 2) You decide to leave the optimization for the end. 3) You develop code that performs suboptimally, sometimes even abysmally. 4) You develop more code on top of it. 5) You repeat the previous step until the codebase is big enough that optimizing away root causes of performance problems is too painful. 6) By this time you have to deal with releases and bugfixes and feature requests and maintenance and whatnots, so you settle for the advice from Coding Horror, where Jeff told you that throwing hardware at performance problems is cheaper than investing programmers' time in solving them. 7) Profit! Er, no, wait, that's the other list of steps...
  - nostrademons 17y ago
    The right place to insert performance tuning is probably between #3 and #4. It makes perfect sense to leave optimization until you know what you actually want to build. It also makes sense that a piece of code will be no faster than its slowest component. So write the slow version first, but don't build anything on top of it until it's no longer slow. Don't pile crap on top of crap.
  - patio11 17y ago
    In web programming the things that will really give you perceptible speed boosts aren't even optimizations so much as "do it the right way the first time". How hard is it to configure Apache to gzip your textual content? That takes, what, four lines? And it will deliver huge, perceptible boosts to probably six nines of all websites without perceptible downsides? You should require a note signed by your doctor to NOT have that option turned on. Putting all your JS/CSS in one file takes almost no thought in Rails. (:cache => true) If you require multiple sets of included Javascript, you have to make the terribly difficult optimization decision of giving them different names (:cache => "purchasing_scripts") If you're not using Rails, then you might have to actually write code in your build/deploy script, once. (Then you copy/paste it to every project you ever do, because there is never going to be a time when including 6 CSS files individually is a good idea.) Looking at our repository it looks like an ANT script can do it in a dozen lines, so it can't POSSIBLY be that hard in your language of choice.
    - litewulf 17y ago
      Long long ago, gzip would cause some browsers to barf. Some browsers would lie about what they could handle, and you had to check the UA as well as the accept-encoding header. JS/CSS concatenation, at least from the last time I had to roll my own always drove me nuts because I wanted to "recompile" on the fly and thus putting it in my build script meant I had to rebuild with every little change. (I recognize these are excuses. But every action comes with an opportunity cost, blah blah blah)
      - nostrademons 17y ago
        I often copy the uncompressed source directly over the compiled file, make my edits on the live file, and then copy it back when I'm ready to check-in. Granted, the system I work with compiles and doesn't concatenate, which is a slightly simpler problem. But you could easily have your build script leave comment markers in the file (or just look for top-level '(function(){...})()' closures which nearly every sane system uses) and "unbuild" the concatenated file from that.
      - acdha 17y ago
pj 17y ago
This is starting to be kind of obnoxious behavior from google. They only want the web to be faster so people can click back faster and search again and they can get higher throughput on their searches and thus generate more revenue from their advertisers. Google added yet another browser to the list of compatibility issues web developers have to endure so they could shave a few milliseconds off javascript. Now they are nagging us day after day to rewrite our websites to scrape a couple more milliseconds off our load times so they can generate even more revenue. How about Google subsidize all web developers with a $10,000 grant so they can dedicate themselves to implementing the acceleration features they are asking for?
- Devilboy 17y ago
  To be fair most sites should be supporting WebKit already, and Google often provides toolkits and source code for general purpose public use.
  - pj 17y ago
    Oh, if only Chrome and Safari worked identically, then what you said would perhaps be a valid statement.
itistoday 17y ago
It's obvious what the hidden message is here: "We can't compete with desktop applications and operating systems, so we're going to turn the tables on everyone by putting everything on the web where we can kick ass. Err... 'Let's make the web faster! Isn't that a neat idea?'"
- kentosi 17y ago
  you're talking as if it's wrong for a company to look after its own interests?
  - itistoday 17y ago
    Not at all, I'm just pointing it out. It's amusing to me how the PR departments can spin self-interest into purely mutual-interest. I.e. it would be like Mother Teresa helping people because each time she does God cuts her a $10,000 check, and then prattling on about how she's just looking out for you.
skwaddar 17y ago
When you don't know the difference between a protocol and a markup language I don't you should be in charge of writing tech PR.
- silentOpen 17y ago
  While HTML is not a network protocol, it is still a data format that is standardized and to which many implementations need to conform -- a "protocol" in layman's terms. Is XMPP a protocol? Yeah, it specifies a machine-machine communication system but it also specifies the structure and formatting of the messages it sends. Where do you draw the line? If it were a technical discussion, you'd be right that HTML isn't a "protocol". From TFA, I got the sense that they didn't mean a network protocol but something more like a "standard" (without the nasty connotations of that term).
  - sneakums 17y ago
    To a layperson, "protocol" is what you brush up on before you meet a distinguished personage.
  - omouse 17y ago
    So you're admitting that HTML is simply an output format?
  - Confusion 17y ago
    Not just in layman's term. That is what a protocol is: a specification for communication. With reference to the OSI model, HTTP is an application layer protocol. TCP is a network layer protocol. Edit: oh, screw me, the article actually says 'HTML'. I didn't register that and saw 'HTTP'. I'm guessing the author meant that: didn't you ever write HTML when you meant HTTP and didn't catch it until the third reading? Edit2: interestingly enough, the above said 'ISO' instead of 'OSI'...
    - skwaddar 17y ago
      When you're "Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering VP" I expect you to notice in a joint statement of intent.
vaksel 17y ago
before we start worrying about making the web faster, how about organizing a standard for all web browsers to follow? Maybe when developers no longer have to make 5 different versions of their websites, they'd have the time to optimize them for speed .
- prodigal_erik 17y ago
  Being more strict than the standards already are would be horrible. The Web succeeded thanks to the loose coupling between browsers and documents, allowing us to make browsers which behave the way we want instead of merely porting the original browser from TimBL's NeXT. Writing documents which degrade gracefully isn't hard unless you do it backwards (scripted frills before meaningful content).
ironsam 17y ago
Ironically I had performance issues streaming the video on the page. Youtube performance has really gotten spotty over the past year or so. Too bad Google isn't in charge of that...oh wait...
TweedHeads 17y ago
The problem is not in the protocols, the problem is in the pipes.
sfphotoarts 17y ago
I don't see any actual content here. Google thinks the web should be faster. That's obvious. They just say this over and over. We have more pressing problems, like browser compatibility to solve first. Maybe if Google could host a service that would take a page known to work on FF3 and apply magic to it on the fly and make it work on IE6/7/8 etc that would be something useful...
seshagiric 17y ago
"...because our research indicates that people prefer faster, more responsive apps..." I find this very funny. They were possibly screaming Eureka!
yason 17y ago
The web won't become faster. It'll just do more than before and take as much time as before or even slightly longer, just like software and operating systems have evolved so far. The key to fast operation is lowering the work-per-horsepower ratio. This hasn't happened for obvious reasons: imagine the mid-90's world wide web running on modern hardware. Pages would be a few kilobytes. Nearly everything would be instantaneous. Text would be weighted over images. People would be generally unhappy with the simple design. Then they would begin to make sites that are more amazing and flashy and less useful... oops, welcome to the 2010's! :)
FluidDjango 17y ago
How to make the web (experience) faster: Don't use video to present a list of points. Although it's only a 3:30 video, I would rather have been able to scan a list of the quotes (with attribution to authors & their titles)... then I could have know it was only a list of opinions (not a reasoned analysis).
- deleted 17y ago
  [deleted]

60 points by peter123 17y ago

for all of google's "dedication" to HTML5 I still can't watch that video without flash. (I assume, staring a blank white space.)

bbuffone 17y ago

"Many websites can become faster with little effort, and collective attention to performance can speed up the entire web..." This is true - I have been working with many over the last 3 years to help them improve web site performance. Most sites will see a huge performance improvement by just concatenating (bundling) their JavaScript and CSS. Tools like; YUICompressor and www.rockstarapps.com Eclipse tools simplify the process. One issue I have found is that developers always leave performance tuning of all projects to the end.

CodeMage 17y ago
One issue I have found is that developers always leave performance tuning of all projects to the end. Yep! Here's how that works: 1) You hear "premature optimization is the root of all evil" parroted everywhere. 2) You decide to leave the optimization for the end. 3) You develop code that performs suboptimally, sometimes even abysmally. 4) You develop more code on top of it. 5) You repeat the previous step until the codebase is big enough that optimizing away root causes of performance problems is too painful. 6) By this time you have to deal with releases and bugfixes and feature requests and maintenance and whatnots, so you settle for the advice from Coding Horror, where Jeff told you that throwing hardware at performance problems is cheaper than investing programmers' time in solving them. 7) Profit! Er, no, wait, that's the other list of steps...
- nostrademons 17y ago
  The right place to insert performance tuning is probably between #3 and #4. It makes perfect sense to leave optimization until you know what you actually want to build. It also makes sense that a piece of code will be no faster than its slowest component. So write the slow version first, but don't build anything on top of it until it's no longer slow. Don't pile crap on top of crap.
- patio11 17y ago
  In web programming the things that will really give you perceptible speed boosts aren't even optimizations so much as "do it the right way the first time". How hard is it to configure Apache to gzip your textual content? That takes, what, four lines? And it will deliver huge, perceptible boosts to probably six nines of all websites without perceptible downsides? You should require a note signed by your doctor to NOT have that option turned on. Putting all your JS/CSS in one file takes almost no thought in Rails. (:cache => true) If you require multiple sets of included Javascript, you have to make the terribly difficult optimization decision of giving them different names (:cache => "purchasing_scripts") If you're not using Rails, then you might have to actually write code in your build/deploy script, once. (Then you copy/paste it to every project you ever do, because there is never going to be a time when including 6 CSS files individually is a good idea.) Looking at our repository it looks like an ANT script can do it in a dozen lines, so it can't POSSIBLY be that hard in your language of choice.
  - litewulf 17y ago
    Long long ago, gzip would cause some browsers to barf. Some browsers would lie about what they could handle, and you had to check the UA as well as the accept-encoding header. JS/CSS concatenation, at least from the last time I had to roll my own always drove me nuts because I wanted to "recompile" on the fly and thus putting it in my build script meant I had to rebuild with every little change. (I recognize these are excuses. But every action comes with an opportunity cost, blah blah blah)
    - nostrademons 17y ago
      I often copy the uncompressed source directly over the compiled file, make my edits on the live file, and then copy it back when I'm ready to check-in. Granted, the system I work with compiles and doesn't concatenate, which is a slightly simpler problem. But you could easily have your build script leave comment markers in the file (or just look for top-level '(function(){...})()' closures which nearly every sane system uses) and "unbuild" the concatenated file from that.
    - acdha 17y ago

pj 17y ago

This is starting to be kind of obnoxious behavior from google. They only want the web to be faster so people can click back faster and search again and they can get higher throughput on their searches and thus generate more revenue from their advertisers. Google added yet another browser to the list of compatibility issues web developers have to endure so they could shave a few milliseconds off javascript. Now they are nagging us day after day to rewrite our websites to scrape a couple more milliseconds off our load times so they can generate even more revenue. How about Google subsidize all web developers with a $10,000 grant so they can dedicate themselves to implementing the acceleration features they are asking for?

Devilboy 17y ago
To be fair most sites should be supporting WebKit already, and Google often provides toolkits and source code for general purpose public use.
- pj 17y ago
  Oh, if only Chrome and Safari worked identically, then what you said would perhaps be a valid statement.

itistoday 17y ago

It's obvious what the hidden message is here: "We can't compete with desktop applications and operating systems, so we're going to turn the tables on everyone by putting everything on the web where we can kick ass. Err... 'Let's make the web faster! Isn't that a neat idea?'"

kentosi 17y ago
you're talking as if it's wrong for a company to look after its own interests?
- itistoday 17y ago
  Not at all, I'm just pointing it out. It's amusing to me how the PR departments can spin self-interest into purely mutual-interest. I.e. it would be like Mother Teresa helping people because each time she does God cuts her a $10,000 check, and then prattling on about how she's just looking out for you.

skwaddar 17y ago

When you don't know the difference between a protocol and a markup language I don't you should be in charge of writing tech PR.

silentOpen 17y ago
While HTML is not a network protocol, it is still a data format that is standardized and to which many implementations need to conform -- a "protocol" in layman's terms. Is XMPP a protocol? Yeah, it specifies a machine-machine communication system but it also specifies the structure and formatting of the messages it sends. Where do you draw the line? If it were a technical discussion, you'd be right that HTML isn't a "protocol". From TFA, I got the sense that they didn't mean a network protocol but something more like a "standard" (without the nasty connotations of that term).
- sneakums 17y ago
  To a layperson, "protocol" is what you brush up on before you meet a distinguished personage.
- omouse 17y ago
  So you're admitting that HTML is simply an output format?
- Confusion 17y ago
  Not just in layman's term. That is what a protocol is: a specification for communication. With reference to the OSI model, HTTP is an application layer protocol. TCP is a network layer protocol. Edit: oh, screw me, the article actually says 'HTML'. I didn't register that and saw 'HTTP'. I'm guessing the author meant that: didn't you ever write HTML when you meant HTTP and didn't catch it until the third reading? Edit2: interestingly enough, the above said 'ISO' instead of 'OSI'...
  - skwaddar 17y ago
    When you're "Urs Hoelzle, SVP, Operations and Bill Coughran, SVP, Engineering VP" I expect you to notice in a joint statement of intent.

vaksel 17y ago

before we start worrying about making the web faster, how about organizing a standard for all web browsers to follow? Maybe when developers no longer have to make 5 different versions of their websites, they'd have the time to optimize them for speed .

prodigal_erik 17y ago
Being more strict than the standards already are would be horrible. The Web succeeded thanks to the loose coupling between browsers and documents, allowing us to make browsers which behave the way we want instead of merely porting the original browser from TimBL's NeXT. Writing documents which degrade gracefully isn't hard unless you do it backwards (scripted frills before meaningful content).

ironsam 17y ago

Ironically I had performance issues streaming the video on the page. Youtube performance has really gotten spotty over the past year or so. Too bad Google isn't in charge of that...oh wait...

TweedHeads 17y ago

The problem is not in the protocols, the problem is in the pipes.

sfphotoarts 17y ago

I don't see any actual content here. Google thinks the web should be faster. That's obvious. They just say this over and over. We have more pressing problems, like browser compatibility to solve first. Maybe if Google could host a service that would take a page known to work on FF3 and apply magic to it on the fly and make it work on IE6/7/8 etc that would be something useful...

seshagiric 17y ago

"...because our research indicates that people prefer faster, more responsive apps..." I find this very funny. They were possibly screaming Eureka!

yason 17y ago

The web won't become faster. It'll just do more than before and take as much time as before or even slightly longer, just like software and operating systems have evolved so far. The key to fast operation is lowering the work-per-horsepower ratio. This hasn't happened for obvious reasons: imagine the mid-90's world wide web running on modern hardware. Pages would be a few kilobytes. Nearly everything would be instantaneous. Text would be weighted over images. People would be generally unhappy with the simple design. Then they would begin to make sites that are more amazing and flashy and less useful... oops, welcome to the 2010's! :)

FluidDjango 17y ago

How to make the web (experience) faster: Don't use video to present a list of points. Although it's only a 3:30 video, I would rather have been able to scan a list of the quotes (with attribution to authors & their titles)... then I could have know it was only a list of opinions (not a reasoned analysis).

deleted 17y ago
[deleted]