Jump to content

  • Log in with Facebook Log in with Twitter Log In with Google      Sign In   
  • Create Account

Subscribe to HRA Now!

 



Are you a Google Analytics enthusiast?

Share and download Custom Google Analytics Reports, dashboards and advanced segments--for FREE! 

 



 

 www.CustomReportSharing.com 

From the folks who brought you High Rankings!



Photo
- - - - -

Google Ranking By Page Speed And Their Recommendations


  • Please log in to reply
18 replies to this topic

#1 rolf

rolf

    HR 6

  • Active Members
  • PipPipPipPipPipPip
  • 675 posts
  • Location:Suffolk UK

Posted 18 December 2009 - 08:05 AM

I've been looking at the site performance metrics for one of my sites in Google Webmaster Tools and was a little dismayed to see that a fair number of pages from this site are considered slow loading :-s

My immediate reaction was confusion, as although I'm not an obsessive I think I write fairly clean code on the whole. Luckily they have recommendations for speeding things up and it doesn't seem to be code that's the problem - which is good and bad I suppose :-s

I wanted to get opinions on the 4 main recommendations and anything else anyone would like to add about what might be useful techniques for speedifying my pages or making use of the new factor in ranking.

1. Enable Gzip Compression

OK, it's a while since I first learned about servers and all that, but has this passed me by? I have heard of gzip but didn't realise browsers could handle it natively, so I've not used it.

Sounds like a good idea, but can I really just gzip files and not encounter compatibility/usability issues?

Will this add a whole extra step into my development process or can it be automated?

2. Leverage Browser Caching

They recommend setting at least a 1 month cache on all my images. Fair enough, I could do that, but should I? It seems like a big PITA without much benefit so I've always left caching down to the individual unless I don't want something cached, am I a bad person for doing this? Should I already be telling my visitors how to cache?

They also say that
QUOTE
Resources that do not specify an expiration may not be cached by browsers


Is that true?

3. Minify Javascript

OK, it's a bit of a PITA for development (e.g. reading the code by eye), but I'll buy that I suppose. There's also a few redundant functions I could chop out, although I've always been reluctant in case I find some time time later that there was still just 1 page using that function, but I can live with that.

4. Parallelize downloads across hostnames

This is also a new one on me and from the brief bit of research I've done it seems I'll have to look into this a bit further before forming an opinion, but feel free to give your opinions, tips and anything else you like.

To summarise, it looks like I'm gonna have to get my head round some new ideas and change my working practices on a few things to make the most of their new speed assessment idea, but, it also looks like these will be useful things that could benefit my visitors, so it's not all bad.

#2 1dmf

1dmf

    Keep Asking, Keep Questioning, Keep Learning

  • Active Members
  • PipPipPipPipPipPipPip
  • 2,167 posts
  • Location:Worthing - England

Posted 18 December 2009 - 08:58 AM

QUOTE
OK, it's a while since I first learned about servers and all that, but has this passed me by? I have heard of gzip but didn't realise browsers could handle it natively, so I've not used it.


hmm, interesting rolf, I'm was not aware browsers handle zip files natively, i thought it was either an installed program or the OS.

You learn something new everyday.. here is some info on it http://betterexplain...ip-compression/

I certainly wouldn't compress your javascript files, if you get muddled up between the shrunk JS file and the source one, you end up with code you can no longer maintain or alter unless you manualy re-format the file!

Edit-> I noticed on the link I posted there was a pingback for speeding up Javascript loads, so that might help you wink1.gif

What's interesting is if Google have offically stated that speeding up page loads will increase rankings, then that is clearly another reason in having clean, semantic, standards compliant markup , removing code bloat such as exessive use of tables for layout etc. not complying with the standards can make a difference on load times, and thus directly affect ranking!

Edited by 1dmf, 18 December 2009 - 09:13 AM.


#3 rolf

rolf

    HR 6

  • Active Members
  • PipPipPipPipPipPip
  • 675 posts
  • Location:Suffolk UK

Posted 18 December 2009 - 10:11 AM

Good resource, thanks.

I'd be interested to hear yours, Randy's and others' opinions of the pros or cons of the various methods of invoking gzip (e.g. via php or in htaccess, and if htaccess then mod_deflate or mod_gzip). I'd think htaccess would be the preferred choice, but further than that I can't really make comment.

