I’m in the process, at the moment, of some interesting changes to the BMTG site. Instead of each show/concert page being individually written (with a few calls to scripts to display photos, etc) I’m creating a totally automated page generation system - simply tell it the show name, call the generator script and you get a show page out the other end. This includes the automatic detection of photos (just drag and drop a new photo into the appropriate folder and it then appears on the page) and the fetching of descriptions from the JPG data. Nice (if I do say so myself).

However, all of this has had an impact of server times. In the past I’ve not measured server times for performance monitoring, as they’ve been so insignificant. Now, I’m having to for the show pages. In fact the changes have pretty much negated recent performance improvements.

The next package, though, should help with this as I bring in some further performance improvements (including image caching and sorting out some shoddy MySQL programming of mine).

However, going forward (and I hate that expression), performance is something I will look at it with each package update.

After that there are packages due to SEO and Accessibility. So, they too will become part of the “standard” package check. Indeed, I have 4 things on my radar…

1. Accessibility
2. SEO
3. Security
4. Performance

Security, which will be tackled in the next package along with performance, is mainly around MySQL injection and the like - making the site as hacker-proof as possible.

It’s actually quite exciting as SEO and Accessibility is not something I’ve really concentrated on in the past, so I’m looking forward to the research and learning that will go with this.

Website performance is becoming a bit of a lost art. As more and more people get broadband, and that broadband gets quicker, then website owners spend less time looking at performance. After all, when you have a quick connection, why bother?

What these people forgot is that not everybody is on the same super-quick broadband. But, even if that’s not the case, we all know that we prefer a quick website over something slower. Then factor in the fact that many people have hosts that limit bandwidth, and the need for efficiencies becomes more apparent.

In this article, I’m going to be using my own websites for demonstration purposes, so I will be talking about HTML (or rather XHTML), PHP and MySQL. I’ve provided details in a past post about useful tools for reducing images in size, so don’t intend to cover this again.

The aim is simple… to look at performance and reduce loading times and bandwidth.

So, where to start.

Well, there are various tweaks we can do to Apache servers and PHP and MySQL installs to improve such things but, if like me, you’re getting hosting from a third party you’re unlikely to be able to do anything about this, so I’ll be concentrating on coding. However, changes to site configuration files – such as .htaccess – are usually allowed so I will include these.

The first thing to do, and excuse me if this sounds obvious, is to try and identify where the slowdown occurs. Is it the host server (possibly PHP or MySQL scripts) or client side (HTML, CSS, JavaScript, Images, etc.)?

When it comes to code, there are 3 basic rules on how we can improve this…

1. Compress (or, as it’s called elsewhere, “minify”) so that the files are smaller
2. Reduce by removing redundant code
3. Improve code so that is works more efficiently

PHP

How we code our PHP can make a difference in the speed. Here is a useful list of tips on how to code more efficiently in PHP…

http://reinholdweber.com/?p=3

This is a pretty good list and is pretty much all I can say on the subject, other than – and this applies to all other coding – to look through your code and try and remove redundancy.

MySQL

The general advise is..

1. Do as little SQL processing as possible. Reduce down what the SELECT fetches, if you can

2. One of the biggest things is select *. If you don’t need all the columns, only ask for the ones you need. If you don’t need all the rows, ask for the ones you need, but ask in a way that exploits the indexes already there.

3. Use Indexes wherever possible

And whilst I’m at it, don’t forget to look at SQL Injection. It won’t help with speed, but is essential for site security.

HTML/XHTML

Other than some of the tips mentioned previously (reduce code where appropriate, etc), there is no magic bullet for this one. Compression programs give very little benefit (reducing code by a couple of percent). There are some that make huge improvements but these come with decompression routines and can slow down the display of pages, as they are decompressed browser-side.

Additionally, many compression routines will strip out characters that will then mean the page can’t be validated without errors.

JavaScript

Unlike HTML/XHTML, I’ve found compression of JavaScript to be beneficial. My particular favourite is the one provided on the Creativyst website. The Litebox script, for example, will compress to 67% of its original size, saving a third of the total size. Unlike other sites and tools, I’ve never found the Creativyst version to break a script.

CSS

Like JavaScript, compression can help with CSS. Be wary, though, of various “hacks” that are used in CSS for cross-browser compatibility. Compression may break these.

Therefore, I put any such “hacks” in a separate CSS file, which I don’t then compress.

My recommendation is the online compressor at CSSdrive, which can provide some impressive results (a 28% saving on the CSS that I tried). Using this compresses the main stylesheet for the BMTG website down to 72% of its original size – a saving of 28% on pretty much each page.

I’d recommend you set the following options…

Having said that, I’ve achieved even greater compression using manual search/replaces (but doing it for each stylesheet every time I change them is laborious). One day I might write a program to do it for me!

.HTACCESS

There are two options, which can be set via your .htaccess file, which will help further.

1. GZIP – assuming your host server has GZIP installed, this will activate this compression functionality
2. Far_future_expires – this adds an “expires” header to your files

Both of these options should be used carefully and fully tested. The latter option, Far_future_expires, should be of particularly note. This caches JS and CSS the first time a user visits. It’s only then an advantage when they return again. Bear in mind that if you then change of these files you’ll need to give them a different name, so document control will be useful here.

Both of these, plus a minify option, is also available via a script named PHP_SPEEDY. I will be covering this in a second article, however.

Server Calls

The number of calls you make to the server for files to make up a resultant web page can have a big impact on load time. Combining images, stylesheets, etc, is the best solution.

Now, you can do this manually, or there’s a rather useful and clever script for automating this on the takaz blog.

Yahoo! Exceptional Performance

Yahoo! Have a section of their Developer Network titled Exceptional Performance. It states that their “team evangelizes best practices for improving web performance”.

