Web site optimization tips

Started by 127.0.0.1, February 01, 2007, 12:24:08 AM

Previous topic - Next topic

127.0.0.1

I am interested in hearing tips from the members of this community concerning web site optimization for achieving faster load times, less bandwidth usage, fine-tuning Apache and/or PHP, and achieving better results in search engines.

Here are some I have learned from reading various articles, W3C.org, and from my own experience. Please call me out on any erroneous information I provide -- its not intentional.


  • Try to minimize the number of HTTP requests on the web page.
  • Avoid using tables where CSS will suffice. Especially avoid nesting tables. And where tables are used apply a fixed length to speed there rendering in the browser. This one is tough to avoid for message boards obviously, but I think it is possible to replace tables in the board and message index with horizontal lists. I think the only problem is compatibility, older browsers do not all render stylized lists the same.
  • SMF specific: Limit the number of messages on the message index to no more than 20. More than that I have noticed lag when the browser renders the message index table.
  • Use HTTP compression such as gzip content encoding
  • Specify width and height attributes of images
  • Use the proper tags to improve document structure. Heading tags for headings, paragraph tag for a paragraph, UL tag for lists, etc. This provides a "semantic rich" document making it intelligible to user agents such as search engine spiders.
  • GIF vs PNG vs JPEG. JPEGs are suitable for photographs. PNGs can be used for most other content. Identify which browsers do not render transparent PNGs properly and considering using GIFs in their place.
  • Optimize your images. I use PNGOUTWin. There are online image optimizers, though I have never used one so I cannot testify to their effectiveness.
  • Limit the amount of images used to minimize HTTP requests. Combining your images and using image maps is one way to accomplish this.
  • Call external stylesheets before anything else (such as JS) in the head of the document since that is what the browser needs to render the content.
  • Try to limit each external stylesheet/Javascript to less than 1160 bytes so it fits within one higher-speed TCP-IP packet. Though I have seen the validity of that statement disputed, and I don't know of many sites utilizing CSS that can achieve a 1160 bytes or smaller stylesheet.
  • Following up on the previous point; if your site receives a lot of traffic, reducing the size of a relatively small file like a CSS can save much bandwidth. A CSS file can be optimized by removing as much redundancy as possible, for example unnecessary elements such as

    • line breaks
    • tab indents
    • excessive white space
    • /* coments */
    • zero length units (0px -> 0)
    • utilizing CSS shorthand, and three-digit hex color codes where applicable
  • You can compact external scripts using the same principles
  • If content encoding (gzip) is not an option the same principles can be applied to the [X]HTML as well. I'd even go as far as declaring a base href in the head of the document so I could use relative URLs rather than absolute URLs.
  • It is good practice to remove redundancy even if the document is being compressed.
  • Fasterfox: This is not an optimization per se but you can use the the robots.txt file to block the Fasterfox user agent from raping your sites bandwidth by including the following
    User-agent: Fasterfox
    Disallow: /


That's all I could think of right now.

P.S.: I didn't really know where to post this but because it may involve HTML, CSS, PHP, and possibly even the web server I figured this board was a good bet.




Dannii

QuoteTry to limit each external stylesheet/Javascript to less than 1160 bytes so it fits within one higher-speed TCP-IP packet. Though I have seen the validity of that statement disputed, and I don't know of many sites utilizing CSS that can achieve a 1160 bytes or smaller stylesheet.
I've never heard of this before. If it's a choice between multiple small files and one large file, the one will be more efficient though. If you only have one file and it's 1200 bytes or something, maybe it would be worth reducing it however..
"Never imagine yourself not to be otherwise than what it might appear to others that what you were or might have been was not otherwise than what you had been would have appeared to them to be otherwise."

goitalone

Whats the best way to add keywords to SMF ? Also, the rest of meta tags as well?

goitalone

Oh..yeah one more thing...can install joomla around my SMF? Is it hard, easy? Do I have to worry about corrupting my forum? I mean how high is the risk?

127.0.0.1

Quote from: eldʌkaː on February 01, 2007, 12:28:01 AM
I've never heard of this before. If it's a choice between multiple small files and one large file, the one will be more efficient though. If you only have one file and it's 1200 bytes or something, maybe it would be worth reducing it however..

