Background of the issue:
I am trying to optimize my webpage and have attempted it with exports, but no one could get good results. I need to improve and identify the plugins or scripts that are consuming too much capacity. Link to a page where the issue can be seen: hidden link
Symptoms:
WPML is consuming more capacity compared to other plugins and scripts. I expected to see a less demanding WPML plugin, but the issue persists.
Questions:
How can I optimize WPML to reduce its capacity usage?
What steps can I take to identify and address the high resource consumption by WPML?
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+01:00)
Hi,
Can you tell me which tool are you using to measure this?
Also, can you please check the performance when:
- only WPML plugins are activated, as it will tell us if there is an interaction issue with other plugin
- theme is set to a WordPress default like Twenty Twenty as it will tell us if there is an interaction issue with your theme
Ok it´s a live site so I have to make and test eniviroment fort change this big things?
It´s called CODE PROFILER
What is Code Profiler?
Code Profiler measures the performance of your plugins and themes at the PHP level, and helps you to quickly find any potential problem in your WordPress installation. It generates an extremely detailed and easy to read analysis in the form of charts and tables that shows not only which plugin or theme, but also which PHP script, class, method and function is slowing down your website. It displays many useful additional information such as file I/O operations and disk I/O usage as well.
It makes it very simple to locate any speed problem in your themes or plugins in order to solve it and speed up your website.
Why does the execution time and memory returned by Code Profiler seem higher than when I load my site in my browser?
Because the profiler needs to analyze your PHP code, it must exclude and disable any kind of website optimization: caching, CDN and PHP OPcache.
A caching sofware and a CDN service will prevent execution of your code and thus must be disabled by the profiler.
Regarding the opcode cache, PHP includes an opcode optimizer since version 7.0: after creating the first set of opcodes, it forwards it to the optimizer where it will get through 13 passes that will optimize it (peephole, jump, call, literal optimizations etc). That means that at the end of the day, the code in the opcache may have been optimized and thus may not match the original code found in your scripts. For that reason, it must be disabled. That problem occurs with other profilers too such as the xdebug extension, which cannot run well when the optimizer is turned on because it removes some virtual machine instructions needed by them.
Note that disabling the opcode cache also increases the memory usage because PHP needs to open, read, parse and compile all scripts instead of serving them from the cache.
Was too much work to make the dev. site for this purpose, but I got following result and to get the answer of below...
Why does Code Profiler warn me that I have multiple plugins using Composer?
Composer, a tool for dependency management in PHP, is included in many popular plugins and themes. It is used to autoload PHP classes.
Code Profiler will inform you if two or more activated plugins use it because you will need to take it into consideration when reading and interpreting the results. Let's take an example:
Assuming you have four plugins, #1, #2, #3 and #4. Both plugins #1 and #4 include and require Composer. WordPress will start and load plugin #1, which will run an instance of Composer to load its classes. Immediately after, WordPress will load plugins #2 and #3. Then, it will load plugin #4, which too will need to load its classes. However, plugin #4 will not start a new instance of Composer but, instead, will rely on the one from plugin #1 to load its own classes.
As a result, the execution time of plugin #1 will increase (its instance of Composer is used to load classes for plugin #4 too), while the execution time of plugin #4 will decrease (it doesn't need to start a new instance of Composer). Therefore, if you have a dozen or more plugins using Composer, it is important to take into consideration that the execution time of plugin #1 may be much higher than other plugins.
Also, assuming you are a developer and just want to profile a plugin that you wrote and that includes Composer, you will need to disable any other plugin using Composer in order to get the most accurate results for your plugin only.
Languages: English (English )German (Deutsch )French (Français )
Timezone: Europe/Zagreb (GMT+01:00)
I am not sure if this description helps me, it only explains how Code Profiler works.
Can you try measuring site load in both the frontend and the backend using tool such as hidden link in scenarions when WPML is active and when it is disabled?
And then send me screenshots.
The topic ‘[Closed] See the attached image and you´ll see WPML eating capacity compared to other plugins and scripts’ is closed to new replies.