Slashdot Mirror
Even Faster Web Sites
Michael J. Ross writes "Slow Web page loading can discourage visitors to a site more than any other problem, regardless of how attractive or feature-rich the given site might be. Consequently, many Web developers hope to achieve faster response times using AJAX (Asynchronous JavaScript and XML), since only portion(s) of an AJAX page need to be reloaded. But for many rich Internet applications (RIAs), such potential performance gains can be lost as a result of non-optimized JavaScript, graphics, and CSS files. Steve Souders — a Web performance expert previously at Yahoo and now with Google — addresses these topics in his second book, Even Faster Web Sites: Performance Best Practices for Web Developers." Read on for the rest of Michael's review.
Even Faster Web Sites
author
Steve Souders
pages
254 pages
publisher
O'Reilly Media
rating
8/10
reviewer
Michael J. Ross
ISBN
978-0596522308
summary
Advanced techniques for improving website performance.
The book was published by O'Reilly Media on 18 June 2009, under the ISBN 978-0596522308. The publisher makes available a Web page, where visitors can purchase the print and electronic versions of the book (as well as a bundle of the two), read the book online as part of the Safari library service, and check the reported errata — comprising those confirmed by the author (of which there are currently two) and any unconfirmed errors (all six of which are valid, though the fifth one may be a coincidence). In a break with traditional practice among technical publishers nowadays, there is no sample chapter available, as of this writing.
In many ways, this second book is similar to Steve's previous one, High Performance Web Sites: It presents methods of enhancing the performance of websites, with a focus on client-side factors. It is fairly slender (this one is 254 pages), relative to most programming books nowadays, and the material is organized into 14 chapters. However, unlike its predecessor, Even Faster Web Sites emphasizes generally more advanced topics, such as script splitting, coupling, blocking, and chunking (which to non-developers may sound like a list of the more nefarious techniques in professional hockey). This second book also has employed a team approach to authorship, such that six of the chapters are written by contributing authors. In his preface, Steve notes that the 14 chapters are grouped into three broad areas: JavaScript performance (Chapters 1-7), network performance (Chapters 8-12), and browser performance (Chapters 13-14). The book concludes with an appendix in which he presents his favorite tools for performance analysis, organized into four types of applications: packet sniffers, Web development tools, performance analyzers, and some miscellaneous applications.
In the first chapter, "Understanding Ajax Performance," guest author Douglas Crockford briefly describe some of the key trade-offs and principles of optimizing applications, and how JavaScript now plays a pivotal role in that equation — as websites nowadays are designed to operate increasingly like desktop programs. On pages 2 and 3, he uses some figures to illustrate fixed versus variable overhead, and the dangers of attempting to optimize the wrong portions of one's code. By the way, the so-called "axes" are not axes, or even Cartesian grid lines, but simply levels. Aside from its choppy narrative style and a pointless religious reference in the first paragraph, the material serves as a thought-provoking springboard for what follows. Chapter 2, titled "Creating Responsive Web Applications," was written by Ben Galbraith and Dion Almaer, who discuss response times, user perception of them, techniques for measuring latency, browser threads, Web Workers, Google Gears, timers, and memory issues. The material is neatly explained, although Figure 2-2 is quite confusing; moreover, both of the figures on that page should not have been made Mac- and Firefox-specific.
In the subsequent four chapters, Steve dives into the critical topic of how to optimize the performance of JavaScript-heavy pages through better script content and organization — specifically, how and when to split up large scripts into smaller ones, how to load scripts without blocking one another or breaking dependencies within the code, and how to best in-line scripts, when called for. Each of the four chapters follows an effective methodology: The first author delineates a particular performance mistake made by even some of the most popular websites, with the statistics to back it up. He presents one or more solutions, including any relevant tools, again with waterfall charts illustrating how well the solutions work. Lastly, he explains any browser-specific issues, oftentimes with a handy chart showing which possible method would likely be optimal for the reader's given situation, such as expected browser choices in the site's target audience. When there are potential pitfalls, Steve points them out, with helpful workarounds. He generally provides enough example source code to allow any experienced developer to implement the proposed solutions. Unfortunately, the example code does not appear to be available for download from O'Reilly's website.
The discussion of JavaScript optimization is capped off by the seventh chapter, written by Nicholas C. Zakas, who explains variable scope within JavaScript code, the advantages of choosing local variables as much as possible, scope chain augmentation, the performance ramifications of the four major data types (literal values, variables, arrays, and objects), optimizing flow control statements, and string concatenation. He outlines what sorts of problems can cause the user's Web browser to freeze up, and the differing responses she would see depending upon her chosen browser. Nicholas concludes his chapter by explaining how to utilize timer code to force long-running scripts to yield, in order to avoid these problems. By the way, in Figures 7-2 and 7-3, the data point symbols need to be enlarged so as to be distinguishable; as it is, they are quite difficult to read. More importantly, on page 93, the sentence beginning "This makes array lookup ideal..." is either misworded or mistaken, since array lookup cannot be used for testing inclusion in ranges.
With the eighth chapter, the book shifts gears to focus on network considerations — namely, how to improve the site visitor's experience by optimizing the number of bytes that must be pushed down the wire. In "Scaling with Comet," Dylan Schiemann introduces an emerging set of techniques that Steve Souders describes as "an architecture that goes beyond Ajax to provide high-volume, low-latency communication for real-time applications such as chat and document collaboration" — specifically, by reducing the server-side resources per connection. In Chapter 9, Tony Gentilcore discusses a rather involved problem with using gzip compression — one that negatively impacts at least 15% of Internet users. Even though videos, podcasts, and other audiovisual files consume a lot of the Internet's bandwidth, images are still far more common on websites, and this alone is reason enough for Chapter 10, in which Stoyan Stefanov and Nicole Sullivan explain how to reduce the size of image files without degrading visible quality. They compare the most popular image formats, and also explain alpha transparency and the use of sprites. The only clear improvement that could be made to their presentation is on page 157, where the phrase "named /favicon.ico that sits in the web root" should instead read something like "usually named favicon.ico," since a favicon can have any filename, and can be located anywhere in a site's directory structure.
The lead author returns in Chapter 11, in which he explains how to best divide resources among multiple domains (termed "sharding"). In the subsequent chapter, "Flushing the Document Early," Steve explores the approach of utilizing chunked encoding in order to begin rendering the Web page before its full contents have been downloaded to the browser. The third and final section of the book, devoted to Web browser performance, consists of two chapters, both of whose titles neatly summarize their contents: "Using Iframes Sparingly" and "Simplifying CSS Selectors." That last chapter contains some performance tips that even some of the most experienced CSS wizards may have never heard of before. As with most of the earlier chapters, the narrative tends to be stronger than the illustrations. For instance, Figure 14-5, a multiline chart, is quite misleading, because it appears to depict three values varying over time, when actually each of the ten x-axis coordinates represents a separate major website. A bar chart would obviously have been a much better choice.
Like any first edition of a technical book, this one contains a number of errata (aside from those mentioned earlier): In Figure 1-1, "iteration" is misspelled. On page 23, in the sentence beginning "Thus, if...," the term "was" should instead read "were." In Figures 7-1 and 7-4, the "Global object" box should not contain "num2." On page 95, in the phrase "the terminal condition evaluates to true," that instead should read "false." On page 147, in the sentence beginning "However, the same icon...," the "was" should instead read "were." On page 214, "Web-Pagetest. AOL" should instead read "Web-Pagetest, then AOL," because the first sentence is one long absolute phrase (i.e., lacking a finite noun and verb).
All of these defects can be easily corrected in future printings. What will probably need to wait for a second edition, are improvements to the figures that are in need of replacement or clarification. What the publisher can rectify immediately — should the author and O'Reilly choose to do so — would be to make all of the example source code available for download.
Even though this book is decidedly longer than High Performance Web Sites, and has many more contributing authors, it does not appear to contain as much actionable information as his predecessor — at least for small- to medium-sized websites, which probably make up the majority of all sites on the Web. Even though such methodologies as Comet, Doloto, and Web Workers appear impressive, one has to wonder just how many real-world websites can justify the development and maintenance costs of implementing them, and whether their overhead could easily outweigh any possible benefits. Naturally, these are the sorts of questions that are best answered through equally hard-nosed experimentation — as exemplified by Steve Souders's admirable emphasis upon proving what techniques really work.
Fortunately, none of this detracts from the application development and optimization knowledge presented in the book. With its no-nonsense analysis of Internet performance hurdles, and balanced recommendations of the most promising solutions, Even Faster Web Sites truly delivers on its title's promise to help Web developers wring even more speed out of their websites.
Michael J. Ross is a freelance Web developer and writer.
You can purchase Even Faster Web Sites from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.
In many ways, this second book is similar to Steve's previous one, High Performance Web Sites: It presents methods of enhancing the performance of websites, with a focus on client-side factors. It is fairly slender (this one is 254 pages), relative to most programming books nowadays, and the material is organized into 14 chapters. However, unlike its predecessor, Even Faster Web Sites emphasizes generally more advanced topics, such as script splitting, coupling, blocking, and chunking (which to non-developers may sound like a list of the more nefarious techniques in professional hockey). This second book also has employed a team approach to authorship, such that six of the chapters are written by contributing authors. In his preface, Steve notes that the 14 chapters are grouped into three broad areas: JavaScript performance (Chapters 1-7), network performance (Chapters 8-12), and browser performance (Chapters 13-14). The book concludes with an appendix in which he presents his favorite tools for performance analysis, organized into four types of applications: packet sniffers, Web development tools, performance analyzers, and some miscellaneous applications.
In the first chapter, "Understanding Ajax Performance," guest author Douglas Crockford briefly describe some of the key trade-offs and principles of optimizing applications, and how JavaScript now plays a pivotal role in that equation — as websites nowadays are designed to operate increasingly like desktop programs. On pages 2 and 3, he uses some figures to illustrate fixed versus variable overhead, and the dangers of attempting to optimize the wrong portions of one's code. By the way, the so-called "axes" are not axes, or even Cartesian grid lines, but simply levels. Aside from its choppy narrative style and a pointless religious reference in the first paragraph, the material serves as a thought-provoking springboard for what follows. Chapter 2, titled "Creating Responsive Web Applications," was written by Ben Galbraith and Dion Almaer, who discuss response times, user perception of them, techniques for measuring latency, browser threads, Web Workers, Google Gears, timers, and memory issues. The material is neatly explained, although Figure 2-2 is quite confusing; moreover, both of the figures on that page should not have been made Mac- and Firefox-specific.
In the subsequent four chapters, Steve dives into the critical topic of how to optimize the performance of JavaScript-heavy pages through better script content and organization — specifically, how and when to split up large scripts into smaller ones, how to load scripts without blocking one another or breaking dependencies within the code, and how to best in-line scripts, when called for. Each of the four chapters follows an effective methodology: The first author delineates a particular performance mistake made by even some of the most popular websites, with the statistics to back it up. He presents one or more solutions, including any relevant tools, again with waterfall charts illustrating how well the solutions work. Lastly, he explains any browser-specific issues, oftentimes with a handy chart showing which possible method would likely be optimal for the reader's given situation, such as expected browser choices in the site's target audience. When there are potential pitfalls, Steve points them out, with helpful workarounds. He generally provides enough example source code to allow any experienced developer to implement the proposed solutions. Unfortunately, the example code does not appear to be available for download from O'Reilly's website.
The discussion of JavaScript optimization is capped off by the seventh chapter, written by Nicholas C. Zakas, who explains variable scope within JavaScript code, the advantages of choosing local variables as much as possible, scope chain augmentation, the performance ramifications of the four major data types (literal values, variables, arrays, and objects), optimizing flow control statements, and string concatenation. He outlines what sorts of problems can cause the user's Web browser to freeze up, and the differing responses she would see depending upon her chosen browser. Nicholas concludes his chapter by explaining how to utilize timer code to force long-running scripts to yield, in order to avoid these problems. By the way, in Figures 7-2 and 7-3, the data point symbols need to be enlarged so as to be distinguishable; as it is, they are quite difficult to read. More importantly, on page 93, the sentence beginning "This makes array lookup ideal..." is either misworded or mistaken, since array lookup cannot be used for testing inclusion in ranges.
With the eighth chapter, the book shifts gears to focus on network considerations — namely, how to improve the site visitor's experience by optimizing the number of bytes that must be pushed down the wire. In "Scaling with Comet," Dylan Schiemann introduces an emerging set of techniques that Steve Souders describes as "an architecture that goes beyond Ajax to provide high-volume, low-latency communication for real-time applications such as chat and document collaboration" — specifically, by reducing the server-side resources per connection. In Chapter 9, Tony Gentilcore discusses a rather involved problem with using gzip compression — one that negatively impacts at least 15% of Internet users. Even though videos, podcasts, and other audiovisual files consume a lot of the Internet's bandwidth, images are still far more common on websites, and this alone is reason enough for Chapter 10, in which Stoyan Stefanov and Nicole Sullivan explain how to reduce the size of image files without degrading visible quality. They compare the most popular image formats, and also explain alpha transparency and the use of sprites. The only clear improvement that could be made to their presentation is on page 157, where the phrase "named /favicon.ico that sits in the web root" should instead read something like "usually named favicon.ico," since a favicon can have any filename, and can be located anywhere in a site's directory structure.
The lead author returns in Chapter 11, in which he explains how to best divide resources among multiple domains (termed "sharding"). In the subsequent chapter, "Flushing the Document Early," Steve explores the approach of utilizing chunked encoding in order to begin rendering the Web page before its full contents have been downloaded to the browser. The third and final section of the book, devoted to Web browser performance, consists of two chapters, both of whose titles neatly summarize their contents: "Using Iframes Sparingly" and "Simplifying CSS Selectors." That last chapter contains some performance tips that even some of the most experienced CSS wizards may have never heard of before. As with most of the earlier chapters, the narrative tends to be stronger than the illustrations. For instance, Figure 14-5, a multiline chart, is quite misleading, because it appears to depict three values varying over time, when actually each of the ten x-axis coordinates represents a separate major website. A bar chart would obviously have been a much better choice.
Like any first edition of a technical book, this one contains a number of errata (aside from those mentioned earlier): In Figure 1-1, "iteration" is misspelled. On page 23, in the sentence beginning "Thus, if...," the term "was" should instead read "were." In Figures 7-1 and 7-4, the "Global object" box should not contain "num2." On page 95, in the phrase "the terminal condition evaluates to true," that instead should read "false." On page 147, in the sentence beginning "However, the same icon...," the "was" should instead read "were." On page 214, "Web-Pagetest. AOL" should instead read "Web-Pagetest, then AOL," because the first sentence is one long absolute phrase (i.e., lacking a finite noun and verb).
All of these defects can be easily corrected in future printings. What will probably need to wait for a second edition, are improvements to the figures that are in need of replacement or clarification. What the publisher can rectify immediately — should the author and O'Reilly choose to do so — would be to make all of the example source code available for download.
Even though this book is decidedly longer than High Performance Web Sites, and has many more contributing authors, it does not appear to contain as much actionable information as his predecessor — at least for small- to medium-sized websites, which probably make up the majority of all sites on the Web. Even though such methodologies as Comet, Doloto, and Web Workers appear impressive, one has to wonder just how many real-world websites can justify the development and maintenance costs of implementing them, and whether their overhead could easily outweigh any possible benefits. Naturally, these are the sorts of questions that are best answered through equally hard-nosed experimentation — as exemplified by Steve Souders's admirable emphasis upon proving what techniques really work.
Fortunately, none of this detracts from the application development and optimization knowledge presented in the book. With its no-nonsense analysis of Internet performance hurdles, and balanced recommendations of the most promising solutions, Even Faster Web Sites truly delivers on its title's promise to help Web developers wring even more speed out of their websites.
Michael J. Ross is a freelance Web developer and writer.
You can purchase Even Faster Web Sites from amazon.com. Slashdot welcomes readers' book reviews — to see your own review here, read the book review guidelines, then visit the submission page.
Slashdot is the SLOWEST web site on the net.
The greatest barrier to website use is information overload, kinda like this review.
TLDR
WALL OF TEXT CRITS YOU FOR +5 TROLL
Has anybody else noticed that of all the websites visited, some of the SLOWEST make heavy use of AJAX? Or is that just me?
If I had a nickel for every time I had a nickel, I'd be richcursive!
You fixed most of your bugs.
I think you might be ready to move from Beta to Release Candidate.
See slashdot, slow loading pages == bad.
I hope this book helps you.
I used to go to VGChartz all the time until a few months ago they "updated" their site with seeming dozens of constant flash ads, talking, moving, popping up on the forums, ect. It got to the point where my Core2Duo desktop was litterally pausing for 5 seconds everytime I navigated to a new page. Pretty quickly I realized that the content on the site wasn't worth my time. I see this happening more and more. Sure I could have used adblock but frankly they were asking for a price (getting attacked by ads) and I chose not to pay it (leaving the site). I was glad to see a few ads, but abuse is a sure sign you have little respect for your readers.
...when your site is slow is to fire up YSlow and see what it says. Sometimes all you have to do is enable mod_expires in Apache to get a huge performance increase and a much lighter server load.
If YSlow doesn't flag anything, then you've got to start digging. But at least you've eliminated some of the easy fixes.
The Army reading list
Were I to be developing a new AJAX-driven Web application I would focus first on simplicity. I feel that if you have so much AJAX stuff going on that you need to resort to crazy tricks you have already lost. Take the following, quoted from the review:
In the subsequent chapter, "Flushing the Document Early," Steve explores the approach of utilizing chunked encoding in order to begin rendering the Web page before its full contents have been downloaded to the browser.
While good advice, something like this should be implemented as a natural part of the specification, or not at all. This rings to me as an attempt to manhandle HTML/Javascript/CSS into a use case for which it is not intended.
I want to see a real protocol for webpages - something between Postscript (except less document-oriented; and yes I know about NeXT's work) and a windowing environment (except more constrained). Then, to preserve the ease of user-input, a simple HTML/XML-like layer. For 99% of the sites that are constructed directly by the user, original HTML with italics, colors, fonts, etc. is sufficient. For projects beyond the scope of Joe Facebook, a true system is needed that allows seperation of design and content. But all attempts thus far to do both, frankly, suck.
The only part that bothers me is the "Preview Post" lag lasting for 20-35 seconds. I love everything else about the navigation on the site, though.
Slow Web page loading can discourage visitors to a site more than any other problem, regardless of how attractive or feature-rich the given site might be
Attractive and feature-rich are not adjectives that are appropriate to apply to slashdot it its current form. Hence I don't think this book is the cure to what ails them.
Damn_registrars has no butt-hole. Damn_registrars has no use for a butt-hole.
how about people quit using flash and other technologies that cause the page to take forever to load and go back to plain html and images with a little css thrown in
Most websites don't need to be ridiculously complicated to be effective. Go ahead and call me a luddite, but does everyone need comments on their website? Fancy sliding menus? Pop-up image galleries? Flash or other web programming up the wazoo?
When did simple, efficient web design that presents content well and doesn't get in the way of it get tossed out the window?
mmmm...forbidden donut
I read this guy's other book, "Clearer thought using vodka". Great read. Can't remember much of it.
The fastest websites I see generally use plain-jane HTML and pre-sized graphics (via size attributes on IMG tag). AJAX, CSS, and too much JavaScript seem to cause confusing UI behavior, unexpected pausing while something fancy is doing GC, or jerky scroll motion that can be perceived as sluggishness, especially on older hardware.
Table-ized A.I.
I'm on a slower computer at work - as such I have plenty of time to watch the status bar in the browser. I would claim that the best way to speed up a site is to reduce or remove the "fancy" (read that as "annoying as hell") ads.
Approximately 80% of my loading time is spent waiting for Google's server to respond with ads, Yahoo's, and whoever else does those terrible javascript/flash ads. Yes yes, I could use adblock, but sadly my browser cannot install addons.
I know people already mentioned VGCharts, but another site that is very terrible is TomsHardware. I used to be an avid reader, but now it takes me almost a minute to load the entire page - I haven't been back in months.
I've seen a lot of good sites "re-designed" into oblivion. I think it's mostly a social problem.
1. The "we're artistes" mentality. Unless your site is explicitly an art site (which it usually isn't), people will just want information from your site. You could do most of that with static HTML and a few simple images.
2. The "we're losing eyeballs, we need to do something" problem. The site design is an easy target; but it may not be your site design. Maybe your content is just boring. Competition moved in. You were participating in a fad. The honeymoon is over. The public tastes change. You can't control those things, but you can control your site design so that's what you do. It's like pushing the walk button at an intersection when somebody else has already pushed it.
3. Now, this is the one I really hate to say; but here goes... "You can't figure out how to let people go". The project is done. You need a few maintenance coders, the most experienced people. OK, maybe there's some justification for keeping staff around for new projects; but I bet often there isn't. If you're directly involved with the developers, you don't want to do this. The risk is that you'll spark brain-drain and cause the people you really need to leave. It's far less risky for you to keep everybody, even the grunts. Better yet, you can go up to the next level of management and tell them that site redesign is needed. That makes you the hero instead of the villain. The next level up from you is probably not going to figure out that you are just trying to keep your department busy. Perhaps this problem could be solved by making it clear right from the start that there will be a permanent staff and some contract workers. Instead, I bet there are a lot of companies where the web developers figured out how to justify their existance--to the detrement of the site, and the company.
4. Cool new technology. 'nuff said.
5. People just aren't that bright. They dynamicly generate javascript via a scripting language with a framework on top of it. Just to put "Hello World" on a page. Look at me! I'm a web developer.
I suspect he overshot his 20% time while writing this, so the guys at Google decided to screw him over by posting this:
Let's make the web faster
I mean, how can you overlook something as glaring as a missing space? "Anonymous Cowardon" indeed!
What I miss most is some kind of feedback corner - ok, sometimes the admins invite comments on new stuff, but those threads vanish too rapidly from the front page. Why not include a simple new slashbox named "Feedback" where people could notify the editors and administrators of things that bug them? This might also be an easy way to improve the site by pointing out common problems (spelling errors in submissions could be caught faster and more reliably than by posting in the respective threads, where notices would be modded as "off-topic" or even "troll" when the error was corrected, for instance).
-- Language is a virus from outer space.
Google Mail is, hands down, *the* slowest webapp that I deal with. I'm not talking about the copout "basic HTML" option. I run any number of browsers (FF, Opera, Safari), and *all* take tens of seconds to load and interact with Google Mail. I dream about sharp needles in the eye as I wait for Google Mail to do its...magic.
So the author of this book is a "web performance expert" who is now employed by Google. Instead of writing books, maybe said author should figure out what's wrong with the Google Mail interface?
This page takes six seconds to load. "data.coremetrics.com" is slow today. "c.fsdn" is slow, too. "doubleclick.com" only wasted about a second.
Maybe someone at Slashdot should read the book.
The average webmaster doesn't need this book; they need tools like Page Speed that highlight very simple issues that webmasters can fix, usually without any code changes. And they need clear instructions on how to do it, and why it will benefit their users. I recently ran a project to cut the fluff on large furry websites. Most failed to even gzip their HTML, CSS or JS, or were resizing images into thumbnails. It's not hard, people just don't think to do it, or don't know how.
> dark background, with large-font bright text. It's the easiest webpage on the internet to read, and despite having some graphics, it loads very quickly because he uses the graphics as actual content, not just filler.
Example: http://www.riverofinnocents.com/wp/
Someone advocating more efficient coding of websites should surely take less than 12 paragraphs to do so!
War as we knew it was obsolete
Nothing could beat complete denial
- Emily Haines
In my experience (having 20/5 Mbit fibre to the house) is that it's almost never the website's local content that loads slow, it's the damned ads. Let me say that again so that we're clear -- I'm sitting there waiting not for the content I was seeking to load, but for the ads that I don't want to load. I know there's work-arounds for this -- I use some of them and they do help. But Fred and Ethyl Nongeek is not going to know about ad suppression. To them the 'net is "just slow" and they don't know why.
Making your local content lightning fast isn't going to help if your customers are waiting for unwanted content from some other website. And (grrrr....) this includes CAPTCHA! Sometimes it takes almost a half minute for the captcha image to come up, long after the rest of the login page has loaded.
The worst example, and a sign of things to come, was when Google Ads went down awhile back and took a bunch of websites down with it, including (as I remember) Slashdot. If your page included google ads, it just wouldn't load. I don't think AJAX is going to help with that. Feel free to disagree, but be specific.
Oliver's law of assumed responsibility: If you're seen fixing it, you will be blamed for breaking it.
... are slow mostly due to advertising. That being said, slow websites can also be due to: - Limited bandwidth where the site is hosted - Slow disk subsystem - Bandwidth throttling due to a large number of users
TOP DSLR Cameras Reviews of the top DSLRs
My personal website has been dying a slow death, not because of the fancy graphics I use on it but because I'm stuck on shared hosting with 100+ other websites (1and1). That alone can make the difference. To download 100K to 300K isn't a big deal now days.
Also, for instance try tallying up all of Facebook's JS, CS + HTML files, and you'll discover the site clocks in over 1MB. Now consider how fast the pages on the site load (super fast) See the difference how your site is hosted can make?
"During My Service In The United States Congress, I Took The Initiative In Creating The Internet." -Al Gore
Sure, you can have a database table that maps images to URLs, so that the code that IS accessing the database to build the page can find what URL to embed, and you can change which image to use by altering the database table, but the ACTUAL IMAGE FETCH should be nothing more than pulling a file from the web server's file system. Nice, simple, and it allows the web server to correctly handle IF-MODIFIED-SINCE and Expires.
What is a file system, other than a database that maps paths to blobs?
I do not believe in so called "web applications". If you need an application, just right a classical application that connects to remote servers.
Assuming "right" means "write": Your audience includes people who use a computer that they do not own and people who use lockout-chipped platforms such as Wii and iPhone. These people generally do not have the privilege to install such "a classical application".
We do not lack portable tool today. python is present on most (all?) operating systems.
Python does not come with Microsoft Windows, and non-administrators are not permitted to install a Python interpreter.
You can still even use java or .net
A Java program that does not require installation is called an applet, and web apps prior to widespread use of AJAX were often written as Java applets.
This is one of the big reasons you shouldn't use tables for layout. Since most tables are set to use auto layout, the browser has to wait for the table content before it can start rendering.
But what's the widely compatible alternative? Some document layouts fit better into a grid model than a flow model. CSS supports grid layout (display: table, table-row, and table-cell), but the subset of CSS implemented in widely deployed versions of Windows Internet Explorer doesn't.
Be glad if you do not support Oracle products. They have been pushing a "new, improved" support site to replace their "classic" MetaLink, which has been fairly straightforward HTML based from what I can tell. The new support site, cutely named "My Oracle Support" (MOS - trying to make it sound "personal" I guess), is PURE Flash-based, not just the occasional Flash pop-up or frame on the side of a page - the whole flaming site is one big, crawling Flash pop-up! .wgetrc lying around (anyone using the box gets root access, and we have to give our corp SSO password for the proxy access). ... ... NOT.
--
The complaints on the various Oracle fora have been quite explicit about all the negatives of that "design" choice starting with Oracle admins working for organizations that do not permit the installation of Flash on PC's for hyper-paranoid security, on down to the more prosaic issues of the bandwidth and CPU hits for someone working remotely on a major database problem trying to search the support knowledgebase, or open a Service Request (SR, formerly known as a TAR).
--
But Oracle's shills... err spokes-persons keep spouting a party line about how this enhances the support experience and is the result of "listening to our customers", and lay on the bafflegab about how their new SOA security model cannot work with the old HTML-based site, yada-yada ad nauseum.
--
It will be very interesting to see what happens with Oracle online support when Classic MetaLink is shut off at the end of July as has been announced. Some protesters threaten to make all their support requests over the phone, which Oracle likely is not geared up for. I can make do with the MOS POS, but am not liking the memory and CPU hits on my work PC when I get a session going.
--
To prepare, I have invested time and effort in making sure I can download the multi-megabyte patchsets and other big updates (how about a 1.8 GIGA-byte upgrade "pathchset" I got a while ago?) via the Linux command line directly on an internal RHEL staging server we use specifically to obtain vendor patches and other files to distribute internally. Oracle made some lame claim that there is a BETA (not supported mind you), Flash 10 plug-in (they require a minimum of Flash 9.something for MOS) for the Firefox that comes with RHEL 4.x 64-bit that we use on the staging server. Only problem is that it requires a newer version of glibc to run, and getting changes like that done on a corp server is difficult to say the least - all that regression testing, bureaucratic support rigamarole, etc. Never mind, I got wget working once I got the corp proxy setup info, and how to extract the multi-100 character download URL from the Oracle download page, etc. Put it all into a nice little script that prompts for all the info, and makes sure not to leave any security openings like the
--
When I am working from home, as I do a lot, I am not about to tie up my bandwidth (typical ISP restriction of 384 Kbps upload speed vs the 7 or 8 Mbps download speed, so, yeah, I can download the mulit-MB files fast enough, but then the upload kills the rest of my online work comms via the VPN for email, instant messaging, terminal sessions, etc). A lot of tech support people share that scenario, but how many would put up with depending on such a pig of a website for critical support? I wonder if Solaris admins face that in the future as that gets integrated into Oracle's "Collective", and how they will react to it
--
This so much fun
__
RO
http://www.youtube.com/watch?v=mHtdZgou0qU
NB: The message above might reflect my opinion right now, but not necessarily tomorrow or next year.
Is there a particular reason why the typos in the book are the most commonly commented upon feature of the review? With the exception of the names of the authors and some general bitching about a few of the figures that the reviewer didn't like, I have no idea if this book is something I want to look at or not. Is it too much to ask to have reviews that actually discuss the point of the book as opposed to the things that the editorial staff missed?
Well, it's almost Thursday. Time to put away that child-like innocence for another week and get back to thinking that the world could really use a good plague about now.
http://slashdot.org/index.pl?simpledesign=1&lowbandwidth=1
Slashdot = Sarcasm
Due to the issues of concurrency and locking
File systems have synchronization bottlenecks too: not just within your application and among applications that access your database but among all applications on a system.
the SQL check is frequently more expensive, especially when you have to do an out-of-process operation (passing the message from the web server over to the database program) vs. an in-process file system lookup.
In a user-space file system, a file system lookup isn't necessarily in-process.
Add to that the cost of moving a large amount of data (the blob itself) from the database process to the web server process to the kernel TCP stack vs. being able to do a simple send_file() operation on the inode from the web server process
In other words: "The file system is faster because it supports send_file()." That's a good point.
rather than using a very cheap sort of database (a file system) they use an expensive data base, for no real advantage
In some case, the expensive database's advantage is that it efficiently stores blobs smaller than 2 KB, while file systems without the uncommon "tail packing" feature use fixed-length records called "clusters".
We can continue the discussion in my journal now.