In the context of globalization, access to multilingual content has become an essential element for many online platforms, including WordPress. Quite often, website owners find themselves needing to use translated content to reach a wider audience. WordPress offers a variety of plugins for this purpose, such as WPML, a powerful tool that allows you to manage translations in multiple languages; Polylang, which facilitates the addition of translations of content in different languages; Translate Press, an intuitive solution for direct translation on the page; And MultilingualPress, which allows you to link content structures between multilingual sites. However, even though these plugins can greatly simplify the management of translations, it has been found that using the translation functions can significantly reduce site performance. This situation has prompted developers and the WordPress community to look for solutions that maintain translation versatility without compromising site speed and efficiency.
After a thorough performance analysis earlier this year, which showed that translations can affect server response times, WordPress contributors are proposing half a dozen technical solutions for you to consider to improve performance for ~56% of WordPress sites using translations.
Initial evaluations have shown that the median load time for a localized site can be up to 50% slower than non-localized sites, depending on the themes and plugins used.
said Pascal Birchler, developer of the Google-sponsored WordPress core.
Based on the recent threads on GitHub, the Performance team narrowed it down to an updated list of six possible top contenders for speeding up sites with translations, including the pros and cons of each:
- Solution A: Use a different file format
- Solution B: Gettext native extension
- Solution C: Translation Cache
- Solution D: Translation calls evaluated lazily
- Solution E: Optimize/Rewrite the existing MO parser
- Solution F: Splitting Translation Files Localized WordPress sites currently download .po and .mo files that contain translations, but the first proposed solution suggests storing translations in .php files and using the .mo file as a backup, as Birchler proposes that loading and running another PHP file would be a faster approach.
A proof of concept on GitHub a swissspidy/wp-php-translation-files and swissspidy/ginger-mo.
Looking at all these factors, it appears that a revamped translation parser (solution E) could bring the most significant improvements to all localized WordPress sites. Especially when combined with a new PHP translation file format (solution A), which Ginger MO supports, the i18n overhead becomes negligible. Of course, the same risks associated with introducing a new format apply.
Besides that, a revamped i18n library like Ginger MO could also be combined with other solutions like caching or dynamic loading of MO to achieve further improvements. However, these avenues have yet to be explored.
Birchler said.
The team Performance Lab it plans to further test these ideas on a larger scale through its Performance Lab feature project after gathering feedback from the wider community. August 6, 2023 is the deadline to leave feedback on the proposal, which includes benchmarks and further details from the analysis.
Finally, after a decade and with the establishment of the Performance Lab, AUTOMATTIC is starting to painstakingly focus on all the performance issues that had been overlooked in the past. The renewed attention to performance is driving the company towards the adoption of innovative strategies and targeted technical solutions. It is hoped that, within the next two years, native optimization systems will also be integrated, taking the world's most used CMS to new heights. These developments represent a promising sign for website owners and developers, with the prospect of a WordPress that is faster, more efficient and capable of responding even better to the needs of a global audience.