Posts Tagged ‘extension’

Chrome v. Firefox - The Container and The Desktop

September 4th, 2008 by smp | Comments | Filed in Browsers, Technology, The Web, Web Performance, Work

The last two days of using Chrome have had me thinking about the purpose of the Web browser in today’s world. I’ve talked about how Chrome and Firefox have changed how we see browsers, treating them as interactive windows into our daily life, rather than the uncontrolled end of an information firehose.

These applications, that on the surface seem to serve the same purpose, have taken very different paths to this point. Much has been made about Firefox growing out of the ashes of Netscape, while Chrome is the Web re-imagined.

It’s not just that.

Firefox, through the use of extensions and helper applications, has grown to become a Desktop replacement. Back when Windows for Workgroups was the primary end-user OS (and it wasn’t even an OS), Norton Desktop arrived to provide all of the tools that didn’t ship with the OS. It extended and improved on what was there, and made WFW a better place.

Firefox serves that purpose in the browser world. With its massive collections of extensions, it adds the ability to customize and modify the Web workspace. These extensions even allow the incoming content to be modified and reformatted in unique ways to suit the preferences of each individual. These features allowed the person using Firefox to feel in control, empowered.

You look at the Firefox installs of the tech elite, and no two installed versions will be configured in the same way. Firefox extends the browser into an aggregator of Web data and information customization.

But it does it at the Desktop.

Chrome is a simple container. There is (currently) no way to customize the look and feel, extend the capabilities, or modify the incoming or outgoing content. It is a simple shell designed to perform two key functions: search for content and interact with Web applications.

There are, of course, the hidden geeky functions that they have built into the app. But those don’t change what it’s core function is: request, receive, and render Web pages as quickly and efficiently as possible. Unlike Firefox’s approach, which places the app being the center of the Web, Chrome places the Web at the center of the Web.

There is no right or wrong approach. As with all things in this complicated world we are in, it depends. It depends on what you are trying to accomplish and how you want to get there.

The conflict that I see appearing over the next few months is not between IE and Firefox and Safari and Opera and Chrome. It is a conflict over what the people want from an application that they use all the time. Do they want a Web desktop or a Web container?

Tags: , , , , , , , , , , , , , , , , ,

Print v. Web: Which comes first?

March 19th, 2007 by smp | Comments | Filed in Blogging, Technology

Today, I want to talk about what happens when you aggressively adopt an online strategy, but leave your print subscribers behind.

I subscribe to a great architecture and design magazine, whose name I will exclude from this discussion, with a fantastic and informative online presence. The archive and articles available to subscribers are a fantastic resource for people just beginning to explore this field.

In February, I noticed that they had updated their site with the most recent issue’s content and cover. I was somewhat miffed, as my print copy had not yet arrived in the mail. Immediate assumption: print copy lost; request re-transmission.

Today, I checked the site, and all of the content for the March 2007 issue is online. And I don’t have my copy of this issue yet.

Based on the response to the e-mail that I sent to the circulation and publishing team, I may be the first person to bring this to their attention.

When you are in the dead-tree print industry, the Web (1.0 and 2.0) are crucial extensions to your existing business model. But the aggressive use of the Web channel to deliver your content to the rest of the world before the print subscribers receive their copies is doing damage to your business.

Subscribers pay extra in order to gain access to your magazine before the rest of the world can get it. This must extend to the Web channel. As a subscriber, knowing that someone can read the contents of the magazine online before I get my chance to look at the print copy is unsatisfactory.

Subscription content infers a level of exclusivity to those who buy the gold ticket. If you give everyone the gold ticket at the same time, then a subscription loses it sense of exclusivity. Then the magazine loses guaranteed revenue. Then the magazine is gone.

Information should be free. I chafe against the subscription gateways as much as the next person. But if you base your entire business on a subscription model, you better not undermine your own subscription business by giving the subscription content away for free.

Tags: , , , ,

Tags: , , , , , , , , , , , , , , , , , , , , , , , ,

Back to Performancing

December 7th, 2006 by smp | Comments | Filed in Blogging, Software

After a few months using the Microsoft Live Writer, I am giving the Performancing Blogging Extension for Firefox another try. Just seems more natural that since I use Firefox as my daily work platform, I should use it for everything.

