Skip Navigation

Everyone loves faster sites. Speed is important to human visitors as well as search engines, and it’s certainly worth spending time on optimizing it. 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 visitor goes to your site, they need to receive a response in the form of a page.

Page Caching

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 and, 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.

Minify: Pack static CSS and Javascript files into fewer files. This way, instead of loading dozens of tiny CSS and JS files, visitors will load fewer and larger files. If you also use a CDN, this doesn’t have an effect on your server, but can greatly enhance the browsing experience by first-time visitors.

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.

Debug Queries output

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 theme loads translations 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.

Auto ID-Adjust

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 includes 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.

You should enable this option for better performance. Do this by enabling the Adjust IDs for multilingual functionality option on the WPMLLanguages page.

Auto ID adjustment control

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.

12 Responses to “Can Your Site Run Faster?”

  1. Hello, I have problems with my website that is too slow, so I made a scan to see which plugin makes the website slow and unfortunatley is mplt multilingual cms, I had already disabled the ID-adjust, here the result of the scan:

    P3 (Plugin Performance Profiler) – 0.0027 sec – 0.30%
    Akismet – 0.0517 sec – 5.72%
    Ecwid Shopping Cart – 0.0056 sec – 0.62%
    Maintenance Mode – 0.0017 sec – 0.19%
    Seo Image – 0.0010 sec – 0.11%
    Sitepress Multilingual Cms – 0.7663 sec – 84.69%
    W3 Total Cache – 0.0100 sec – 1.11%
    Widget Logic – 0.0146 sec – 1.62%
    Wordpress Seo – 0.0235 sec – 2.60%
    Wpml Cms Nav – 0.0207 sec – 2.29%
    Wpml Media – 0.0069 sec – 0.76%

  2. Disabling Auto ID-Adjust just changed my page-creation time from 2.1 seconds to 1.0 seconds. Thanks for the tip.

  3. this is what wpengine suggested for my site slow performance due to your plugin:

    It seems like you’re catching the server when it doesn’t have a version of the site cached. The first time you view the site after the cache has expired it will need to hit the server to generate the page. Your site has 1435 queries ran on each (un-cached) page load. This is way too many. The average is around 100, and optimized sites run around 50. All of these queries are ran before the data is sent and increase the first byte time by a lot. But when the page is cached the server just sends the page from memory.

    The main plugin is


    This plugin generates 853 queries.

    I suggest contacting WPML. On this page ( it says

    “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.”

    And that is exactly what we’re seeing.

    • Please have another look at the full recommendations in this blog post. There are different operating modes that significantly influence the number of queries the site needs.

      Have you tried checking the different settings, which are described in this blog post? There is also a suggestion to use Debug Queries and get a log of the queries. You only need to run it once, keep that log and deactivate Debug Queries. It will show you, and us, what your site is doing and hint about what can be optimized.

      If your site takes 1435 queries to load and WPML takes 853, it’s a pretty bit number. You should really get a log of these queries.

    • im not a technician, and tired to have problems with plugins… i have uninstalled WPML cause i cant afford waiting my time testing all day and digging into complex questions… if i pay for something, i expect it to work! i had everything ready for 2 languages, including gravityforms, woocommerce, etc. ready for WPML. I used wpengine for his reputation, but the cant solve the issues… really tired.

  4. We are experiencing problems with a language:

    Catalan 611 queries in 3 seconds
    Spanish 11162 queries in 44 seconds

    How can be the problem?

    • Did you check the output of Debug Queries to see what it’s doing? Just the number of queries is important, but the information is in the queries log. You should open a support thread about it in our technical forum, where our staff can carefully look at this log and see what’s repeating.

  5. Hello, I just profiled my WordPress site because the client is complaining, and noticed that your very expensive and unoptimized plugin is doing something like 600 queries per each page and uses more than 80% of the time spent by all the plugins.

    You should take performance optimization more seriously.

    • We’re actually very interested in improving performance. WPML 3.1, going out in a few days, may significantly improve your site’s performance. We saw a decrease of up to 60% in the CPU time for big sites.

      • Of course. Any update we make is compatible with existing sites. The changes we did were all to internal functions, reusing loaded information, refactoring complex procedures and clearing old issues. Let’s see what are the results that you’re getting.