Google To Promote Web Speed On New Dev Site 106
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].'"
Why Do They Ignore Their Own Advice? (Score:5, Interesting)
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 [w3.org], you can omit the following tags (tags of so-called "void" - empty - elements are marked as strikethrough):
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.
Comment removed (Score:3, Interesting)
Re:Why Do They Ignore Their Own Advice? (Score:5, 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.
Just write a native client-side app (Score:2, Interesting)
Yes I realise that for n00bs its all about the convenience of web apps but client-side apps need not be inconvenient. Look at the iPhone app store, n00bs love it and its full of client-server applications. If there was something like it for Windows and OS X we'd never need to work with a horrible "web application" ever again. Linux doesn't need any, package managers could do with a bit more eye-candy and buttons with round edges for n00bs but for the rest its fine.
I'm all for optimising web pages but one should focus on minimalism, only use AJAX in cases where it actually saves bandwidth rather than using it for useless playthings. Use a CSS compressor, gzip compression, strip out useless eye-candy and effects, use as little javascript as you can get away with.
Modern web design thrives on feature-creep and making one's own site look better (and more bloated) than the competitor's. The web devs have a skewed perception of how long it takes to load because most of them are using decent machines and accessing the server through 192.168.1.x
Re:Yahoo has a good page, too (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 [vlad1.com]. 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.
Opera Unite - resourcefetcher.js (Score:1, Interesting)
I was having a look over Opera Unite services when looking to write one of my own, and i noticed this handy little function.
It fetches all the external page objects after the initial page has loaded.
Sadly, the example (homepage) failed in the sense that the basic CSS was not always the first thing to be loaded, which resulted in buckled pages on tests for slow upload speeds. (and some things weren't obviously clickable objects before images were loaded in)
So, in this way, an initial page could be loaded that is, at a minimum, functional, then load in all the fancy-shmancy stuff if they have JavaScript enabled.
I would love to see more people take advantage of that since a good deal of the time, websites are sitting there loading loads of crap that end up going unnoticed anyway.
Always always always load the most important stuff first. But sadly, "most important" has gone from page content to stupid sponsor stuff, crappy flash ads, useless headers that take up an eighth of the screen, shiny flowing menus, etc. (some of these being the reason i want Flash to die a painful death since it is one of the major causes of slowdown, DEATH TO PLUGINS!)
off-topic
Also, i am loving the way Unite services are created so far.
JavaScript, HTML, CSS and XML, none of that PHP, or Python or anything else, just all native browser technology.
Re:What's that sound? (Score:3, Interesting)
As for using commas with echo, why aren't you using a template engine?
Some very slow sites: Slashdot and Facebook (Score:3, 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.
Why do XML closing tags contain the tag name? (Score:3, Interesting)
<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!
Re:Some very slow sites: Slashdot and Facebook (Score:3, Interesting)
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)