Technorati Tags: , ,

Tags: , , , , , , , , , , , ,

Performance Improvement From Caching and Compression

October 3rd, 2006 by smp | Comments | Filed in Web Performance, WebPerformance.Org

This paper is an extension of the work done for another article that highlighted the performance benefits of retrieving uncompressed and compressed objects directly from the origin server. I wanted to add a proxy server into the stream and determine if proxy servers helped improve the performance of object downloads, and by how much.

Using the same series of objects in the original compression article[1], the CURL tests were re-run 3 times:

 

  1. Directly from the origin server
  2. Through the proxy server, to load the files into cache
  3. Through the proxy server, to avoid retrieving files from the origin.[2]

This series of three tests was repeated twice: once for the uncompressed files, and then for the compressed objects.[3]

As can be seen clearly in the plots below, compression caused web page download times to improve greatly, when the objects were retrieved from the source. However, the performance difference between compressed and uncompressed data all but disappears when retrieving objects from a proxy server on a corporate LAN.

uncompressed_pages

compressed_pages

Instead of the linear growth between object size and download time seen in both of the retrieval tests that used the origin server (Source and Proxy Load data), the Proxy Draw data clearly shows the benefits that accrue when a proxy server is added to a network to assist with serving HTTP traffic.

  MEAN DOWNLOAD TIME
Uncompressed Pages
Total Time Uncompressed — No Proxy 0.256
Total Time Uncompressed — Proxy Load 0.254
Total Time Uncompressed — Proxy Draw 0.110
Compressed Pages
Total Time Compressed — No Proxy 0.181
Total Time Compressed — Proxy Load 0.140
Total Time Compressed — Proxy Draw 0.104

The data above shows just how much of an improvement is gained by adding a local proxy server, explicit caching descriptions and compression can add to a Web site. For sites that do force a great of requests to be returned directly to the origin server, compression will be of great help in reducing bandwidth costs and improving performance. However, by allowing pages to be cached in local proxy servers, the difference between compressed and uncompressed pages vanishes.

Conclusion

Compression is a very good start when attempting to optimize performance. The addition of explicit caching messages in server responses which allow proxy servers to serve cached data to clients on remote local LANs can improve performance to even a greater extent than compression can. These two should be used together to improve the overall performance of Web sites.


[1]The test set was made up of the 1952 HTML files located in the top directory of the Linux Documentation Project HTML archive.

[2]All of the pages in these tests announced the following server response header indicating its cacheability:

Cache-Control: max-age=3600

[3]A note on the compressed files: all compression was performed dynamically by mod_gzip for Apache/1.3.27.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Enemy Alien Status: Uncertain

September 1st, 2006 by smp | Comments | Filed in Canada, Life, RANTING

I just remembered something this morning. Starting October 7, 2006, I will be officially a man without a Visa. My final H1-B renewal expires on October 6, 2006, and although they have applied for an extension, and I am at some indeterminate point supposed to get a Green Card, I will be of no status as of that date.

If you have any conferences or camps or seminars you want me to attend, better get me before October 6!

Technorati Tags: , , , , , , ,

Tags: , , , , , , , , , , , , ,

Performancing Extension: Trying something new

August 8th, 2006 by smp | Comments | Filed in Uncategorized

Since I started using the Performancing Firefox extension, it seems that Technorati takes a while to find me. FInally figured out that I haven’t enabled pings.

So this is a test post to see if the ping function works correctly.

Technorati Tags: , ,

Tags: , , , , ,

Hey CTO, I’d like some software, with open and extensible on the side

October 5th, 2005 by smp | Comments | Filed in smp

The CTO of the blogosphere asks: What kind of software would you like developed?

Option 1: Build a product in 12 months that is simple and easy to use but only meets basic requirements. Upon completiion, this company will only fix bugs and provide minimal updates every six months; training through FAQs and some simple documentation; and support through basic email, forums, but no phone contact. The cost to you to pay for the development and ongoing support of this product is low.

Option 2: Build a product in 24 months that meets all the requirements including features that you might want to use in the future but is complex to configure and use. Upon completion, this company will fix bugs and provide enhancements or new functionality through a elaborate support agreement that includes frequent updates every three months; extensive training through onsite, manual and online and support through 24/7 phone,email and web. However, the cost to you to pay for the development and ongoing support of this product is high.

