[Resolved] Admin.ajax.php slow my site

[Author]

Posts

[Jeffrey]

Hello,
I am using WP ROCKET to cache webpages. and having been tested with Gtmetrix got some issues. Wp Rocket support team told me , this kind of issues I may need ask the support team of plugin, so just paste some pieces of code here, could you please check for me, and teach me how I can cache and improve page speed?
1st.
Get admin.ajax.php hidden link

 a,.text-primary,.pagination > li > a, .pagination > li > span,.btn-primary .badge,.btn-link,.list-group-item
.active > .badge, .nav-pills > .active > a > .badge,.panel-primary > .panel-heading .badge,.wpt-taxonomy-popular-show-hide
, .wpt-repadd{ color:#be3179; }a:hover, a:focus,a.text-primary:hover,a.bg-primary:hover,.btn-link:hover
, .btn-link:focus,.wpt-taxonomy-popular-show-hide:hover, .wpt-taxonomy-popular-show-hide:focus, .wpt-taxonomy-popular-show-hideactive
, .wpt-repadd:hover, .wpt-repadd:focus, .wpt-repaddactive,.pagination > li > a:hover, .pagination > li
 > a:focus, .pagination > li > span:hover, .pagination > li > span:focus{ color:#6d1c45; }.dropdown-menu
 > .active > a, .dropdown-menu > .active > a:hover, .dropdown-menu > .active > a:focus,.nav-pills > li
.active > a, .nav-pills > li.active > a:hover, .nav-pills > li.active > a:focus,.progress-bar,.label-primary
,.bg-primary,body .navbar-toggle, body .ddl-navbar-toggle,body .ddl-dropdown-menu > .active > a, body
 .ddl-dropdown-menu > .active > a:hover,... [truncated to save space (11914 more bytes)]

2nd.
Get toolset-notifications.css
Get onthego-admin-styles.css
Get onthego-styles-helper.css
Get onthegosystems-icons.css
Get onthego-colors.css
Get onthego-buttons.css

above 5 files should avoid css @import, it seems. the test recommendation from Gtmetrix is Avoid @ css import

those issues normally cost 3 more second in full page loading, So I may have to solve it.

this is the result link of Gtmetrix tested hidden link, please change "mysite" as my real domain

[Beda]

I am aware off the usage of @import and myself not fully clear why. We use it only on certain files, I will report this to be reviewed.
However, @import will not slow down your site massively. It is a Medium impact issue. And there are not a lot, hence I do not expect too much improvement when we change this. However I escalate this for review, this is clear.

I am not entirely sure about your first issue, the waterfall chart.
Yes, we require wp-admin AJAX for paginations, as example. Basically all AJAX callas require it.
But that cannot be avoided.

It should not take 3.7 seconds thou. I think there is something wrong with the View in this case. What page exactly is this happening? How can I replicate that exact performance issue?

[Jeffrey]

Hi Beda, thank you for your reply! Could you please send me the private link, I will point the issued page.
Best regards

[Jeffrey]

I will send you access information as well

[Beda]

I activated a private reply. Please let me know where I can see the issues directly.

Thank you

[Beda]

Google Chrome shows the same Results here.
Please see my screenshot on the example for the services page.

Although this is not a felt slowness. It is only appearing in the report.

I confirm the issue is due to Views
All those pages you mention include a View and when you remove it the issue is gone.

I analyzed one of the Views ({!{wpv-view name="services-pricing-table"}!}) and I cannot see any issue there.
I think this problem is due to cache settings on the server.

I need to know if this issue happens as well with no other Plugins but Toolset and a native WordPress Theme.
Do you have a staging site, or can you perform such a test on any site of yours?

I am not able to replicate this locally, that is why I pin point towards server side cache issues.

[Jeffrey]

Hello Beda, thank you for your reply, yes I have tried to deactivate all of plugins including Visual composer and their addons except toolset and WPML an WP Rocket, its still appeared. I only have this site. if so, how can you help troubleshoot this ?
Best regards

[Jeffrey]

maybe you go log into my site by ftp or access to my admin? Ｉhave done backup already. Thank you so much! 🙂

[Beda]

No, the cache is still running, I can see that in the drop ins.

If you want, I can test this issue on a loa server to confirm that this is the issue.

For that I need a copy of your site.
https://toolset.com/faq/provide-supporters-copy-site/

If you cannot provide that, I can offer an online test server (it's free) that you will need to populate with your website.

[Jeffrey]

Hi Beda, thank you so much for your reply. after comparison between using toolset starter and twenty seventeen, once I changed to twenty seventeen, admin.ajax.php？action.dynamic.css disappeared on waterfall of page testing, but if changed back, it's still here. but whatever toolset starter or twenty seventeen, the page speed was not gone faster. so it may not be a issue for my site. but I don't know why full loading a page in my site takes 10 + seconds, could you please recheck for my site , and give some suggestions if possible, I am using a dedicated server and located in Hong Kong, and using Wp Rocket cache plugin. you can see the result, the score is not bad, but every factor spends more time than other sites. I will also consult with WP Rocket team.
you can see the attachment, left side is twenty seventeen, right is toolset starter.
Thank you again!

Best regards

[Beda]

The Toolset Starter ref_enqueue_customizer_css and ref_dynamica_css are loaded only if is admin.
Anyway, you can dequeue them (see ScreenShot)

Related to page speed, my analysis stands:
This is due to the Views in the Pages you shared.
And those Views are slow most likely due to the cache drop ins and server side cache you use.

We can double proof this:
https://toolset.com/forums/topic/admin-ajax-php-slow-my-site/#post-588553

If then the issue is solved there is nothing we can do, as it would require an adjustment in your cache.
Do you know that Views also offers it's own cache mechanism?
https://toolset.com/documentation/user-guides/front-page-filters/how-to-use-views-parametric-search-on-large-sites/
https://toolset.com/faq/working-with-caching-plugins/

[Beda]

I deployed the package and got some issues on the log in:
ERROR: Cookies are blocked due to unexpected output. For help, please see this documentation or try the support forums.

Note that I have cookies allowed, otherwise I could not debug client's sites locally.

I deleted all non-standard folders from the install, inclusive cache, which did not help.
I then removed all Plugins but Toolset and WPML.
This still did not help.
I tried to apply another theme, which also did not help.

I finally found out that this is a Multisite, even thou your Debug information states it is not.
Hence I removed all customizations in the wp-config.php as well and enabled error logging.

I got:

Fatal error: Uncaught Error: Call to a member function get() on boolean in .../plugins/layouts/vendor/toolset/toolset-theme-settings/compatibility-loader/toolset.layouts-themes-factory.class.php on line 31
( ! ) Error: Call to a member function get() on boolean in .../plugins/layouts/vendor/toolset/toolset-theme-settings/compatibility-loader/toolset.layouts-themes-factory.class.php on line 31

I got the same for Views after disabling Layouts.

That might have happened because you used outdated Plugin versions (Types).
I Updated and all was fine.

I finally was able to log in.

But to be honest, it's pointless to proceed now. I changed the initial install so heavily in order to be simply able to log in, that the install is basically not the same anymore.

The strangest is, that the issue still happens, even in this install, even if the page I look at has no View at all included.

All I need to do is activate Views to get circa 3 seconds more load time on the Request URL:hidden link (example)

I have to ask a Developer what I can do here, as I cannot replicate it in a fresh install.

As for the server settings you mention, I will let David Reply here on this, he is a good Server expert.

Although they seem irrelated to this issue. I hope we can find the reason for and update you properly.

Thank you for the patience meanwhile.

[Beda]

David has updated me on some details about the server.
- the smallest ADSL line has 2Mb (and thats on the client side)
- 1Mb is too low for a server
Imagine the server serving several clients, then it will be unusable.

We suggest to first upgrade this, and then retest this issue.
Even if I was able to replicate a misbehavior locally let's first start there, as that is/would be necessary anyway to have a functional site.

Please let me know the results.
I will be immediately with you if the results are the same.

Please consult your hosting provider for optimal settings of WordPress installs and these requirements:
https://toolset.com/toolset-requirements/