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].'"
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):
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.
Comment removed based on user account deletion
We've got to slashdot their site for ultimate irony! :)
The skinnier ones compress much easier.
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
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.
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.
Comment removed based on user account deletion
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.
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.)
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?
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.
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
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.
2bits.com, Inc: Drupal, WordPress, and LAMP performance tuning.
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!!)
:D
<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!