Everyone loves faster sites. Speed is important to human visitors as well as search engines and it’s certainly worth spending time on, to optimize. Here are a few tips that can make your multilingual site faster.
Speed and performance optimization are an endless tunnel. No matter where you are, there’s always room for improvement. There are the simple and trivial optimization steps and the more advanced ones. The results you’ll get are very dependent on the amount of effort you’re willing to put in.
First, it’s important to understand the basics.
When a visitors go to your site, they need to receive a response, in the form of a page.
Your first line of defense is page caching. Page caching will return the response from the disk, or from memory without asking WordPress to prepare it. Obviously, using page caching is the one most important step towards a fast site.
In our sites, we use either WP Super Cache or W3TC.
- WP Super Cache – easier to configure and harder to go wrong. We use that on low-traffic sites, where we just need page caching to avoid WordPress from processing each and every request.
- W3TC – a complete package for speed optimization, requiring reasonable understanding of what you’re doing. When used correctly, W3TC can perform every optimization possible for your site. However, you need to understand what you’re doing and it’s possible to crash your site when you don’t. We use W3TC on wpml.org and wp-types.com, which are relatively high-traffic sites and speed is critical. We use every single feature in W3TC to squeeze out all the performance we can.
If you’re interested in more details, check out my older, but still relevant. post about WPML and W3TC.
CDN, Minify, Object Caching and APC
Besides the basic page caching, there are a number of techniques to further improve your site’s performance. Here are the popular ones:
CDN (Content Delivery Network): Your static files will be hosted on other servers, closer to visitors. Instead of hitting your server to get static content, this content will go directly from the CDN. There are different CDN providers, such as MaxCDN and Amazon. On our sites, we use Amazon S3 + CloudFront.
Object Cache: Stores data units that take long to compute. You can read more about that in WordPress codex.
PHP Opcode Cache: Pre-compiles PHP code, so that it doesn’t have to be interpreted from scratch for every page load.
There are plugins that implement each of these operations. W3TC implements them all too.
Specific Optimization for Your Site
Page caching, CDN and Object Caching will give your site the initial speed boost. They prevent WordPress from executing, or from executing from scratch, for every single request. However, even with all the caching in the world, sometimes, WordPress does need to produce content. Then, if it takes 40 seconds for a page to compute, it’s not going to fly.
To optimize the performance of page-rendering by WordPress, you must first understand where most of the time is spent.
I recommend to start with a plugin called Debug Queries. Enable it and look at your site’s footer. You’ll see exactly how much time PHP processing and database processing took. You’ll also get a breakdown of the individual queries that make up each page.
I cannot stress enough how important doing this is for your site. Without checking what your site does now, there’s no way to tell where there’s waste and what needs improving.
You should look for things like:
- The same query running over and over again.
- A series of queries loading individual items instead of a single query loading the entire array
- Joins on huge tables, which take long to perform
- Queries that search by columns that have no index, or text searches
All these things will surely slow your site and can be avoided. Many times, you’ll see them happening in conjunction, with a single solution to fix a few problems together.
Often, in order to really fix these issues, someone is going to have to work hard on the site’s coding. In other cases, different usage of widgets or theme options can greatly reduce the database load and increase the site’s speed.
Using WPML Better
WPML has several features that help you manage your site, but also require database resources to run.
String Translation Features
WPML’s String Translation module is fairly optimized and should not slow your site, just as long as you know what you’re telling it to do.
It already comes with a caching engine, which will load entire contexts in a single query. When a plugin, or your theme, loads translation using a GetText call, or directly using WPML’s icl_t function, WPML will load all the translations for that context. This means that other strings that belong to that plugin or theme are already in memory. This is similar to the way GNU GetText operates.
The String Translation module includes several features which help you locate and register strings for translation. To work, they require the database. These features are not intended for normal production usage and only affect performance for logged-in users.
They are explained in the String Translation performance FAQ.
WPML creates different posts for different languages. Many themes refer to specific posts and want to load them from the database. They don’t know that you’re using WPML, so they don’t care about the same page appearing on different posts for different languages.
To allow you to use your themes, without any PHP edits, WPML include a handy feature that automatically converts IDs to those in the current language. If your theme attempts to load a page in English, but the site is now displaying in French, WPML will deliver the French page instead of the English page.
To do this, WPML needs to query the database, look for the French translation and deliver this instead. This operation requires database access.
You can control how this works by enabling and disabling the feature called Adjust IDs for multilingual functionality, under WPML->Languages.
For smaller and less busy sites, it might not be worth the trouble. However, for busy and performance-critical sites, we recommend to disable this option and do the ID adjustments yourself.
Use WPML’s icl_object_id function to do this manually, thereby saving many accesses on places where the ID conversion is not really required (but WPML cannot tell that). On this site, we handle ID conversion manually. It’s only needed in a handful of places.
Separate WPML’s Impact
While there are many things that you can optimize, which are not all related with WPML, we want to know that we’ve done our job right.
Grab a copy of your database and run it locally. Try with and without WPML.
If you see a huge change when you enable WPML, we want to know about it. By huge, I mean that it might take 70 queries without WPML and 900 queries with it.
You can post about your experience here, or in our technical forum (better). If we need your database dump to reproduce this situation, we’ll email you to get it privately.