• Resolved Keith

    (@keithkhl)


    This is more a review than a Q/A posting.

    When I first saw the discussion in 6.4 development that WP dev team finally catches the fact that foreign language WP is way slower than English version, I had some level of hope. Then, among many options to deal with it, when conversion from .mo to .php was proposed, I really hoped that it would change my websites’ performance.

    I’ve used Performant Translations for about 3 months, before/after WP 6.4 release.

    This week, due to debugging issues, I changed my website’s language to English. I can feel that everything got sped up at least 20%, and sometimes a lot more than that. When it was in non-English version, for one of the subsites that has over 100MB post and post_meta tables, respectively, admin’s post list loading took me about 5 seconds, after Redis Object Cache. After changing the site language to English, it takes less than 4 seconds, mostly around 3 seconds. Lighter subsites are more dramatic. For subsites that required 3~4 seconds now need only 2 seconds.

    I am glad that Performant Translations’ key function will be incorporated to coming WP 6.5 in late March 2024, but if there isn’t any significant change of WP’s multi-language structure, most non-English websites should still suffer from translation related dragging issues.

    Though the idea to change .mo to .php is great, the experience was not really material. I will stick to English version WP for all my services from now on, until I hear otherwise.

    I speak multiple languages and most non-English website owners usually do not regards WP as a reasonable alternative, if they have local language based solution. After months of testing on my sites, I can now confirm that they are right and WP is still for English speakers. Not sure how long it will take to say otherwise, but I am now certain that .mo to .php is not a solution.

    The reason I still post this one to Q/A forum is because there might be a configuration setting that I have missed. I thought it is just install, activate, and forget type plugin. Plz let me know if it is not.

    • This topic was modified 10 months, 1 week ago by Keith.