First of all, I’d recommend their list of performance rules. This includes full explanations of each recommendation.

Secondly, and to back this up, they’ve introduced a Firefox plugin that will check a website for performance issues, using their aforementioned rules. This is named Yslow and requires the Firebug developer plugin as well.

Now, some of these recommendations are going to be for large-scale commercial sites, including having a number of interspersed host servers, etc., so I suspect it’s doubtful that anyone with a small scale site is going to be able to achieve a high rating.

If you’ve found this article of interest, then a PDF version is available for download below. I’m happy for you to use and distribute this, but please don’t edit it, sell it or generally be beastly.

improving-website-performance.pdf

Over the last few weeks I’ve been looking at improving the eCommerce facilities on the BMTG website.

Up until now I’ve handled the handled the ticket availability via a combination of PHP and MySQL. The shopping basket and checkout has then been handled by PayPal. To add some more flexibility, though, I’ve been taking over the shopping basket. The coding was a little complicated but it’s done. I can now track multiple tickets in a basket, with options to change quantities and delete items from the basket. All well and good.

The next bit is to pass the basket entries to PayPal for final payment.

Oh lord.

The main PayPal site has “walk through” screens on how to add the code. But stuff is missing - but can be found in a 100+ downloadable PDF manual. Add to that the code they give you includes a broken link to a PayPal image.

So, now, I need to find a replacement “Checkout” graphic from PayPal. Could I find one. Could I heck. However, there was a news story about PayPal updating their graphics so I followed that and found a list of “before” and “after” images. That told me that PayPal generated images - such as the ones provided in the example code - would update automatically. The other option was to download replacement images and host them yourself. This wasn’t my preferred option, but I went for it anyway. Guess what? Yes, clicking on the link to download the image showed me the code that was required to host it from the PayPal site - exactly what I was after. But in no way obvious.

And that’s what I’ve found about the PayPal site in general - nothing is where you’d expect it to be and everything needs a good deal of searching to find.

Which is why most of the help can be found at the PayPal Developer Community - a group of official PayPal forums that I only came across via a Google search.

These forums mentioned that I could use the PayPal Sandbox for testing purposes. But could I find a link? No. A search on Google naturally lead me to a completely different site - PayPal Developer Central. And don’t even get me started on how complicated the Sandbox is to use…

So right now I’m frustrated to hell. My coding of the PayPal interface has barely started as I’ve spent all my time desperately trying to find answers to what I think are basic questions.

And after that… I’ve going to add Google Checkout as a second payment option. God help me.

I had an email today from a good friend, asking for recommendations about setting up a personal domain name. I get asked this quite a lot, so I thought I’d Blog the answer for future. You know it makes sense.

Right, if you’re simply after a domain name for your email - i.e. having a nice personal email address such as joe.bloggs@artiss.co.uk - then this is easy. I use 1&1 who can supply them for £2.99 for 2 years. This gives you the domain name, but no email facility. You’ll need to keep your existing email but use the 1&1 Control Panel to divert your new domain name to your existing email address.

That means if you move ISP and therefore ISP-based email address, then you simply change the forwarding, and your friends don’t need to know anything different - they still use your personal email address.

Not only that but you can set up different diversions for different email addresses.

The down-side to this is that when you reply from most email account it will use your “proper” email address as the “from”. In other words, if you’re using an ISP supplied email address, it will use that when you reply. Google Mail, which I highly recommend, isn’t ISP dependant and will allow you to reply to emails using your personal email addresses.

Now, that’s the email covered. What if you want a domain name for a website as well? Well, the 1&1 offering will allow you to divert the matching website address to anywhere else. So again, you can divert, say, artiss.co.uk, to that free space given to you by your ISP. But, again, there’s a downside. The forwarding works by creating a frame with your website inside it. That means the URL doesn’t change as you move around pages, and makes providing specific links to page rather difficult. Now there is a way around this by pointing the “name servers” directly to the web space. However, this is dependant on both your ISP and domain name provider allowing this. It’s also a bit of a technical jungle at times.

So, if you want a website and want it to look all cool, froody and sophisticated, I’d suggest you look at getting a host - i.e. a company that can provide the domain name and webspace and link them together automatically. The additional upside of this is that they’re likely to provide a better quality service than the free offerings from your ISP.

Streamline.net provide a “power” option for £47.98 for 2 years. This includes your domain name, email forwarding, 750MB of space and even PHP & MySQL if that’s your bag.

UPDATE: A Blog reader has kindly pointed me to Microsoft Office Live. They provide a FREE small business package which includes email, 500MB of space and a domain name. It looks as if the email is their own mail service and you may have to use their own designer to create the website rather than upload your own. Plus I suspect it won’t allow PHP, MySQL, etc. So limitations you should be aware of… BUT it’s free, so worthy of investigation.

No, not this time.

But I’ve noticed that I mentioned some time ago about using new Captcha software. Well, after some head scratching (explained in a bit) I’ve got it up and working on the BMTG site.

Scratching, because it refused to work. In the end it turned out that another piece of code was interfering with it. I used the least elegant solution to the problem (rather than getting them to work in harmony, I simply turned the other code off on the pages that needed the captcha) and all is well.

It might be worth taking a while to peruse the BMTG site whilst you’re there as I’ve recently made LOTS of changes to it. These include…

• Removed a menu system that I was trialling (it had drop-down sub-options) and have instead implemented a simple single menu, but where options lead to screens with further sub-options on.
• Good use of iconography on screens
• The front page is now delivered via a back-end MySQL database
• Top-of-page adverts are also now delivered from a MySQL database
• Various page tidies
• Completely re-validated all the pages, checked links, checked across browsers, etc, etc.

Not bad. Even if I do say so myself!