QUOTE
What's interesting is if Google have offically stated that speeding up page loads will increase rankings, then that is clearly another reason in having clean, semantic, standards compliant markup ,


Yes, interesting to see where this is going in the arms race that is the quest for higher rankings.

#4 1dmf

1dmf

    Keep Asking, Keep Questioning, Keep Learning

  • Active Members
  • PipPipPipPipPipPipPip
  • 2,167 posts
  • Location:Worthing - England

Posted 18 December 2009 - 10:52 AM

QUOTE
I'd be interested to hear yours, Randy's and others' opinions of the pros or cons of the various methods of invoking gzip (e.g. via php or in htaccess, and if htaccess then mod_deflate or mod_gzip). I'd think htaccess would be the preferred choice, but further than that I can't really make comment.
I'd like to know the best way also, I currently have a support ticket with my web host asking exactly this question as when i logged into my plesk contol panel I couldn't find an option to enable gzip.

As soon as I get a reply on how I turn it on and if .htaccess should be used along with if DEFLATE or the GZIP method is preferable, I will post back.

#5 qwerty

qwerty

    HR 10

  • Moderator
  • 8,695 posts
  • Location:Somerville, MA

Posted 18 December 2009 - 11:19 AM

I've been looking at the Apache documentation and it's not clear to me whether I just need to add
CODE
AddOutputFilterByType DEFLATE text/html text/plain text/xml
to .htaccess or if I also need
CODE
SetOutputFilter DEFLATE


#6 Jill

Jill

    Recovering SEO

  • Admin
  • 33,244 posts

Posted 18 December 2009 - 12:23 PM

I wouldn't blindly believe that Google is using page speed as a ranking factor.

I'm sure they have an ulterior motive for spreading this particular round of FUD. Just not sure what it is yet.

Perhaps they have an app for it?

#7 Randy

Randy

    Convert Me!

  • Moderator
  • 17,540 posts

Posted 18 December 2009 - 12:38 PM

Just to make sure we're all being clear on this, gzip is not the same thing as zipping a file. Similar maybe, but not the same. We're talking HTTP Compression here, not actual file compression. Technically what we're talking about is known as Dynamic Content Encoding, which just means the compression or encoding happens when the file is requested, not when the file is uploaded.

To make it more confusing, this stuff is handled at the server configuration level. As a webmaster you don't do anything special with your files when you're uploading them, the compression just happens if the server is configured to support one or more of the various methods of compression.

And to make it even more confusing, there are several different ways to provide compression.

The two main Apache modules are mod_deflate and mod_gzip. They're similar but not the same.

And there are also alternative ways to provide compression that are language dependent. For example, PHP provides ob_gzhandler and zlib output compression. You can use one or the other, but not both.

Limiting ourselves for the sake of sanity, the differences main differences between Apache's mod_deflate and mod_gzip are:
  • mod_deflate comes pre-installed and enabled in recent versions of Apache. mod_gzip doesn't, meaning you'd have to recompile Apache to have it available if it's not already. Many hosts do compile Apache with mod_gzip support, but not all do. So it may or may not be an available option. (You can see this in the Loaded Modules section for Apache's handlers in a standard phpinfo(); page.)
  • mod_gzip will offer a higher compression level than mod_deflate, meaning lower bandwidth usage and faster file delivery.
  • mod_gzip carries a slightly higher server load effect than mod_deflate.
And the main differences between PHP's zlib and ob_gzhandler methods are:
  • zlib.output_compression runs parallel with the php script execution, meaning it begins compressing as soon as it receives any output from the script, sending chunks of data to the client each time it reaches its preset buffer limit is reached. That's chunks of data 4k in size by default.
  • Conversely ob_gzhandler does not start compressing the data until the script "flushes", which usually means the script has exited, and will then send the entire compressed document all at once. It's this wait until the end trait that can make ob_gzhandler seem slower for very large files, because nothing at all shows up on the screen until it's all finished.
  • ob_gzhandler allows you to set the level of compression at run time, or if you don't tell it a level explicitly it'll use its default compression level.
  • ob_gzhandler benchmarks show a slightly higher CPU load quotient than zlib, but it's not a huge difference.