Option 3: Build a product in 18 months that is simple, basic and easy but an open architecture is developed that will allow others such as end users or other developers to make it as complex as they would like it through the development of addons and extensions. Upon completion, this company will fix bugs or enhance existing functionality only and provide moderate updates, training and support through a combination on in-house and community resources. The cost to you to pay for the development and ongoing support of this product is a little more expensive than Option 1. In addition, you will be on your own regarding support and future development of any additional functionality that is provided by third parties.

Only an idiot or a dinosaur would build software under Options 1 and 2.

Tags: , , , , , , , , , , , , , , , , , ,

Performance Improvement From Caching and Compression

April 30th, 2005 by smp | Comments | Filed in smp

This paper is an extension of the work done for another article that highlighted the performance benefits of retrieving uncompressed and compressed objects directly from the origin server. I wanted to add a proxy server into the stream and determine if proxy servers helped improve the performance of object downloads, and by how much.

Using the same series of objects in the original compression article[1], the CURL tests were re-run 3 times:

  1. Directly from the origin server
  2. Through the proxy server, to load the files into cache
  3. Through the proxy server, to avoid retrieving files from the origin.[2]

eries of three tests was repeated twice: once for the uncompressed files, and then for the compressed objects.[3]

As can be seen clearly in the plots below, compression caused web page download times to improve greatly, when the objects were retrieved from the source. However, the performance difference between compressed and uncompressed data all but disappears when retrieving objects from a proxy server on a corporate LAN.


Instead of the linear growth between object size and download time seen in both of the retrieval tests that used the origin server (Source and Proxy Load data), the Proxy Draw data clearly shows the benefits that accrue when a proxy server is added to a network to assist with serving HTTP traffic.

Uncompressed Pages

MEAN DOWNLOAD TIME
Total Time Uncompressed — No Proxy 0.256
Total Time Uncompressed — Proxy Load 0.254
Total Time Uncompressed — Proxy Draw 0.110

Compressed Pages

Total Time Compressed — No Proxy 0.181
Total Time Compressed — Proxy Load 0.140
Total Time Compressed — Proxy Draw 0.104

The data above shows just how much of an improvement is gained by adding a local proxy server, explicit caching descriptions and compression can add to a Web site. For sites that do force a great of requests to be returned directly to the origin server, compression will be of great help in reducing bandwidth costs and improving performance. However, by allowing pages to be cached in local proxy servers, the difference between compressed and uncompressed pages vanishes.

Conclusion

Compression is a very good start when attempting to optimize performance. The addition of explicit caching messages in server responses which allow proxy servers to serve cached data to clients on remote local LANs can improve performance to even a greater extent than compression can. These two should be used together to improve the overall performance of Web sites.


[1] The test set was made up of the 1952 HTML files located in the top directory of the Linux Documentation Project HTML archive.

[2] All of the pages in these tests announced the following server response header indicating its cacheability: Cache-Control: max-age=3600

[3] A note on the compressed files: all compression was performed dynamically by mod_gzip for Apache/1.3.27.

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Compressing Web Output Using mod_gzip for Apache 1.3.x and 2.0.x

April 30th, 2005 by smp | Comments | Filed in smp

Web page compression is not a new technology, but it has just recently gained higher recognition in the minds of IT administrators and managers because of the rapid ROI it generates. Compression extensions exist for most of the major Web server platforms, but in this article I will focus on the Apache and mod_gzip solution.

The idea behind GZIP-encoding documents is very straightforward. Take a file that is to be transmitted to a Web client, and send a compressed version of the data, rather than the raw file as it exists on the filesystem. Depending on the size of the file, the compressed version can run anywhere from 50% to 20% of the original file size.

In Apache, this can be achieved using a couple of different methods. Content Negotiation, which requires that two separate sets of HTML files be generated — one for clients that can handle GZIP-encoding, and one for those who can’t — is one method. The problem with this solution should be readily apparent: there is no provision in this methodology for GZIP-encoding dynamically-generated pages.

