On small stores, this is pretty straightforward, but on larger stores, the effort to query all products (including all individual variations of products) can be significant.

I’ve recently been doing some work on performance-tuning the plugin. I started out with some really simple performance tracking outputting total time and memory usage at the end of the XML document. There were some quick wins as a result of that, but it didn’t really give me a feel for what was going on, or any big gains.

I’m normally a big fan of the Query Monitor plugin for reviewing what queries are run to generate a page, however in this instance it doesn’t help since there is no HTML output to the page for Query Monitor to add its results to. I needed something that wasn’t tied to logging its output to the generated page. I finally settled on Time-Stack by Joe Hoyle.

There are actually two things you need to get up and running – the timestack “app” (repo linked above), and the WordPress plugin that logs the data. Once you’ve got the app installed, and the WordPress plugin activated, then every request will be tracked, and visible in the app:

You get to see the total runtime, and memory usage, but more importantly you can drill into sections of the page request to see further information. You can right down to the actual queries being run and see exactly what’s going on. You can even instrument your code to markup useful sections for your profiling.

How did I get on? I’ll let the evidence speak for itself …

https://twitter.com/leewillis77/status/768863921763717120

Probably not for every site, or every occasion, but an awesome tool to have in the locker – thanks Joe!

The post WordPress performance tracking with Time-stack appeared first on Lee Willis.

When you set up a site in the Google Analytics web interface you get a copy and paste snippet of code which gets you going in no time. This snippet links your website to the account you’ve set up in Google Analytics, and tracks each page that’s viewed on your site.

For many people this is everything that’s needed.

However, Google Analytics can be used for so much more. You can use it to track anything you want using event tracking (user clicked on call-to-action button, user downloaded PDF etc.), or by providing richer context about page views (this was a logged in user etc.). Here’s some of the things I’ve used Google Analytics to track in past projects:

• On a site with a multi-field search (E.g. country, market sector, and keyword) track which of the fields were provided for each search, e.g. “Country Search”, “Country & market search”, “Keyword only search” etc.
• Track events according to which adverts users were shown
• Track custom events when people follow certain on-page nav elements

Historically I’ve used custom javascript to do this. Google provide good API documentation and the amount of code required isn’t normally significant.

Being familiar with what you can do with Google Analytics, on my new hill-walk blogging service I had a list of things I wanted to track. One of the things I wanted to track was selected external links. This can always be a bit hit and miss as there’s no guarantee that the tracking will fire before the browser navigates on to the clicked page.

So off I went to do a bit of research on the best way to handle the issue.

Tip: Even if you *know* how to solve a problem, have a quick check. Technology moves fast and there might be a better / easier way today than there was yesterday…

In my travels I came across the “autotrack” library by the Google Analytics team.

The library describes its capabilities (my emphasis):

Provides default tracking for the interactions most people care about, and it provides several convenience features (e.g. declarative event tracking) to make it easier than ever to understand how people are using your site.

The interesting bit for me was the nod to “declarative event tracking”. This basically means that you can have Google Analytics track events without writing and javascript, just by marking up your HTML. Here’s some example markup:

<a href="#" ga-on="click" ga-event-category="AdClick"
   ga-event-action="Ad category 1" ga-event-label="Seller one">
    <img src="https://placehold.it/100x100">
</a>

With the autotrack library installed, this will automatically take care of tracking a click when the link is clicked. The library takes care of using the best API for the visitors browser to maximise the chances of outbound links getting tracked.

Simples…

The even better news is that everything we’ve talked about here is just one of the features available (via the eventTracker plugin for autotrack). The library also includes a variety of other plugins covering tasks such as cleaning up tracked URLS, visibility tracking, media query tracking, and page visibility tracking plus more.

Next time you need custom analytics – be sure to check out the Autotrack library.

The post Autotrack for Google Analytics appeared first on Lee Willis.

The problem

It’s important to remember that:

1. Not everyone has broadband
2. Most web browsers don’t take advantage of the bandwidth available

GZIP Compression

If you’re developing a site in Joomla for example you often hear people suggesting “turn on compression” within Joomla. This option compresses the page content created by Joomla before sending it back to the browser in real-time.

While this is a great solution for some sites, there are significant issues with this approach for many sites. It’s important to realise that the HTML page is only 1 of the many requests needed to generate a webpage – you also need all of the images, CSS files, and JS.

Take for example a typical template from YOOtheme – a major Joomla theme provider. The actual HTML for March 2009 theme demo is 1 out of 31 requests, and just 7kB out of a total of 144 kB.

It’s worth noting that if the objective is to make your site “faster” then Joomla’s gzip may not be the best option. The downsides to this approach are:

• It only affects the size of the HTML page
• It does that by compressing the content on-fly
  • Cacheing aside – this can result in you compressing the file every time it is requested – adding a significant processor load to your server
  • The process of compressing the data adds a delay (However small) before your content can be sent
• It does nothing about the other files that make up the webpage
• It doesn’t maximise your bandwidth usage by minimising total number of requests

My Approach

For the sites that I run I use the following approach:

• Identify files that are included widely, but updated infrequently
• Consolidate multiple files into one (ie, create just one .js file for your site, and one .css file)
• Create a compressed version of these files alongside the original
• Use a bit of .htaccess magic to serve the compressed files to everyone who can deal with them.

This is a good solution for files which don’t change frequently (CSS, template images, JS includes etc.) This approach gives you the best of both worlds, compressed files, but low server CPU impact.

The HOWTO

To implement it simply create a compressed copy of the file(s) you want to compress. If you have shell access to your website files you can do:

This should leave you with your original uncompressed file, and a compressed variant with the suffix “gz”.

Now add the following to your .htaccess file:

Remember if you do change any of the uncompressed versions you’ll have to re-generate the compressed version otherwise clients that support gzip won’t see the changes.

There are some complications when using Joomla with Virtuemart (Since it insists on loading CSS/JS support files itself) – but that’s a topic for another day!

When we implemented this on SnugBaby it reduced the total number of files required from over 35 to 27, and the total download size from over 200k to 144k – would love to hear other’s experiences.

The post Gzip in Joomla – Tips for a faster website appeared first on Lee Willis.