Why do web pages of text load so slowly?

November 25, 2007 3:18 PM

Some web pages with a lot of text seem to load slowly, even over broadband, and especially when compared to the bandwidth streaming video uses, I don't understand why. Can somebody explain? (Warning: Those links load slowly.)
posted by cgc373 to Computers & Internet (14 answers total)

They take a while to load because there is a lot to load on those pages. Streaming video is just like a text web page - When enough video has been downloaded to start watching it, it starts playing. Just as you see the top of those text pages while the bottom is loading, you watch the beginning of the streaming video while the end is still loading.
posted by mzurer at 3:22 PM on November 25, 2007

(also some pages are being generated on the fly, so there is no reason to think that serving "only" text is somehow always easier than streaming video. Not to mention that sites that serve video are engineered to serve video, so they may actually be able to serve much larger files faster than other servers can serve text.)
posted by mzurer at 3:24 PM on November 25, 2007

If those pages are generated on the fly from text in a database the bottleneck could be at the server. I've worked on poorly coded pages that do just this, and some took up to a minute to serve a mere 100k of text when the database was getting hit hard.
posted by waxboy at 3:26 PM on November 25, 2007

Also depending on your browser you have to be rendered by the browser, which could seem like it is loading slow.
posted by bigmusic at 3:28 PM on November 25, 2007

What people mean by "generated on the fly", is that the text isn't just one big file on the server that gets sent to you, the way video is. Each comment, on a metafilter page for example, has to be pulled from a database and formatted by the server software to display uniquely for you. This takes some time, and on heavily loaded servers, it can be quite slow. And on your end, in your browser, it has to do a lot of page composition as the text arrives. This is particularly bad if the text is kept in a table, which thankfully is rare these days. Some pages also tend to pause and not display until associated Javascript files have been downloaded.
posted by Jimbob at 3:50 PM on November 25, 2007

It could also be a Quality of Service (or traffic shaping) issue. I guarantee that somewhere between you and mefi there is some host or router that has it enabled. Anecdotally, the default rules for QoS on my router put web pages over 10kB on a lower priority than smaller web pages. That's not exactly what it sounds like is happening in your case, but QoS (and its variants) is in widespread use across the internet.
posted by philomathoholic at 4:02 PM on November 25, 2007

Sometimes pages which seem to be primarily text have lots of little graphics files, and CSS files, and lots of other crap. It's not uncommon for it to be slower to access and load a lot of small files than it is one big file.
posted by Steven C. Den Beste at 4:10 PM on November 25, 2007

Also, you might need to change the browser setting which controls the number of simultaneous access you can have going at once. See this.
posted by Steven C. Den Beste at 4:12 PM on November 25, 2007

Have you considered the size of the pages to which you linked? Just because they only display text doesn't mean that they can't have a TON of text to render, which will slow the page load time because of the sheer size of the page. For example, the following news pages, which display both text and photos, load quickly because their index pages are quite small in size:

http://www.usatoday.com/
Size: 16,818 bytes

http://www.cnn.com/
Size: 32,790 bytes

http://news.google.com/
Size: 43,158 bytes

All under 50,000 bytes. However, your three pages are each over 1,000,000 bytes:

http://metatalk.metafilter.com/15330/Your-thoughts-on-current-and-future-changes-to-make-Metafilter-more-woman-friendly
Size: 1,208,897 bytes

http://nielsenhayden.com/makinglight/archives/009546.html#009546
Size: 1,327,919 bytes

http://metatalk.metafilter.com/15281/Discussion-Point
Size: 1,785,774 bytes

Text or photos, bytes are bytes - when you load over 1,700,000 bytes, the page is going to take longer to load than 16,000 bytes.
posted by seymour.skinner at 4:24 PM on November 25, 2007

Often, this kind of thing is due to tracking code that has to connect to a third-party server upon page load, but it doesn't look like that's the case in at least two of the three cases here.
posted by Mr. Gunn at 4:36 PM on November 25, 2007

Yeah, I'll chime in with seymour.skinner and say to the people complaining that 1200+ comment threads are taking too long to load -- it's a 2Mb file for chrissakes! Depending on your connection, it could easily take 30 seconds or so to load that much data and on top of that, browsers aren't exactly optimized for displaying web pages bigger than a few hundred kb. I've seen blogs with a zillion posts/comments lock up my copy of Firefox on a 8Mbit line often enough that I basically restart the browser twice a day just to keep it stable.
posted by mathowie at 6:11 PM on November 25, 2007

Response by poster: Yeah, I do that restart thing, too, mathowie; I just wondered whether there was some technical reason text might take longer than, say, a Flickr Leech page. Of course, that page takes a while to load, too. I guess I expected text to take less time, and it doesn't, because it's a similar amount of data. Just misguided expectations on my part, then.

Thanks for your answers.
posted by cgc373 at 7:23 PM on November 25, 2007

In my experience, the problem with the metafilter 1200 comment threads is not that they take long to load (that's expected) but that they very frequently never finish loading at all. They often stall with "scripts.metafilter.com" in the status bar, for what that's worth.
posted by Rumple at 9:20 PM on November 25, 2007

Hope not to oversimplify: your browser, whichever it is, is capable to establish a certain number of connections to the web server: the first one is used to download the HTML document, which is what includes all information about the content of the page and the content itself.

A second connection is usually for the style sheet file(s), which (ideally, but this can depend heavily on how the page is designed) includes all the information about how the page is displayed.

Then, as the HTML and the style sheet are being downloaded, the browser parses them and makes further requests to the server for other content, such as images, video, and so on. These connections are concurrent until a maximum number is reached, then they are queued.

As the browser has downloaded enough content and layout information to "decide" how the page is to be displayed, it starts rendering the page on your display (which is why, depending on the browser and/or the overall speed of the data downloading, you might see the layout "adjusting" itself as new content is being downloaded)

So, there's a lot of factors influencing the overall speed of a page, from the moment you click on the link to the moment your browser displays "completed" on its status bar.

As for the problem for very long text pages, the text content, is included in the very HTML document, and this means that there is only one connection that takes care of that, so it can take a while, moreso if the text is retrieved from a database on a very busy server.

If the page is properly designed, you will be able to start reading as new content is downloaded, though.
posted by _dario at 2:55 AM on November 26, 2007