Viewing 15 replies - 1 through 15 (of 18 total)
  • Plugin Author Pascal Birchler

    (@swissspidy)

    Hi there,

    Thank you for taking the time to open a new topic here to share your experience!

    It sounds like you are running a larger site, and maybe even one with multiple languages. I would like to learn more about it so I can better assess the performance impact you may gain from this solution.

    Usually the more you have going on on a site, the less of an impact translation has on the overall load time. But that depends also on whether you are using any multilingual plugins etc.

    If you think you might have missed a configuration setting or so, tools like Query Monitor are easy ways to see if and how translations are loaded. That will definitely provide additional insights. Also, check your PHP configuration to see whether OPcache is enabled and working, that gives an additional boost.

    If you are unsure about the whole .mo vs. .php difference, I highly recommend reading the in-depth i18n performance analysis that was published last year. tl;dr: PHP translation files are almost as fast as not using any translations at all, and faster than any other mechanism.

    And if none of that helps, well, it sounds like you are happy with just using WordPress in English, which is totally fine as well 🙂

    Thread Starter Keith

    (@keithkhl)

    I rely on above plugin for OPcache control, and I usually have around 80~90% hit ratio. Query monitor has so far not given me anything material, because most queries are nearly 0.1~0.2s.

    Things that bother me a lot is LCP, but if I am not mistaken, it is for front-end, and it should fall to image caching issues. Many plugins that I have to rely on are another factor for the sluggish load time, but that’s something I have to compromise with.

    ‘PHP files are the fastest on PHP platform’ did attract my attention, and that’s why I’ve been testing on it for months. Since I do not have any on-site translation plugins (like WPML), I thought it should mostly affect on admin menus, so the impact will mostly be on admin pages. But having seen 20~40% reduced load time for key admin pages w/ English as a default language, I doubt .mo to .php conversion can make any noticable changes.

    I do need to keep my own language in the website, but seeing ‘Needs Improvements’ and ‘Poor’ in Google Search Console tears my heart apart. Until I can find any better solution, I will stick to English version.

    I hope integration to WP core from ver 6.5 can make any changes in performance.

    • This reply was modified 10 months ago by Keith.
    Thread Starter Keith

    (@keithkhl)

    as strange as it sounds, after deactivating performant translations, a number of malfunctions are disappeared. I had some plugins not working properly (Kadence Block Pro, Elastic Press, One User Avatar, and a few more), and WP ‘s default site health, user edit functions did not work.

    I guess the .mo to .php is not compatible with some plugins. This could be the key reason that I have not been able to witness any performance upgrade, or reason to see performance downgrade from time to time.

    Since WP 6.5 is going to incorporate this function natively, I do hope that other plugins can keep up.

    Plugin Author Pascal Birchler

    (@swissspidy)

    Apologies for my late response, I missed you earlier reply.

    Query monitor has so far not given me anything material,

    What I meant with Query Monitor is specifically that it has a “Languages” tab where it shows you exactly which translations were loaded (or not found). Here’s a screenshot:

    as strange as it sounds, after deactivating performant translations, a number of malfunctions are disappeared. I had some plugins not working properly (Kadence Block Pro, Elastic Press, One User Avatar, and a few more), and WP ‘s default site health, user edit functions did not work.

    What do you mean by malfunctions? Straight out broken plugins, or just missing translations?

    I just installed One User Avatar + Performant Translations and it works just fine, and Site Health works fine too. Both are correctly translated.

    Performant Translations does nothing beyond changing which translations are loaded. I don’t see how it would affect functionality of other plugins.

    I’d be more than happy to dig into this and figure out what’s going on. Could you perhaps share some screenshot or video, or perhaps even your Site Health info (Tools -> Site Health -> Info -> Copy to clipboard)? Anything would help as a starting point.

    Thread Starter Keith

    (@keithkhl)

    those pages are not loaded. For example, when Performant Translations together with aforementioned plugins are activated, if site language is non-English, I can’t open Site Health and User Edit. For both cases, the page is loaded with blank white, and in the browser’s top panel, instead of site title (for this forum page, it is “Not as great as advertised | WordPress…), I could only see the webpage’s url, like xxx.com/wp-admin/site-health.php. From time to time, I can see Site Health is updated on admin dashboard, so I assume the function is working, but not accessible when I click it by Tools -> Site Health. In other words, the function is working at the back, but the .php page is not loaded properly.

    The same issue occurred to Users -> All Users -> ‘Edit’ user profiles. The user edit page is not loaded. If I wanted to change user’s name, role, password…, I had to directly access DB.

    The issue was even more terrible for network’s admin page. In addition to aforementioned user edit, each subsite’s ‘Edit’ was not loaded. So, if I wanted to change subsite’s url, I had to deactivate Performant Translations. Initially I thought it is due to Kadence Block Pro, but after deactivating the plugin at network level and activate it on subsite level, it became clear that the issue was not because of Kadence’s plugins but due to Performant Translations, which was activated at network level.

    Not sure what was the exact issue, but since I cannot activate Performant Translations for each subsite, I just deactivated it at network level. Above mentioned ‘malfunctions’ are just a tip of the iceberg. I had many plugins not working properly. ElasticPress stopped indexing on a few subsites (non-English ones), which I thought is due to ElasticSearch issue, at first. I removed and reinstalled it many times, and again, eventually after deactivating Performant Translations, ElasticPress suddenly indexes all my posts in just a few seconds.

    I am sorry to Kadence theme supporting team by that I have wasted my and their time at least over a month.

    I don’t have time to list up all the issues that I have suffered for the last a month, but I share this much, because I am super worried by the fact that from WP 6.5, Performant Translations is going to be the core of WP. On Mar 29th, immediately after WP 6.5 update, if all these malfunctions come back to me, it is going to be a nightmare again. I usually back-up daily and levae auto-update does the job, but this time, I am going to turn off auto update and will run 6.5 on a test server for at least a few days.

    If you want it, I can give you my back-up for WP and DB, so that you can play on it on your local server, but I am done debugging for now.

    Plugin Author Pascal Birchler

    (@swissspidy)

    the page is loaded with blank white

    It sounds like there might be some errors happening. Did you see anything when checking the error logs? You can check the Debugging in WordPress guide if you’re not familiar with this kinda stuff.

    The issue was even more terrible for network’s admin page.

    Ah, you’re using Multisite 💡 Now that’s a good pointer. I’ll do some more testing with Multisite and the plugins you mentioned.

    If you want it, I can give you my back-up for WP and DB, so that you can play on it on your local server

    Sure! We’re not technically allowed to do that in the forums I think, according to the guidelines, but feel free to reach out on Slack.

    Moderator Steven Stern (sterndata)

    (@sterndata)

    Volunteer Forum Moderator

    If you want it, I can give you my back-up for WP and DB, so that you can play on it on your local server

    Please don’t offer to send or post logon credentials on these forums: https://wordpress.org/support/guidelines#the-bad-stuff

    It is not OK to offer, enter, or send site credentials on these forums or on Slack.

    Thanks for your cooperation.

    Thread Starter Keith

    (@keithkhl)

    @sterndata, Thx for the notice. I didn’t know about that.

    @swissspidy, what bothered all of us (all parties jumped into debugging this issue) were not benefited by WP’s native debug as well as PHP/Nginx’s error log. In fact, there is no error log that we were able to find that is even potentially related to this issue. I guess the Kadence theme team now got kinda pissed, given the time wasted over the last a month. If we had any clue, it would have not been that long to pinpoint Performant Translations.

    Again, I do hope that this issue is resolved before official roll out scheduled in late March. Good luck!

    • This reply was modified 10 months ago by Keith.
    Plugin Author Pascal Birchler

    (@swissspidy)

    You can already install a WordPress nightly release on a test site to see if the upcoming change in 6.5 is working smoothly for you.

    As for error logs, there should always be a default log file somewhere. The hosting provider can help locate it.

    In the meantime, I was unable to reproduce any issue on Multisite with the plugins you mentioned.

    Thread Starter Keith

    (@keithkhl)

    I am aware of WP debug file’s whereabout. It’s just no critical error or even remotedly related error log was present in wp-content/debug.log. Just so you know, I have my own dedicated server. Though I am not an expert, I at least know where to find php8.x-fpm.log for PHP and error.log for Nginx.

    To be honest, the fact that you can’t re-produce my situation makes me more scared. It sounds like a combination of plugins, including Performant Translations, is the cause of my problem.

    Based on the past a month of wandering, I have a theory on this one, and it is up to you to take it. Since wp-admin pages are all shared across subsites in a multisite installation, some .php files in /wp-admin/ folder that require .mo (or translated .php by Performant Translations) are called regardless of language, but when it is called, the .php can be corrupted, affected, or jointly called by translated .php files. When this happens on a multisite network with more than 2 languages assigned to subsites, call for the translated .php may create double load or memory leak, or something similar to my description of ‘mal-function’.

    In my multisite network, I have WP Multi Network plugin activated, so I have a few sub-networks that share limited network settings. Duing the time when I had no idea how to handle the situation, I re-assigned a subsite to an unused sub-network and changed that subsite’s url, and brought it back to my main sub-network. Initially I was going to separate all my subsites by sub-network, but I can’t split object cache for each sub-network, so I cannot really use of the feature now. I had used it only for above case. The fact that I was able to change subsites’ url in the ‘clean’ (no plugin activated) sub-network, I come to a conclusion that the cause of the malfunction can be attributed to a plugin’s or a combination of plugins’ mis-use of .mo to .php conversion.

    I think I have given you all I got, unless I violate WP Forum’s rule. If things fail with WP 6.5, I will rely on aforementioned sub-networks to workaround. And, if it becomes a part of WP core, I am sure other plugin authors receive similar reports like mine and eventually there should be a fix available. Till then, I will either stick to WP Multi Network, or switch website’s language back to English temporarily.

    Plugin Author Pascal Birchler

    (@swissspidy)

    That’s not really how the translation loading in Multisite works, but if you think the issue is with “bad” PHP files there are two things you can do:

    1. Completely uninstall Performant Translations and then re-install it again. This will wipe out all PHP translation files and re-create them.
    2. Use add_filter( 'performant_translations_preferred_format', static function () { return 'mo'; } ); somewhere in a plugin or perhaps an mu-plugin to force Performant Translations to keep using MO files for translations.

    I think I have given you all I got

    I previously asked for your Site Health info which would be helpful for me to debug.

    Thread Starter Keith

    (@keithkhl)

    As said, with Performant Translations activated, I can’t load site health page. I can’t give you what I don’t have.

    Plugin Author Pascal Birchler

    (@swissspidy)

    As said, with Performant Translations activated, I can’t load site health page. I can’t give you what I don’t have.

    Then disable it first and then go to Site Health 🙂

    Thread Starter Keith

    (@keithkhl)

    Plz see the txt from the above link.

    Thread Starter Keith

    (@keithkhl)

    I just removed and re-installed your updated version. Now network admin page’s functions are working. Network admin is in English. For non-English subsites, most functions that were not working are now working, and website’s speed got improved, except site health and user edit. As before, the pages are blank white.

Viewing 15 replies - 1 through 15 (of 18 total)
  • The topic ‘Not as great as advertised’ is closed to new replies.