The more graceful solution for administrators who want to add GZIP-encoding to Apache is the use of mod_gzip. I consider it one of the overlooked gems for designing a high-performance Web server. Using this module, configured file types — based on file extension or MIME type — will be compressed using GZIP-encoding after they have been processed by all of Apache’s other modules, and before they are sent to the client. The compressed data that is generated reduces the number of bytes transferred to the client, without any loss in the structure or content of the original, uncompressed document.

mod_gzip can be compiled into Apache as either a static or dynamic module; I have chosen to compile it as a dynamic module in my own server (more compile instructions here). The advantage of using mod_gzip is that this method requires that nothing be done on the client side to make it work. All current browsers — Mozilla, Opera, and even Internet Explorer — understand and can process GZIP-encoded text content.

On the server side, all the server or site administrator has to do is compile the module, edit the appropriate configuration directives that were added to the httpd.conf file, enable the module in the httpd.conf file, and restart the server. In less than 10 minutes, you can be serving static and dynamic content using GZIP-encoding without the need to maintain multiple codebases for clients that can or cannot accept GZIP-encoded documents.

When a request is received from a client, Apache determines if mod_gzip should be invoked by noting if the “Accept-Encoding: gzip” HTTP request header has been sent by the client. If the client sends the header, mod_gzip will automatically compress the output of all configured file types when sending them to the client.

This client header announces to Apache that the client will understand files that have been GZIP-encoded. mod_gzip then processes the outgoing content and includes the following server response headers.

		Content-Type: text/html
		Content-Encoding: gzip
		

These server response headers announce that the content returned from the server is GZIP-encoded, but that when the content is expanded by the client application, it should be treated as a standard HTML file. Not only is this successful for static HTML files, but this can be applied to pages that contain dynamic elements, such as those produced by Server-Side Includes (SSI), PHP, and other dynamic page generation methods. You can also use it to compress your Cascading Stylesheets (CSS) and plain text files. As well, a whole range of application file types can be compressed and sent to clients. My httpd.conf file sets the following configuration for the file types handled by mod_gzip:

		mod_gzip_item_include mime ^text/.*
		mod_gzip_item_include mime ^application/postscript$
		mod_gzip_item_include mime ^application/ms.*$
		mod_gzip_item_include mime ^application/vnd.*$
		mod_gzip_item_exclude mime ^application/x-javascript$
		mod_gzip_item_exclude mime ^image/.*$
		

This allows Microsoft Office and Postscript files to be GZIP-encoded, while not affecting PDF files. PDF files should not be GZIP-encoded, as they are already compressed in their native format, and compressing them leads to issues when attempting to display the files in Adobe Acrobat Reader.[1] For the paranoid system administrator, you may want to explicitly exclude PDF files.

		mod_gzip_item_exclude mime ^application/pdf$
		

Another side-note is that nothing needs to be done to allow the GZIP-encoding of OpenOffice (and presumably, StarOffice) documents. Their MIME-type is already set to text-plain, allowing them to be covered by one of the default rules.

How beneficial is sending GZIP-encoded content? In some simple tests I ran on my Web server using WGET, GZIP-encoded documents showed that even on a small Web server, there is the potential to produce a substantial savings in bandwidth usage.

http://www.pierzchala.com/bio.html Uncompressed File Size: 3122 bytes
http://www.pierzchala.com/bio.html Compressed File Size: 1578 bytes
http://www.pierzchala.com/compress/homepage2.html Uncompressed File Size: 56279 bytes
http://www.pierzchala.com/compress/homepage2.html Compressed File Size: 16286 bytes

Server administrators may be concerned that mod_gzip will place a heavy burden on their systems as files are compressed on the fly. I argue against that, pointing out that this does not seem to concern the administrators of Slashdot, one of the busiest Web servers on the Internet, who use mod_gzip in their very high-traffic environment.

The mod_gzip project page for Apache 1.3.x is located at SourceForge. The Apache 2.0.x version is available from here.


[1] From http://www.15seconds.com/issue/020314.htm

Tags: , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , , ,

Netcraft Anti-Phishing Tolbar

December 27th, 2004 by smp | Comments | Filed in smp

The folks at Netcraft have released an anti-phishing toolbar. So far it is only for MSIE; hopefully they will release a Firefox extension soon.

Tags: , , , , , , , ,