[Escalated to 2nd Tier] Over a 100 duplicate queries, super-slow site
This is the technical support forum for WPML - the multilingual WordPress plugin.
Everyone can read, but only WPML clients can post here. WPML team is replying on the forum 6 days per week, 22 hours per day.
Our wait time is higher than usual, please make sure you are meeting the minimum requirement - https://wpml.org/home/minimum-requirements before you report issues, and if you can take a look at current Known Issues - https://wpml.org/known-issues/. Thank you.
Background of the issue:
I am trying to address an issue where WPML is causing over 100 duplicate queries per page, which is significantly slowing down my development site. Disabling WPML restores the site's speed to normal. I used query monitor to identify that the scripts causing the slowdown are related to WPML. The issue can be seen on this page: hidden link.
Symptoms:
The site is experiencing a super-slow speed due to over 100 duplicate queries per page caused by WPML. When WPML is disabled, the speed returns to normal.
Questions:
How can I resolve the issue of duplicate queries caused by WPML?
What steps can I take to improve the site speed while using WPML?
Our second-tier supporter has debugged this issue. The problem arose from the Briks theme. Here is a detailed explanation our second-tier supporter provided.
Visiting the site front page I can see the duplicate queries.
The vast majority arise from calls to get_page_by_path that follows from Bricks and a calls to Bricks\Helpers::maybe_set_aria_current_page when generating links, twice for every link.
There are also a few (not many) duplicate calls to icl_get_string_by_id arising from Bricks calls to get the site name and description from options.
Switching to a default theme eliminates virtually all of these duplicate queries (and the home page loads almost instantaneously).
There are a lot of links on the page output by the theme (notably in the header navigation), and every time the theme outputs a link it checks "is this linking to this same page" to know whether to add some aria attribute related to the current page, and so url_to_postid gets called each time to know what page the link is linking to, and we filter those calls because we need to handle cases where urls include a language directory or parameter.
WPML being implicated in the queries just reflects the volume of queries being made by the theme (when there are lots of links on the page).
The theme could perhaps cache the url of the current page and use that instead of calling the same url_to_postid function so many times.
I'm calling our compatibility team and asking them whether there is something we can do here from our side or if we must have the cooperation of the Bricks theme about it.
Meanwhile, it would be great if you could also contact the Bricks theme support and report this issue to them. You can send them the link to this ticket.
I'll update you once I have our compatibility team's reply.
I have a response from our compatibility team. They explain that the issue isn't caused by WPML directly but is made more noticeable due to our filtering. Therefore, as suggested, you should contact Bricks theme support to report this issue. If they need help, they can contact our developers, who will direct them on changing their code to fix this issue.
Please let me know if you have any further questions.
