Let’s say you have a web performance problem and you hate it. You should probably take time to consider what you’re about to do, but you pick up the nearest blunt instrument, and . . . . What are those blunt instruments that kill performance problems, at least some of the time? Here are a few you can try right off without investing much brainpower or patience, though you may have to invest money. Some are not very elegant and might not help. But then again, they might.
Turning off autoloading of images will help performance dramatically if the problem is simply that your bandwidth is limited to that of a modem on a regular dial-up telephone line (also known as a POTS line, for Plain Old Telephone Service). Of course, without graphics you won’t enjoy a lot of what the Web is about, which is, well, graphics. In Netscape 4.0, you turn off automatic loading by choosing Edit → Preferences... → Advanced and then unchecking the “Automatically Load Images...” box.
Even if you turn off automatic loading of images, you can load and view an interesting image by clicking on the associated image icon. Your next question should be how to tell whether an image looks interesting before you’ve seen it. This is exactly what the HTML <ALT> tag is for: the HTML author is supposed to add a text description of the associated image, which the browser will display if image loading is off. ALT stands for “alternate text.” Here is an example:
<img src="images/foo.gif" alt="Picture of a Foo" width=190 height=24>
Most browsers also have a button which forces all unloaded images to load at once.
Many sites offer a light-graphics or text-only link for the bandwidth-impaired user. Another option is to use a text-only browser such as Lynx, which also has the advantage that it can be run remotely over a VT100 or other terminal-mode connection rather than requiring a TCP/IP connection all the way to the client. That is, your ISP may let you dial up and run Lynx on the ISP’s computer rather than on your computer at home.
It is frequently helpful to set the browser to start on a blank page, so that the user does not have to wait for a default page to load when starting up. The Netscape page can be particularly heavy with graphics and features, so it’s a poor choice to leave as the default. To change the startup page to blank in Netscape, choose Edit → Preferences... → Navigator and then click the radio button for “Navigator starts with blank page”.
When loading a web page, sometimes you first see an image loading at the top of the screen, followed by a long delay before the text of the page appears. More often than not, this image is an animated GIF advertising something you don’t want. This usually happens because the page designer didn’t include the image size in the HTML. The browser doesn’t know how much space to set aside for the image until the image is completely loaded, so it delays laying out the page until it has the entire image.
If you notice this happening, you have a couple of options to stop it. First, try hitting Netscape’s Stop button. This forces Netscape to stop loading, to show the rest of the page, and to stop any animated GIFs. Remember that the HTML text of a page is necessarily downloaded before any images. If you think about it, this must be so, because the HTML contains the link to the image, not the other way around. You might think that the text should therefore be visible before any images, but it doesn’t always work that way. The browser needs to know the size of the images before it can lay out the HTML text correctly, but when you hit Stop, Netscape will go ahead and do the best it can to display the HTML because it’s not getting any more image data.
Another way you can avoid the ugly-ad-image syndrome is to turn off automatic loading of images, as described above. Remember that you can always hit the Show Images option to get the images if you want them.
Finally, you can switch to another browser. It seems that Internet Explorer does not delay HTML rendering until images are loaded, unlike Netscape 4.x. The text-based browser Lynx, of course, never waits for images, because it can’t display them.
On the other hand, if you’re a content designer and you want to
inflict this suffering on your viewers because it pleases your
sponsors, there are a couple of ways you can make viewers watch the
commercial before starting the show. First, you can simply leave the
image size out of the HTML <IMG> tag, as described earlier.
This doesn’t work for Internet Explorer users, so it’s
not a general solution. A second way to force the user to look at the
image before viewing the HTML is to send an image with an HTTP
Content-length header that deliberately lies about
the size of the image, claiming that it is bigger than it really is,
so that the browser hangs waiting for more until the user hits the
Stop button. A third way to achieve the same effect is to put the GIF
in its own HTML frame and to put the content in another
frame—but delayed by the server until a good while after the
GIF loads. The delay can be generated several ways. One way is to
load a blank page in the bottom frame and include a <META> tag
in its HTML, like this:
<meta http-equiv="refresh" content="5;url=Show.html">
Java is not yet as popular in web advertising as animated GIFs are. Still, there are enough sites using gratuitous Java that it may be worthwhile for you to turn off Java if you can’t spare any bandwidth for the applet download. Another performance problem with Java is that it can take 15 or 20 seconds to start up the Java virtual machine the first time you hit a page with Java in it. This Java initialization freezes the browser and cannot be interrupted, which can be very annoying.
Like the ALT text, the text within the <APPLET ...></APPLET> tags will be displayed when Java is off, so you will have an idea of whether you want to turn Java back on and reload the page. This text can include any valid HTML, and it is possible that the content designer has created a useful alternative to the applet and put it within the applet tag, so you may not even know that Java is disabled. In some cases, you really need Java: if you must use a Java applet as the client in a client/server application, it won’t work with Java disabled.
Another crude trick that gives the appearance of better bandwidth is to install most of your applet’s class files on the client with the browser’s own Java class libraries. You can put them in the same directory or even in the same .zip or .jar file that comes with Netscape (unzip it, add them, and zip it up again). You can also put them in some arbitrary directory and ask the user to add that directory to his or her CLASSPATH. You then download a stub applet from the web server and use that applet to refer to the bulk of the locally installed code. This requires installation work and isn’t practical for publicly available applets, but it’s a big help for intranet applets you’ll need for long periods of time.
A faster client machine will parse HTML faster and retrieve pages from the cache faster, as well as run Java applets faster. This may be an obvious tip, but it won’t help much if the bottleneck is your network connection or the speed of the web server at the other end of that connection.
Your video performance is limited by your graphics card and CPU, not by your monitor. If you buy a faster video card, your display and scrolling performance should improve. Another option is to include more video RAM (VRAM) on the video card. This will help only up to the point where you have enough VRAM to store the entire display buffer.
Ironically, 8-bit color video cards, or even black-and-white cards, are often faster than 24-bit color video cards, because they have much less work to do and put less of a load on the CPU.
If you’re trying to read a popular site, consider that there may be mirror sites that are less heavily loaded. Mirror sites are usually mentioned on the home page of a site. AltaVista (http://www.altavista.digital.com), for example, has mirror sites around the world, as does the Apache site (http://www.apache.org).
Browsers cache the documents you view and then retrieve an item from the browser’s cache if you request it again. Because the document may have changed in the meantime, the browser will by default contact the original server to validate the freshness of every cached page. If the document has changed on the server, the new version will be downloaded. If the locally cached copy is up to date, then it is displayed. The validation request may require only a little network traffic if the document has not been modified, but you’ll still get better performance from using what’s in the cache without verification, and you won’t have to download any pages with trivial changes. You may get stale pages, but at least you’ll get them quickly.
To get the performance gain from not verifying cached documents in Netscape, set Options → Network Preferences... → Verify Document: to “Never”. If you suspect you’ve got a stale page, it’s an easy matter to force Netscape to get the current version. Simply hold down the Shift key and hit Reload. Setting Verify Document: to “Once per Session” is second-best; this will verify the timeliness of the document just once for that Netscape session. Setting Verify Document: to “Every Time” is worst from a performance point of view. This instructs Netscape to check with the original server for a fresher version every time you view that page.
There are a number of “read ahead” products that immediately retrieve all of the pages linked to by the page you’ve just loaded, whether you intend to look at them or not. While this definitely speeds up perceived performance if you spend a bit of time reading the current page and then jump to a link from of the current page, it’s really not a neighborly thing to do. You probably won’t read most of the content that is downloaded to your machine, so this makes someone else’s server and network do a lot of work for nothing. Take a look at your modem’s read light to get an idea of how much more it is working when you’re using one of these products. Normally, you see the read light when loading a page, and then the light goes off, showing that you’re not reading anything more off the network. With one of these read ahead products, the read light will probably never turn off. Two read ahead products for Windows 95 and NT are Blaze (http://www.xspeed.com) and PeakJet (http://www.peak.com).
If you are on the West Coast of the U.S., be aware that there is a lot of traffic in the morning because the East Coast has been up and surfing for three hours already. So the East Coast gets better speed early in the morning because the Californians are asleep, and the West Coast is faster late at night because the New Yorkers are asleep.
You can tell if your disk is working hard by listening to the machine. Hard disks are noisy things, so if you hear a lot of crunching going on when your hit the Back button, for example, you know that the machine is getting the previous page from disk and not from memory. This may be because the browser has used up the RAM you allocated to the memory cache or because the operating system is paging. If you hear silence but the machine still takes several seconds to show the previous page, it’s a good bet that your machine is just slow to parse and display HTML, so you’d probably be better off with more RAM for the browser’s cache, or a better CPU, video card, or bus. To get a better bus, you have to get a new machine.
It has always been well worth the money for dial-up users to buy the fastest modem available. If you are dialing in over a POTS phone line, that’s currently 56kbps. 56K modems have incompatibilities between brands due to the use of chip sets that follow different standards. You should check what sort of modem is going to be on the other end, say at your ISP or company dial-in port, and purchase the same brand or one known to be 56K-compatible with it. If the modems include the same chipset, they’re probably compatible.
Many higher-bandwidth access services are available, but all have a higher cost. You can get 128kbps from ISDN by “bonding” the two 64kbps channels together. ISDN, unlike 56K, has limited availability and steep startup and per-minute costs because the service is available only through local phone monopolies. Some local monopolies also offer Asymmetric Digital Subscriber Line (ADSL) at rates up to 1.5Mbps, but both ADSL and ISDN require that you pay two bills: one to the phone company to rent the physical wire, and another to your ISP for Internet connectivity. In some areas of the country, you can get cable modem service for $50-100/month, approximating ADSL bandwidth. Cable modem providers also act as ISPs. I have had both ISDN and cable modems, and I prefer the cable modem, because it has higher bandwidth, it’s always on, and it’s been more reliable than ISDN. Your local cable monopoly can tell you whether they offer this service in your area.
A PPP connection over a modem, dialing direct to another modem attached to a web server, has reasonable latency and sometimes better throughput than the Internet even at only 28.8kbps. This is a very rare solution, but the moral is that the Internet is not the only way to get to a web server. If you need good access to a web server at work, find out if you can dial into a modem attached to your LAN at work.
Whether you’re browsing or serving, a dedicated digital line is almost always better than using a modem over a POTS line. The first step up is ISDN, cable modem, or a 56kbps dedicated line. These connections are more expensive than an analog line, but they have much better throughput.
If you are spending most of your time getting data from one server, it may be worthwhile to get an account with the ISP that connects that server to the Internet. You’ll probably see better throughput and latency working from an account on the same ISP than from somewhere else. Telecommuters probably want an account with their company’s ISP.
A proxy server between your organization and the Internet will cache frequently requested pages, reducing the load on your connection to the Internet while providing faster response time to the users for cached pages. The benefit you see depends on the number of times the requested page is in the cache. If all web requests were for unique URLs, then a proxy would actually reduce performance, but in practice, a few web pages are very popular and the cache is well used. The proxy server has a particular need for speed, since it must act as both client and server. Proxies are write-intensive, so they can benefit a lot from a caching disk controller.
Also, keep in mind that proxies are likely to make some Java applets unusable, since applets can currently connect back only to the server they came from. The server they came from will be the proxy, which is not where the applet probably thinks it came from.
DNS servers can become overloaded like anything else on the Internet. Since DNS lookups block the calling process, a slow DNS server can have a big impact on perceived performance. Consider setting up additional servers or simply pointing your DNS resolver to another DNS server.