In most cases it doesn't matter much which compression routine you choose to utilize. The differences are small enough as a general rule that it just doesn't matter. What can matter however is if HTTP compression is happening or not.

Side note: Older browsers, especially old versions of Netscape, IE5 and even 6 used to sometimes have issue with compression but that's pretty much a non issue these days. The problem was they'd send a header saying they could handle compressed/encoded files when they didn't. Those bugs have been wiped out in all modern browsers.

Another side note... This all is only dealing with Text Compression. It has nothing to do with image compression. Images and other binary files should already be compressed before they're uploaded.

Do I have my servers configured to automatically utilize compression? Yes I do. I try to keep things pretty normal these days since it's the easiest to do and there aren't any huge advantages for taking extra steps. So long story shorter, I have Apache set up to use mod_deflate that comes as a pre-installed module and have my php.ini set up to enable zlib.output_compression. Then if I need better compression or need to control the level of compression of a single file I start ob_gzhandler, which I also have compiled into PHP via the Zend stuff.

Does it make a difference? Yes it can and does. Both in page load speed and in bandwidth usage. The latter being the bigger reason why I enable compression by default. It's not at all unusual for basic compression settings to cut the file size / bandwidth usage for delivery of a file by 50-60%. On those sites where I have enabled ob_gzhandler by default (via an .htaccess instruction that says php_value output_handler ob_gzhandler since it's already compiled into php and available) it's not at all unusual to see compression levels of 70-75%.

So your #1 recommendation is something one could write an entire book about. giggle.gif There is no single best answer. It depends. Sometimes no compression is just fine. Most times some form of compression is better, but you need to choose the one that best fits your specific situation.

#8 Randy

Randy

    Convert Me!

  • Moderator
  • 17,540 posts

Posted 18 December 2009 - 01:01 PM

Bob,

It depends.

If memory serves the first line in your example is all you should need for a sort of global setting for text files.

Apache also allows you finer control over what gets compressed and what doesn't. That's where the other commands come into the picture.

-- Edit to add --

There are freebie tools out there online where you can check pages to see if they're compressed or not. And also to check to see if your browser notifies that it accepts http compressed data. One such tool can be found at www.whatsmyip.org/http_compression/

#9 qwerty

qwerty

    HR 10

  • Moderator
  • 8,695 posts
  • Location:Somerville, MA

Posted 18 December 2009 - 01:25 PM

I must be doing something wrong. I added that line to my .htaccess then tested out a page using the tool Randy mentioned. Here are the results:
QUOTE
Actual Page Size: 16.36 KB
Size if Gzipped: 6.24 KB
Potential Savings: 61.86%


#10 Randy

Randy

    Convert Me!

  • Moderator
  • 17,540 posts

Posted 18 December 2009 - 01:57 PM

Your version of Apache may not have mod_deflate loaded as a module Bob.

If you create a php page with just
CODE
<?php
phpinfo();
?>


and upload that to your server what do you see in the Loaded Modules section? It should tell you there if either mod_gzip or mod_deflate is available. (I'll PM you a link to a phpinfo page on my server to compare against since I don't want to make it public for security reasons.)

Apache 1.3 used mod_gzip, but you had to recompile Apache and install the module manually. Every version of Apache 2 I've seen has mod_deflate installed and enabled by default.

#11 qwerty

qwerty

    HR 10

  • Moderator
  • 8,695 posts
  • Location:Somerville, MA

Posted 18 December 2009 - 04:39 PM

Yeah, it looks like that's the reason it isn't working for me.

#12 rolf

rolf

    HR 6

  • Active Members
  • PipPipPipPipPipPip
  • 675 posts
  • Location:Suffolk UK

Posted 19 December 2009 - 06:45 AM

QUOTE
I wouldn't blindly believe that Google is using page speed as a ranking factor


Fair point Jill, I have my pinch of salt on standby :-) At least this particular idea has some tangible benefits other than ranking, unlike some of the other ideas we hear on how to do well in G lol.gif

QUOTE
So your #1 recommendation is something one could write an entire book about


Maybe you should! As always, enlightening and very helpful.

I've added the gzip compression and it was all simple and straightforward. I've also chopped the oldest of the [hopefully] redundant functions from my JS. Now I guess all I can do is keep an eye on my bandwidth, WMT Site Performance and look out for any other measurable effects.

