Slashdot Mirror


Google To Promote Web Speed On New Dev Site

CWmike writes "Google has created a Web site for developers that is focused exclusively on making Web applications, sites and browsers faster. The site will allow developers to submit ideas, suggestions and questions via a discussion forum and by using Google's Moderator tool. Google hopes developers will join it in improving core online technologies such as HTML and TCP/IP. For Google, a prime example of how Web performance can be enhanced is the development of HTML 5, which provides a major improvement in how Web applications process Javascript, Google believes. 'We're hoping the community will spend some time on the basic protocols of the Internet,' Google product manager Richard Rabbat said. 'There's quite a bit of optimization that can be done [in that area].'"

26 of 106 comments (clear)

  1. Why Do They Ignore Their Own Advice? by eldavojohn · · Score: 5, Interesting
    Most of this is helpful but from the HTML piece:

    HTML - as opposed to XHTML, even when delivered with the MIME type text/html - allows authors to omit certain tags. According to the HTML 4 DTD, you can omit the following tags (tags of so-called "void" - empty - elements are marked as strikethrough):

    • </area>
    • </base>
    • <body>
    • </body>
    • (Void Element) </br>
    • </col>
    • </colgroup>
    • </dd>
    • </dt>
    • <head>
    • </head>
    • (Void Element) </hr>
    • <html>
    • </html>
    • (Void Element) </img>
    • (Void Element) </input>
    • </li>
    • (Void Element) </link>
    • (Void Element) </meta>
    • </option>
    • </p>
    • </param>
    • <tbody>
    • </tbody>
    • </td>
    • </tfoot>
    • </th>
    • </thead>
    • </tr>

    For example, if you have a list of items marked up as <li>List item</li>, you could instead just write <li>List item. Or instead of a paragraph that you'd usually close with via </p>, you could just use <p>My paragraph. This even works with html, head, and body, which are not required in HTML. (Make sure you feel comfortable with this before making it your standard coding practice.)

    Omitting optional tags keeps your HTML formally valid, while decreasing your file size. In a typical document, this can mean 5-20 % savings.

    Now, my first reaction was simply "that cannot be valid!" But, of course, it is. What I found interesting is that when I looked at the source for that tutorial they themselves are using </li> and </p>. Interesting, huh? You would hope that Google would follow the very advice they are trying to give you.

    Some of these suggestions may come at the cost of readability and maintainability. There's something about web pages being nice tidy properly formatted XML documents with proper closing tags that I like.

    --
    My work here is dung.
    1. Re:Why Do They Ignore Their Own Advice? by gbjbaanb · · Score: 4, Interesting

      The trouble with web pages is that they are source and 'released binary' all in one file, so if you put comments in (as you always should), and meaningful tag and variable names, then your download gets quite bigger.

      What you really need is a system to 'compile' the source pages to something less readable, but significantly smaller - removing comments, replacing the unneeded end tags, shortening the variable names. If that was automated - so your source files were deployed to the server via this translator, then you'd never even know the difference, except your users on low-bandwidth (ie mobile) devices would love you more.

      We used a primitive one many years ago, but I don't know if there's any improvements to the state of web-page optimisers today.

    2. Re:Why Do They Ignore Their Own Advice? by Anonymous Coward · · Score: 2, Insightful

      Come on now. The price of downloading html and javascript source is peanuts compared to images and flash animations. The solution is better web design, not another layer of complexity in the process. There is no shortage of low-hanging fruit to be picked here. Metric tons, you could say.

    3. Re:Why Do They Ignore Their Own Advice? by Serious+Callers+Only · · Score: 5, Informative

      What you really need is a system to 'compile' the source pages to something less readable, but significantly smaller - removing comments, replacing the unneeded end tags, shortening the variable names. If that was automated...

      Something like gzip compression perhaps?

    4. Re:Why Do They Ignore Their Own Advice? by Anonymous Coward · · Score: 3, Informative

      This is what's called mod_deflate on Apache 2

      I'm using it on a couple small sites I maintain. The text portions of those sites get compressed to less than 50% of their original site. Obviously it does not compress images, pdfs,...
      Obviously there is no need to compress those as they are already properly prepared before they are available online.

    5. Re:Why Do They Ignore Their Own Advice? by BZ · · Score: 5, Informative

      > The price of downloading html and javascript source is peanuts compared to images and
      > flash animations

      That may or may not be true... Last I checked, a number of popular portal sites (things like cnn.com) included scripts totaling several hundred kilobytes as part of the page. The problem is that unlike images those scripts prevent the browser from doing certain things while the script is downloading (because you never know when that 200kb script you're waiting on will decide to do a document.write and compeletely change what you're supposed to do with all the HTML that follows it). So the cost of downloading scripts is _very_ palpable...

    6. Re:Why Do They Ignore Their Own Advice? by quanticle · · Score: 3, Insightful

      The problem with gzip compression (in this case) is that its not lossy. All of the "unnecessary" things that you have (e.g. the unneeded closing tags on some elements) will still be there when you decompress the transmitted data. I think the grandparent wants a compression algorithm that's "intelligently lossy"; in other words, smart enough to strip off all the unneeded data (comments, extra tags, etc.) and then gzip the result for additional savings.

      --
      We all know what to do, but we don't know how to get re-elected once we have done it
    7. Re:Why Do They Ignore Their Own Advice? by Tokerat · · Score: 2, Insightful

      If you save 320 bytes per file, serving 200 different files 750,000 times per day each (imagine some HTML docs that load a bunch of images, JavaScript, and CSS), that's 1.3TB over the course of 30 days. It adds up fast.

      320 was chosen out of the air, as the total length of removed JavaScript comments (320 bytes is the content of 2 full SMS messages), trimmed image pixels, or extraneous tabs in an HTML document. Of course some files will see more page hits than others, some days will see less traffic on the site, and some files/file types are likely to be reduced by different amounts. The question still remains - how you would like to reduce your bandwidth bill and have your users be happier with your site all at the same time? Less traffic, maybe you don't need to bother with it. 500 hits/day sure paints a different picture (915MB/month), but upper-mid-sized sites which rely on leased hosting should really be keeping an eye on this, and it certainly would be good netiquette for everyone to ensure optimized traffic.

      --
      CAn'T CompreHend SARcaSm?
  2. Comment removed by account_deleted · · Score: 2, Interesting

    Comment removed based on user account deletion

  3. C'mon slashdot, get working by Anonymous Coward · · Score: 2, Funny

    We've got to slashdot their site for ultimate irony! :)

  4. Start by eliminating the zero bits by Anonymous Coward · · Score: 2, Funny

    The skinnier ones compress much easier.

    1. Re:Start by eliminating the zero bits by Tokerat · · Score: 3, Funny

      Yes, the 1s are skinny and the 0s are fat. You see, there is more space to compress between a line of evenly spaced 1s than between a line of evenly spaced 0s. If you compress wth too much force, the 0s get "squished", they'll turn into 1s, and this can screw up the formatting and cause segfaults and kernel panics, even in the newer Linux builds. There isn't much that can be done about this, even with today's protected memory designs, so we're limited to removing the space in between. It might help you to think of this technique as the giant laser thingie in "Honey, I Shrunk The Kids!" which recuded the space between atoms of objects in order to shrink them.

      ROR compression (a variation of the .rar format) uses this particular method, replacing the 0s with a counter of how many 0s in a row where replaced, and then compressing the 1s together. This is called "Packed Binary Coding".

      Similar methods where developed by American researchers (Dynamic Unicode Hypertensioning), but instead of simply compressing the 1s, they are instead converted into a pipe character ("|") so as to prevent the tick mark adorning the shaft of the 1 to prevent further compression (or errors resulting from "tilt" when the ones are pressed together too forcefully).

      These are second-year Comp Sci concepts. What is /. coming too when we're not even keeping up with the basics? It's a sad day for geeks everywhere.

      --
      CAn'T CompreHend SARcaSm?
  5. Revolutionary idea by fph+il+quozientatore · · Score: 5, Funny

    I have this great and innovative idea. Take your browser-based e-mail client and word processor, rewrite them in native machine code and run them alongside the browser, as a separate app, instead of inside it. For even more speedup, the data could be stored on the hard drive instead of downloaded from a remote web-site. Never seen before!

    --
    My first program:

    Hell Segmentation fault

    1. Re:Revolutionary idea by JohnnyBGod · · Score: 2, Insightful

      WHOOSH

  6. good idea by burris · · Score: 2, Funny

    As any open source developer knows, what's needed is more ideas, suggestions, and questions. Later, once the discussion group has come to consensus, we'll write some code.

  7. Re:It's a plague. by gmuslera · · Score: 2, Insightful

    I remember when the recommendation was that your webpage in total (counting all resources that includes, code, graphics, etc) couldn't weight more than 50k. What is the average total page size today? 500k? 1Mb? And that loading a lot of resouces between main page, style sheets, javascripts and graphics both small and big (and that gets only worse with flash apps/movies),

    Technology is advancing (i think i read somewhere there that JS processing is 100x faster in modern browsers) and there are a lot of developers tools that give advices on how to improve responsiveness of your site (yes, most of them linked from that google site), so maybe the good part of the web could improve speed in a near future.

  8. Comment removed by account_deleted · · Score: 2, Informative

    Comment removed based on user account deletion

  9. Yahoo has a good page, too by JBL2 · · Score: 2, Informative

    Yahoo! has a handy page (http://developer.yahoo.com/performance/) with lots of good info. It includes YSlow (a Firefox add-on), a set of "Best Practices," and some good research. Also references a couple of O'Reilly books (which, to be fair, I haven't read).

    More specifically, CSS sprites (see http://www.alistapart.com/articles/sprites/) and consolidating Javascript may be back (reducing HTTP requests), and a few other things that may surprise or inform.

    1. Re:Yahoo has a good page, too by POWRSURG · · Score: 2, Interesting

      I am honestly torn on the idea of CSS sprites. While yes, they do decrease the number of HTTP requests, they increase the complexity of maintaining the site. Recently, Vladimir VukiÄeviÄ pointed out how a CSS sprite could use up to 75MB of RAM to display. One could argue that a 1299x15,000 PNG is quite a pain, but in my experience sprites end up being pretty damned wide (or long) if you have images that will need to be repeated or are using a faux columns technique.

      Some times it gets to be a better idea to make a few extra initial requests, then configure your server to send out those images with a far future expires header (which you should do for the sprite anyway). At that point you're just talking about the initial page request, and then subsequent visits get the smaller sized. With one site I am working on the initial page view is hitting 265 KB on the initial view, 4.75 KB for the next month.

      I don't see this mentioned anywhere, but Google has already switched to the HTML5 Doctype. It is much shorter the other flavors.

  10. external resources in HTML pages by reed · · Score: 3, Insightful

    The number one slowdown I see on pages is linking to all kinds of external resources: images, flash movies, iframes, CSS, bits of javascript. Each of these requires at least another DNS lookup and a new HTTP connection, and often those external servers take a really long time to respond (because they're busy doing the same for all those other websites using them). Why is this going on in each users browser? It should all be done behind the scenes on the web server. Why would you put the basic user experience of your users or customers in the hands of random partners who are also doing the same for competing sites? It takes some load off your server, but I think the real reason that people just link in external resources as images, objects, etc is just that it's easier than implementing it in the back end. If you really want to offload work, then design a mechanism that addresses that need specifically.

    We've ended up with a broken idea of what a web server is. Because it was the easiest way to get started, we now seem to be stuck with the basic idea that a web server is something that maps request URLs directly to files on the server's hard disk that are either returned as is or executed as scripts. This needs to change (and it is a little bit, as those "CGI scripts" have now evolved into scripts which are using real web app frameworks.)

  11. Re:What's that sound? by Dragonslicer · · Score: 2, Interesting

    That article says "It's better to use concatenation than double-quoted strings." Every legitimate benchmark I've seen has shown that the difference is zero to negligible. In tests that I've run myself, concatenation actually scales worse; a dozen concatenation operations are slower than one double-quoted string.

    As for using commas with echo, why aren't you using a template engine?

  12. Some very slow sites: Slashdot and Facebook by Animats · · Score: 2, Interesting

    More and more, sites are generating the message "A script on this page is running too slowly" from Firefox. Not because the site is hung; just because it's insanely slow. Slashdot is one of the worst offenders. The problem seems to be in ad code; Slashdot has some convoluted Javascript for loading Google text ads. Anyway, hitting "cancel" when Slashdot generates that message doesn't hurt anything that matters.

    Facebook is even worse. Facebook's "send message" message composition box is so slow that CPU usage goes to 100% when typing in a message. Open a CPU monitor window and try it. I've been trying to figure out what's going on, but the Javascript loads more Javascript which loads more Javascript, and I don't want to spend the debugger time to figure it out.

    1. Re:Some very slow sites: Slashdot and Facebook by WebmasterNeal · · Score: 3, Interesting

      Look at these lovely stats from my Facebook profile:

      Documents (3 files) 7 KB (592 KB uncompressed)
      Images (111 files) 215 KB
      Objects (1 file) 701 bytes
      Scripts (27 files) 321 KB (1102 KB uncompressed)
      Style Sheets (12 files) 69 KB (303 KB uncompressed)
      Total 613 KB (2213 KB uncompressed)

      --
      "During My Service In The United States Congress, I Took The Initiative In Creating The Internet." -Al Gore
  13. Re:What's that sound? by quanticle · · Score: 2, Insightful

    From TFA:

    Sometimes PHP novices attempt to make their code "cleaner" by copying predefined variables to variables with shorter names. What this actually results in is doubled memory consumption, and therefore, slow scripts.

    It seems to me that this is a flaw in the PHP interpreter, not the PHP programmer. The way I see it, the interpreter should be lazily copying data in this case. In other words, the "copy" should be a pointer to the original variable until the script calls for the copy to be changed. At that point the variable should be copied and changed. I believe this is how Python handles assignments, and I'm surprised that PHP does not do it the same way.

    --
    We all know what to do, but we don't know how to get re-elected once we have done it
  14. Yslow vs. Speed by kbahey · · Score: 2, Informative

    For those who are into web site performance, like me, the standard tool for everyone was Yslow, which is a Firefox extension that measured front end (browser) page loading speed, assigned a score to your site/page and then gave a set of recommendations on improving the user experience.

    Now Google has the similar Page speed Firefox extension.

    However, when I tried it, with 5+ windows and 100+ tabs open, Firefox kept eating away memory, and then the laptop swapped and swapped and I had to kill Firefox, and go in its configuration files by hand and disable Page Speed. I have Yslow on the same configuration with no ill effects.

  15. Why do XML closing tags contain the tag name? by Zaiff+Urgulbunger · · Score: 2, Interesting

    One thing I've never really understood is why closing tags in XML have the tag name? Surely the angle brackets with slash inside would be enough since (assuming the markup is valid) it is obvious to the parser which tag is being closed: e.g. (I've used underscores to indent... I can't make the slash-code use spaces!!)
    <html>
    __<head>
    ____<title>Example</>
    __</>
    __<body>
    ____<h1>Example</>
    ____<p><em>This <strong>is</> an</> example.</>
    __</>
    </>

    I know this makes it hard for a human to see opening/closing tags, but if XML parsers (including those in browsers) were able to accept markup with short close tags or the normal named close tags, then we could: 1. benefit where the markup is machine generated and, 2. easily pre-process manually created markup.... it's easy enough to convert back and forth.

    But maybe there's a good reason for not doing this that I'm missing... but it's always bothered me! :D