Google thinks we're slow..?

[lazer]

We moved to XF in early April and were previously on VB. When we were running VB our loading times were in the 1-2 seconds bracket and we were pretty happy with that - even though we had a pretty graphically heavy style and little or no image optimization.

Since moving to XF, surprisingly, Google thinks that the site has become much slower:


..and even though YSlow and PageSpeed tell us that things are ok, we can't work out why they are still experiencing slower load times than in the "real World".

Anyone else experienced this since the switch to XF?
Anyone out there that could give us pointers as to where the problem may lie?

Cheers.

 

[craigiri]

We had some similar results...but ours were (are) due to the following:

1. Google keeps results over a couple months, so it was still figuring in the old forums pages!
2. The social widgets on the front page (or others) take a long time to load - remove them if you don't use them.
3. As always, you may have to tune your server for the innodb tables which XF uses.....
4. Posting in XF is very quick and may not represent a true load of the page according to goog analytics - that may affect page speed calcs since in most older forums a posting DOES create a (relatively fast) reloading of the page.

Even with these changes, google may think your site is slower.....but I can assure you that ours is not. I even took a poll of users, and 90% thought it faster and about 10% thought the same speed.

Note: I just looked and google is still using some old URL's - for 3 months ago! I must assume those exist someone on the internet (even though redirected) and good uses them in their calcs. It is by far the slowest page shown....

I think all of this stuff is why google calls the speed test a "Beta".

 

[Chris D]

I think it's worth employing caching as well. We've found XenForo fast, but we've found it even faster with caching enabled. We're using memcache, but I'm keen for our server monkey to try APC.

It makes a difference. It also makes a difference to the load on our server as well. We estimated that our server, as a result of caching, would probably handle an additional 1000 - 2000 visitors as a result of reduced load on the database and Apache.

 

[CTXMedia]

memcached and APC are different things and you can use both!

One of the key changes between vB and XF is the database engine type - vB uses MyISAM (and it's possible your MySQL server is setup/tuned with MyISAM use in mind) but XF uses InnoDB and not all servers are optimised for InnoDB out-of-the box so you could benefit from some tweaks there.

Try starting a thread in the server optimisation forum and post your my.cnf file settings, your http server type, OS, memory, etc. and details of any caching you have setup on your server and hopefully you'll get some good help with increasing your page loading speed.

Cheers,
Shaun

 

[lazer]

Hey, thanks guys. I don't think any perceived slow-down is server-side. Real-world page speeds are great and the YSlow and PageSpeed apps both bear this out...

I personally think it's due to the social networking scripts - Google waiting for them to finish loading...

 

[Adam Howard]

Hey, thanks guys. I don't think any perceived slow-down is server-side. Real-world page speeds are great and the YSlow and PageSpeed apps both bear this out...

I personally think it's due to the social networking scripts - Google waiting for them to finish loading...

Disable the Facebook share button and you'll save yourself between 1 - 10 seconds (sometimes more depending on the load on Facebook).

 

[lazer]

Disable the Facebook share button and you'll save yourself between 1 - 10 seconds (sometimes more depending on the load on Facebook).

Thanks. Is there a way to have it show just for logged in members - to stop the code from loading for bots and guests?

BTW, we made some changes (switched the JQuery from local to Google, changed the sprite.png to sprite.jpg) and our Pingdom pagetest went from 3.5s to 1.4s. We are also looking at leveraging browser caching, to shave a bit more time...

 

[Digital Doctor]

Disable the Facebook share button and you'll save yourself between 1 - 10 seconds (sometimes more depending on the load on Facebook).

Great tip.
It seems like that is what it is coming to.
Maybe Xenforo could load Facebook in a different method ? Just load it when it is clicked ? Seems like the method Xenforo uses to load it assumes it is going to be fast to load but that hasn't been the case.

 

[Chris D]

Thanks. Is there a way to have it show just for logged in members - to stop the code from loading for bots and guests?

Yep.

Wrap the Facebook code in share_page and share_page_sidebar in this:

<xen:if is="{$visitor.user_id}">
FACEBOOK CODE
</xen:if>

 

[lazer]

Yep.

Wrap the Facebook code in share_page and share_page_sidebar in this:

<xen:if is="{$visitor.user_id}">
FACEBOOK CODE
</xen:if>

Cheers

 

[Coop1979]

Thanks. Is there a way to have it show just for logged in members - to stop the code from loading for bots and guests?

BTW, we made some changes (switched the JQuery from local to Google, changed the sprite.png to sprite.jpg) and our Pingdom pagetest went from 3.5s to 1.4s. We are also looking at leveraging browser caching, to shave a bit more time...

What does the sprite.png to .jpg do?

 

[Coop1979]

Great tip.
It seems like that is what it is coming to.
Maybe Xenforo could load Facebook in a different method ? Just load it when it is clicked ? Seems like the method Xenforo uses to load it assumes it is going to be fast to load but that hasn't been the case.

I'm seeing that method used on many sites now. Either activate on click or on mouse over.

 

[Chris D]

A really good way of doing it is to replace the Facebook button with an image and link it like this:

https://www.facebook.com/sharer.php?u={$url}

So something like this basically:



Obviously it wouldn't have a counter, and technically this share feature is deprecated... but I doubt they'll take it away until the normal one works properly.

 

[Coop1979]

What about doing something like this? http://daily.siebler.eu/2011/04/facebook-like-button-asynchronous-loading-with-jquery/

 

[lazer]

What does the sprite.png to .jpg do?

It saved us around 40kb per page load.

 

[CTXMedia]

Do you use Apache? If so have you setup the Expires header for common file types?

 

[lazer]

Do you use Apache? If so have you setup the Expires header for common file types?

Not yet. Thanks Shaun, looking at that now...

BTW - wrapping the Facebook code for members resulted in another .26s of time off of the page load time.

 

[CTXMedia]

You can cache sessions - add this to your config.php:

$config['cache']['cacheSessions'] = true;

You could also shave a bit off the page loading by setting up a separate Apache virtual server (on a sub-domain but pointing at the same document root) to serve images/js from:

$config['externalDataUrl'] = 'http://subdomain.yoursite.com/data';
$config['javaScriptUrl'] = 'http://subdomain.yoursite.com/js';

(NB: In the ACP change the style image URL to this sub-domain too ... )

 

[CTXMedia]

Not yet. Thanks Shaun, looking at that now...

BTW - wrapping the Facebook code for members resulted in another .26s of time off of the page load time.

lol ... In the past I've spent weeks working on tweaks to shave off just a few parts of a ms - the members never noticed but I knew it was faster ...

There is one caveat with expires headers and that's images/avatars - your members may experience a delay in getting any new/replaced images and may need to do a hard browser refresh to see them - just so long as you're aware of this you can give them the CTRL + F5 advice.

 

[DBA]

Anyone else experienced this since the switch to XF?

You can see the spike we had back in January. Setting up xcache, removing social items, and cleaning up a few other things is what brought it back down.

It saved us around 40kb per page load.

Which sprite are you referring to? The UI sprite is only 4kb to start with.

http://xenforo.com/community/styles/default/xenforo/xenforo-ui-sprite.png