Does Formatting Code Slow Down The Page?

Forum Moderators: open

Message Too Old, No Replies

Does Formatting Code Slow Down The Page?

By adding tabs and spaces to format code are you slowing down the page?

guiroo

2:16 pm on Jul 30, 2003 (gmt 0)

I know it depends on the size of the page but should I worry about tabs and spaces adding enough bytes to make a noticable difference in the download time?

Thx!

NickH

5:57 pm on Jul 30, 2003 (gmt 0)

It can make a difference, obviously along with other page elements, such as images. Line breaks and other superfluous (from the perspective of the browser) whitespace also add to download time.

Nick

[edited by: tedster at 6:35 pm (utc) on July 30, 2003]

tedster

7:36 pm on Jul 30, 2003 (gmt 0)

However, unless your page is heavily loaded with superfluous line breaks and tabs, the savings you get by eliminating these types of characters will be minor.

I recently re-worked the code for an existing site and found that saving even 1kb took more than eliminating tabs and line spaces. Some WYSIWYG editors really pump out the tab formatting - I've always thought it was excessive. 1 character is 8 bytes, I believe, so a couple hundred tabs and you've quickly added 2kb or more. Still, 2kb of text isn't all that much on today's web with native modem compression available.

But even more than bandwidth savings, I think all that formatting makes it HARDER to read the code, especially for table grid layouts.

NickH

11:01 pm on Jul 30, 2003 (gmt 0)

One character is one byte -- unless you're using Unicode, when it can be two.

I agree, though, that eliminating whitespace should be some way down the list in website optimization. Some factors that are usually more important include:

1. Ensure graphics are compressed.

2. Specify height and width for all graphics. (Speeds page rendering.)

3. Validate all HTML, and specify a DOCTYPE that will trigger standards compliance mode -- again, speeds rendering.

4. Use one external stylesheet. (Or as few as is reasonable for your site.) Try to keep it under 1160 bytes, to fit in one higher-speed TCP-IP packet.

5. Where possible, enable incremental rendering of tables. (For example, if you can tell the browser the number of columns, and their widths, the table will render much faster.)

6. Whitespace-crunching, and other extreme optimizations, may be worthwhile on a home page, or high traffic page.

Nick

claus

11:17 pm on Jul 30, 2003 (gmt 0)

>> Try to keep it under 1160 bytes, to fit in one higher-speed TCP-IP packet.

- is this in fact the size? No kidding? I didn't know that, thanks :)

NickH

8:06 pm on Jul 31, 2003 (gmt 0)

>> Try to keep it under 1160 bytes, to fit in one higher-speed TCP-IP packet.
- is this in fact the size? No kidding? I didn't know that, thanks :)

I should qualify that somewhat...

My understanding is that packet size, negotiated at connection time, is typically between 576 and 1500 bytes, depending on connection speed.

On faster connections (> 128Kbps), packet size is typically 1500 bytes. Subtracting TCP/IP overhead of 40 bytes, and HTTP response header when the server first answers a client request (250-300 bytes), leaves 1160-1210 bytes.

It has been shown that, on faster connections, download time is directly affected by the total number of TCP/IP packets. So squeezing an external CSS file into the first available slot (assuming nothing else in <HEAD>) is optimal.

Nick

killroy

12:27 pm on Aug 1, 2003 (gmt 0)

yeah, except that HTTP uses something called a "slow start". It begins with the worst case scenario, and then tries to find out the ideal speed (and packet size) over the next couple of packets.

Except of course that in most web communicatiosn th etransfer is funished, long before this process is complete. So ultimatiely you'RE stuck in the worst case and should design your packet alignment for that. I jsut read the RFC for it, but am too lazy to look it up. Just google for HTTP/1.1 packet size slow start RFC.

Ah, there it is: www.w3.org/Protocols/HTTP/Performance/Pipeline.html

antoshka

8:56 pm on Aug 1, 2003 (gmt 0)

recently i was working on a project where i was generating HTML dynamically (PHP) and the resulting page had a line of code repeated many times, each time with a slight difference. there was several hundred lines, so the total page size came out to be 130Kb. i had to spend some time to complicate the logic of the script in order to generate less characters. after hours i was able to reduce the resulting file to 25Kb.

the point is, if you use a space for indentation on a signle - that's ok. if you use it for indentation everywhere - consider CSS. this way you might save a couple of kilobytes in a big page.

[edited by: engine at 9:11 pm (utc) on Aug. 1, 2003]
[edit reason] No sigs, thanks. See TOS [webmasterworld.com] [/edit]