This is from websiteoptimization.com...

"CSS_SIZE - Caution. The total size of your external CSS is 4207 bytes, which is above 4080 bytes and less than 8K. For external files, try to keep them less than 1160 bytes to fit within one higher-speed TCP-IP packet (or an approximate multiple thereof). Consider optimizing your CSS and eliminating features to reduce this to a more reasonable size"

I have found a further explanation of this discussed here...

Quote
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.

Quote
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

127.0.0.1

Off topic: When I try to modify my original post to correct a typo my changes are not saved though the last edit time is updated.

goitalone

Same here...someone turn off edit profiles?

127.0.0.1

#7
Another thing I just learned about optimizing a site for search engines.

I have the layout of each page on my site divided into two columns -- #left and #right.

The #left column contains navigation links, recent discussion links, et cetera.

The #right column contains the content of the site. That is the meat and potatoes of each page.

Even with good semantics, Google seems to display the description of each page using whatever applicable text it crawls first in the HTML. Which in the case of my layout would be irrelevant stuff in the #left column.

Therefore, I'll make it crawl the #right content first by placing the div containing the #right ID selector before  the #left in the HTML. Then in my stylesheet I added float: right; to the #right ID selector and float: left to the #left ID selector.

Now the next time Google crawls my site hopefully the page description will begin with the content rather than than the menial navigation text. I picked this up when looking at Wikipedia's HTML source. Because they have links on the left, content on the right, but in Google their content always comes up first in the description.

I think an added benefit for this in SMF, depending on your layout, the browser will render your page faster if it gets the largest section (the forum content) done first.

Ensiferous

Most of what you listed deals with render time for the browser; most of it is correct, and to me, common sense. However, deleting linebreaks and tab indenting in your css file is just stupid, next time you have to edit it you'll be banging your head because you removed all maintainability.

One thing many templating systems are begining to offer is combining several javascript files into 1 file. This is done as only 2 files can be downloaded at the same time, so having it all downloaded at the same time instead of split out gives a speed increase and will, if used properly, make your page render faster.

There are, of course, also a bad side of things, with all files combined you may have upwards of 200 kb of javascript in one file. (especially if you're doing real 2.0 with neat drag-n-drop features and ajax)

You might also want to look into installing an opcode cache for php (http://devbee.com/opcode_cache_for_dummies) for reference and (http://www.eaccelerator.net/) for one of them.

Yet another thing is to learn how to profile your scripts, using Xdebug (http://www.xdebug.org) and WinCacheGrind (http://sourceforge.net/projects/wincachegrind/)
My Latest Blog Post: Debugging Nginx Errors

127.0.0.1

Quote from: NoFear on February 02, 2007, 03:10:17 AM
Most of what you listed deals with render time for the browser; most of it is correct, and to me, common sense. However, deleting linebreaks and tab indenting in your css file is just stupid, next time you have to edit it you'll be banging your head because you removed all maintainability.

You are correct. I should have mentioned that you compact only the CSS or JS file that you upload to the server while keeping the original available for future developing. That's how I do it at least. I made a PHP script that removes all the unnecessary stuff automatically.

In the case that I lost the readable version I'd just use the same script to explode the style sheet into something legible. I am sure there is even software available that does both compaction and "uncompaction" of CSS and JS.

Sverre

Very interesting discussion!

I'm not much of a coder, so I'll leave the major improvements to the SMF team and the next version's default theme, but I've played around a bit with CSS optimization following these tips:

Quote from: 127.0.0.1 on February 01, 2007, 12:24:08 AM
  • Following up on the previous point; if your site receives a lot of traffic, reducing the size of a relatively small file like a CSS can save much bandwidth. A CSS file can be optimized by removing as much redundancy as possible, for example unnecessary elements such as

    • line breaks
    • tab indents
    • excessive white space
    • /* coments */
    • zero length units (0px -> 0)
    • utilizing CSS shorthand, and three-digit hex color codes where applicable

And not only has it given me more efficient style sheets, but it has also given me a much better understanding of CSS :)

Advertisement: