Article

|

I decided to write a short follow up from the post from last week about the performance of this site, but framed more as a “how to quickly speed up my site”. Even if you can’t or don’t want to go down the line of changing themes (or writing your own), profiling plugins to find the fastest options, or changing hosting company, by spending 5 minutes installing these 3 plugins you can get a significant performance boost.

1. Squish those images

Images generally make up the bulk of the download weight of a site, especially in badly behaved themes. While WordPress does compress the smaller versions it creates when you upload a new one, and got better at it in version 4.5, a bit more can go a long way to speeding things up.

There are plenty of plugins to do this, both premium and free, and they fall into two camps technically – those who offload the processing to another server, and those that do it on your server. The big reason for using the external server type is to lower the resource use on yours or because yours doesn’t have the required libraries (normally cheap shared hosting). However most decent hosts will have no problems, and I prefer to keep things under my control when I can, so I’ve chosen to use Ewww Image Optimizer. Ewww has come out ahead in various comparisons but I’ll leave it to you to choose from the competition. Once you’ve installed it, any new images uploaded will be automatically optimised, both the full size originals and the smaller ones. There’s only one more step – head to Media -> Bulk Optimize and click on Start Optimizing. This will scan the media library and optimise everything previously uploaded. If your theme comes with built in images, you can also click Scan and Optimize which will catch those too.

Images squished, quick and easy – on to step 2.

2. Cache money business (to quote Mark Jacquith)

WordPress is built on PHP and a MySQL database. While the browser needs to be sent HTML files, on the server PHP is used to generate that HTML by reading information from the database. All this takes time, and also resources. When you have more concurrent visitors then the server uses more resources, which causes it to slow down, and eventually become unable to serve them. One way around this is to buy a bigger server, but a cheaper and easier solution exists – caching. Caching is the process of grabbing the HTML that PHP generates, and saving it for a set time. Instead of each visitor going to PHP and the database to generate the HMTL, it is sent to them directly saving both time and load on the server. After a chosen time, or a trigger like publishing a new post, the saved HTML is thrown away and a fresh copy created. This ensures visitors get an up to date version. The exact impact will depend on your site and server, but as an illustration I was running a load test on a client server last month: without caching the site became unresponsive after 36 concurrent visitors, with caching it was still going strong at 1500! NB – the site in question has some very complex pages making large numbers of database queries; also, these ‘users’ all doing indentical actions at exactly the same moments which would equate to a larger number of real-world users.

This was achieved using the popular free plugin WP Super Cache. Caching is more complicated than image optimisation, but WP Super Cache strikes a good balance between its simplicity and power. Even just installing the plugin and using the default settings on the Easy screen will give your site a huge boost. But it’s worth having a read of the Advanced and Preload tabs to refine things – the settings all have good inline documentation. For most turning on all the Recommended items on the Advanced screen is a good start, as well as reviewing the Expiry Time & Garbage Collection values (the text under the setting box has good examples).

Your site will now be both quicker and able to cope with more visitors. But there’s one more thing to do.

3. Minify, compress and concatenate HTML, CSS and JavaScript

Images squished, HTML pre-generated – but there’s also CSS and JavaScript being sent to users. Have a look at your site using View Source in your browser of choice. Since most themes are fairly badly behaved you’ll likely see multiple CSS and JavaScript files relating to the theme, and on top of that there will probably be ones added by plugins. Each separate file is both adding bytes to be downloaded, and also a connection that has to be opened from the browser to the server which takes time.

The solution to this threefold:

  • minification – remove spaces and rewrite files to shorten the length of them.
  • concatenation – join files together so that fewer have to be downloaded.
  • compression – server the files from the server with file compression to make them smaller, and send special headers to tell the browser to cache them locally to save downloading them again.

One plugin can so all this for us – Autoptimize. Install, activate, and turn on the 3 basic options to optimise HMTL, CSS and JavaScript. This one does need a bit more care – there is potential to break JavaScript code in particular. I’d recommend giving your site a good test after this basic activation to check everything is ok. If so, feel free to enable the Advanced Settings and tweak it to squeeze a bit more performance out – it’s all well documented. One advanced setting in particular to look at is inlining CSS. If your theme is quite a light one, inlining it all is best. If your theme is more complex, inlining ‘above the fold’ CSS will drastically improve the apparent loading speed of your site. This is because the browser will have enough information to render the visible area of the site even while it is still loading the rest.

 

5 Minutes, that all it will take – probably less time than it took to read this ramble – and you will have netted a substantial increase in performance. If you’re still after more speed things get a bit more complex – a faster server / host or a better theme would be the next on my list. Beyond that there’s object caching, server caching, CDNs, server optimisation, code optimisation… It goes on, but the 3 simple steps here should be all that 90% of sites need. To take things further I’d highly recommend reading this detailed article on WordPress performance and bottlenecks at Smashing Mag.

Article

|

One of the things we do at Helpful Technology is provide digital skills training. As part of that we have a sandboxed Twitter style social network platform that allows users to get used to the medium and practice in a safe environment.

I’ve been re-building this system recently, and one feature we wanted to add was the automatic linking of usernames and hashtags. This is fairly simple to do with a bit of RegEx in PHP – and on WordPress you can just attach it to the filter called the_content to process all text before it is output and insert links as needed. The code could be put in a plugin, but here it’s written so you can just drop it in to your functions.php.

If you’re wondering about the ‘weird’ \p{X} statements – that’s using PHP’s unicode character properties to ensure all languages are matched.

Article

|

Updated 4/6/15 – now with added key/salt generation

When deploying a new WordPress site, there are two (potentially) needlessly time-consuming steps – logging in to MySQL to setup a new database and user, and then copying the WordPress files to the directory. The script below lets you do this in one step, pass in your database and basic WordPress settings, and it will configure MySQL and directly download WordPress to the server. A key benefit of this over a phpMyAdmin + FTP approach is that it will work over even ropey internet connections as the work is all done on the server itself.

A more advanced approach is to build a setup script based on WP-CLI, which allows the most customisation, but also needs more setup work and control over the server. If you always install the same plugins and themes – definitely look in to this.

How to use the script:

  1. SSH in to your server and navigate to the desired install directory (e.g. /var/www/domain/)
  2. Paste all of the following in to terminal and hit Return:
    curl -L -o 'wp.sh' https://gist.githubusercontent.com/emirpprime/37ef1f355ec5a7ecbb8f/raw/019acd595af695498acdf7b497e32ca0ebfb87f0/wp.sh && bash wp.sh
  3. Enter your details when prompted
  4. (Exit / close the SSH connection, your done here)
  5. Navigate to your new site in a web browser to complete the normal WordPress installation steps

Here’s the raw script so you can see what it’s doing – feel free to Fork it or suggest improvements:

Article

|

20130122-220026.jpgLately I’ve been working with the conservation group in a local village. They were awarded Big Lottery funding for promoting and growing the group, and decided a website was an ideal partner to traditional leaflets. A local designer was contracted to design the print media and I built the web site around the identity he created. It will be launching over the next two weeks but here’s a sneak peak.
Continue reading →

Article

|

Background

WordPress offers quite a friendly hybrid WYSIWYG / HTML editor that makes publishing easy even for those with no HTML experience. One of the ways it accomplishes this is through a function called wpautop. This runs on the_content as the page is drawn to insert <p> and <br/> tags as needed. By inserting them dynamically like this it prevents code creeping in to the editor and leading to potential confusion / corruption. However, it can sometimes lead to unexpected results – especially when combined with shortcodes.
Continue reading →

Article

|

Prior to WordPress 3.1 you could only use one meta_key : meta_value : meta_compare in a query_posts. This meant that you could, for example, get the custom post type (cpt) product, filter it to get only those products that have a price >= 100. However you could not then orderby department ASC. Neither could you get the products with a price over 100 and colour green.
Now you can do advanced CPT filtering in WordPress since 3.1 with meta_query. There’s a nice intro post to this which I won’t repeat, but here is the code I used last week as an example:
Continue reading →

Article

|

There seems to be a problem/oversight in WordPress at the moment (afaik).

You can generate Custom Post Types (CTP) easily enough, and have them visible on any page using templates/the loop, but when you click through to a single CTP WordPress assigns the current_page_parent to the default posts page. For many that will mean highlighting the News or Blog pages of their site.
After a lot of searching, and finding lots of people asking the same question but no solutions (except hacks), I found a reply by jonny_williams to a post about this on the wordpress.org/support forum. His solution at least runs from functions.php (and so before the content is displayed) rather than being accomplished through javascript like many others.

After a couple of modifications I settled on this:

function fix_portfolio_parent($menu){
	global $post;
	if ( 'projects' == get_post_type() )
	{
		$menu = str_replace( 'current_page_parent', '', $menu ); // remove all current_page_parent classes
		$menu = str_replace( 'menu-item-XXX', 'current_page_parent menu-item-XXX', $menu ); // add the current_page_parent class to the page you want
	}
	return $menu;
}
add_filter( 'nav_menu_css_class', 'fix_portfolio_parent', 0 );

Just replace the XXX with the number of the parent page you want to highlight, and 'projects' with the name of your CTP. As always, make sure you function name is unique and relevant. If you have multiple CTPs, either duplicate this for each, or extend the if (I haven’t looked at the performance differences of these options).

Article

|

I’m a big fan of WordPress – it’s both easy to use as an author and easy to develop for. There are also a huge amount of free (and paid) plugins to extend the core functionality.
Unfortunately there is a downside – most plugins do not conditionally load their files only on pages that call them. It is all to easy to end up with every page loading a string of Javascript and CSS files slowing the site to a crawl, when they are only actually required on specific pages.

I’m going to show 2 quick examples of how to use the functions.php file in your theme to only load the scripts for a plugin on a specific page using deregister and remove_filter, which are built into WordPress.
Continue reading →