In Consideration of Dialup Users

Posted by santosj on July 21, 2007

There are enough visitors on dial-up that it makes sense to support them. Well, that decision should be based on what percentage and what percentage you decided to support. If anything is more than 1%, I think it is worth to support them as much as possible. Who cares about the supporting a minor audience when so many more people enjoy what you’ve done? Then again, 1% might be more than 10K or 100K, but I don’t work on any of those sites. I still think that any large amount should be supported.

The question came up on how to improve the speed for those who are on dial-up. There are many. Well, ultimately, you could say to them, “Screw you, get Broadband!”

  1. Build an entirely new site geared to just those users, but with static pages, that would mean twice the work. With many pages, it wouldn’t be feasible.
  2. Use AJAX, which isn’t a cure for the problem, but just a hack of a solution. (I have since been banned from using the cleaner in reference to anything site related)
  3. Use Progressive (or Interlaced) images.
  4. (Related to #3) Use the lowsrc attribute for img elements. (The real reason this isn’t used, is that Progressive and Interlace images do this work, so there is little need.)
  5. Some Deferred method for JavaScript and CSS, which would load it after the page was loaded.
  6. Some sort of theoretical JavaScript timer which would wait for when the page loaded and then after so long ask the user if they wanted to see the low bandwidth site (Again, not a cure and might not work)
  7. Have a message that is outside the main content flow that links to low source page and would be overlapped when the main content is finally loaded.

Splash Pages are not an option, because they suck and then you suck by association.

There are many more, but I think the best option is to have something come up, so that the user at least gets some reward for visiting your site. During some investigation, it was found that the total HTML was 30K and other sites of comparable sizes, loaded much quicker. It didn’t seem logical that sites of same sizes could load much much quicker. There had to be something different.

Enter GZip and Deflate

If it takes 20 seconds to download just the HTML, then your problem isn’t the images. It takes time to download the HTML. What if there were just so way to compress the HTML before you send it to the browser and the browser had some way to decompress before it displayed it?

Luckily there is. It is funny how much you forget when you don’t use the crap. It is also funny how stuff comes to you when you are thinking about random crap. “Oh yeah, that is how!”

The fastest and I would say the best method (since it doesn’t require an apache restart) is to use the php_flag in the .htacess file. The only problem is if PHP is using the CGI SAPI. However, not all is lost, if you are using PHP, then you can enable it in the PHP code. However, this only leaves out static pages! Oh, it only takes less than a minute with this method.

Apache 2 uses the mod_deflate (don’t argue with me, mod_gzip is unsupported with Apache 2 and I can pull up 10s of sites that same the same thing), instead of mod_gzip. If you use Apache version greater than 2.0.45, then there is no disadvantage to using mod_deflate.

Note: the DeflateCompressionLevel directive must not be <location>, <directory>, and of course can’t be in .htaccess. It is one of the few that has to be in the server config file. Which requires a restart. The rest of the rules probably belong in the .htaccess, because you can easily change them later without a restart. However, most of the rules shouldn’t need to be changed. However, some issues did surface when trying to modify rules. I’m not sure if it because AllowOverwrite wasn’t enabled or if you have to enable it, and where you enable it.

The reason I don’t talk about this in more depth, is because I’m not an Apache expert and you would be better served, if I don’t pull stuff out of my ass. Google it!

Other Options to Consider: JavaScript and CSS

It is better to put as much CSS and JavaScript in the head as possible, since it will slow down the page loading. The page, requires that JavaScript be placed at the top of the page. This is what is forcing the current slow down.

However, the mod_deflate and PHP zlib.output_compression_level effectively solved a majority of the problem. Trying to shave off 3 or 4 seconds, seems like more work than what is worth it. I do know of a solution, but more pressing issues exist.

Possibly Related Posts:


Programming

Comments are closed.