Does anyone have any comments to make on points 2 (browser cache),3 (minify) and 4 (parallelize )?

#13 Randy

Randy

    Convert Me!

  • Moderator
  • 17,540 posts

Posted 19 December 2009 - 11:38 AM

Those are easier --and shorter-- answers. giggle.gif

Browser Cache - It's the user's browser, so ultimately it's their choice what cache and what not to cache. I never do anything special with caching instructions personally, and in fact have my own browsers set up to not cache stuff for the most part. That's probably a web dev thing though.

Minifying - In a perfect world I'm a huge proponent of a concept I coined a term for many moons ago. The term is Simple Elegance. This concept applies both to the visual look of a site and also to its underlying code. Simply Elegant code is clean, well ordered, minimalist but still gets the job done.

That's perfect world stuff, which usually falls by the wayside a bit as continuing development takes place, new stuff gets added, old stuff gets changed or removed, etc. Though I do still strive to attain the Simple Elegance ideal when I'm coding a new site from scratch or doing a total redesign.

It's not something I stress over, but in a perfect world I do like to have the minimum amount of code necessary to get the job done. Which means I do try to set up functions and classes for stuff that will be reused in two or more places.

Parellizing - This is one that frankly won't affect 99.99% of the sites out there. The trade off of the expense required to have servers located throughout the whole world vs speed increase for different locations or even redundancy simply doesn't measure up. It's wise for the Google's of the world, but is silly exercise to even consider for Ma & Pa Kettle's little web site.

#14 1dmf

1dmf

    Keep Asking, Keep Questioning, Keep Learning

  • Active Members
  • PipPipPipPipPipPipPip
  • 2,167 posts
  • Location:Worthing - England

Posted 22 December 2009 - 04:46 AM

QUOTE
I've added the gzip compression and it was all simple and straightforward.
rolf, what method did you use? I'm still fighting for a coherent response from my web support (they are not normally so difficult!).

I did get a response
QUOTE
Because we use suPHP to parse php files, you have the option of using a custom php.ini file.

Your account can have multiple php.ini files on your account in different folders so you can customize the php processing in different folders should your script require it. A php.ini file will not inherit down into subfolders, however, you can create a .htaccess file in the same folder as the php.ini file and place the following code into it:

suPHP_ConfigPath /home/username/public_html/

where "username" is your cPanel username. This will cause the php.ini file to affect all subfolders, unless a php.ini file is in a subfolder, at which point the php.ini in the subfolder takes precedence.

In php.ini, you will need to use the actual php.ini syntax instead of the php_value or php_flag syntax you would normally use in .htaccess (Which should not be used at all):

setting_name = setting_value

So, this means if you move the settings from .htaccess to php.ini, you must convert the format. Let's say you have the following line in your .htaccess file:

php_value register_globals 0

the corresponding php.ini format is as follows:

register_globals = Off

Notice how the value 0 becomes Off and 1 becomes On. Now if your php_value has quotes like the following, for example:

php_value include_path ".:/home/user/lib"

The corresponding php.ini format is:

include_path = ".:/home/user/lib"

and so on. You should only use the settings you need to change in your php.ini.

For the PHP settings you do not have in your php.ini file, PHP will use our default configurations.

Please do not hesitate to contact us if you require further assistance or have any questions.
But i'd had to email back because I don't understand this respone, I don't use PHP, so I'm not sure how creating a PHP ini file, is going to affect my Perl code / SSI or HTML.

I'm assuming (but correct me if i'm wrong), if you dont use PHP, then it doesn't matter what PHP setting you make, it isn't going to do anything!


#15 Randy

Randy

    Convert Me!

  • Moderator
  • 17,540 posts

Posted 22 December 2009 - 04:58 AM

The easiest way normally is to add the following line to your .htaccess 1dmf.

CODE
AddOutputFilterByType DEFLATE text/html text/plain text/xml


Run one of your pages through any of the compression checkers like the one I mentioned but didn't link to in my post above. Do it before and after you insert the line in your .htaccess file. You should see the tool's response change if compression is in effect after the change.

FWIW, the above is usually easier because it's an Apache instruction that works off of the MIME type of the file. So it should catch and compress all text based files basically.




0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users

We are now a read-only forum.
 
No new posts or registrations allowed.