Plugin slowing down products page a lot about the-seo-framework

[sftsk]

Hello again,

thanks for the fast answer!
This is exactly what I was looking for, the page loads as fast as before with the plugin activated and it is not so important to see the seo settings in the overview for this project!

Have a great start into the week,
Lukas

[sftsk]

Hello, just tried it with the master version.
It is indeed a lot better. I think it still adds a bit to the loading time but you can pretty much ignore it.

Great work and thank you a lot!

[ianregister]

So on the posts that have ACF and TSF, New Relic profiling will record fine for Chrome, and eventually for Firefox but not at all for Safari. All other dashboard pages are fine for all browsers.

[sybrew]

Hi Lukas,

It seems the database you're connecting to doesn't have caching enabled.
Or if it has, it has reached its limit of the amount of queries to cache — as you said, you're maintaining a "fairly big" (I'd call it "strikingly huge") shop.

I'm afraid you'd have to disable the SEO Bar entirely. Based on your findings, everything should work as expected again.

The issue lies in that every product item needs to have all their options and outcome generated. This is quite a heavy task, so I've put the most heavy generations in re-usable transient cache, this is stored in the database. Other often used items are stored in temporarily object cache until PHP closes.

I also believe you're viewing more than 100 items per page in the product overview. This has been tested to work when you have sufficient memory allocated, but it can be a culprit as you're then also adding hundreds of transient calls. These transients aren't autoloaded, so every SEO bar you see adds extra database calls.

To disable the SEO Bar entirely, you'd have to use this filter:

add_filter( 'the_seo_framework_show_seo_column', '__return_false' );

You can also disable "no search" option finding on each product in the overview to reduce load time even more:

add_filter( 'the_seo_framework_allow_states', '__return_false' );

If you'd still like to view the SEO Bar, you can add it to the SEO Meta Settings metabox within the product edit screen:

add_filter( 'the_seo_framework_inpost_seo_bar', 'my_return_seo_bar_location' );
function my_return_seo_bar_location() {
    return 'above'; // Or below, what suits you best.
}

I do hope this helps. Let me know if disabling the SEO Bar resolves this issue.

Have a great day!

[sftsk]

hello again, sorry but I was too happy too soon.
It seemed to work fine on local but now deploying to the real server it still is slowing down things by quite a bit.

I only see these two additional queries:

SELECT option_value FROM wp_options WHERE option_name = '_transient_timeout_tsf_tdir_0_1' LIMIT 1
include('wp-admin/admin-footer.php'), do_action('admin_footer'), AutoDescription_Admin_Init->localize_admin_javascript, AutoDescription_Admin_Init->get_javascript_l10n, AutoDescription_Generate_Title->add_title_additions, AutoDescription_Detect->can_manipulate_title, AutoDescription_Detect->theme_title_doing_it_right, get_transient, get_option #88 (0.2ms)
SELECT option_value FROM wp_options WHERE option_name = '_transient_tsf_tdir_0_1' LIMIT 1
include('wp-admin/admin-footer.php'), do_action('admin_footer'), AutoDescription_Admin_Init->localize_admin_javascript, AutoDescription_Admin_Init->get_javascript_l10n, AutoDescription_Generate_Title->add_title_additions, AutoDescription_Detect->can_manipulate_title, AutoDescription_Detect->theme_title_doing_it_right, get_transient, get_option

any idea if there is anything more to tweak?

[sybrew]

Hi Lukas,

That's too bad! Unfortunately, that code snippet does not yield any issues.

Note that The SEO Framework caches almost everything it runs into. This should mean that the heaviest code is run at most once. It's also been heavily debugged using xDebug, and from 2.7.0 it will also follow WordPress.com VIP standards (wherever possible).

This all makes me afraid that there's something going wrong, somewhere, on your setup. And I want to help you eliminate it — and of course possibly discover a bug or two so this will never happen again.

The SEO Framework hooks into many WordPress components. This means it will show up everywhere where there might be an issue, related or not. It currently uses more than 100 WordPress hooks.
To be certain, I'd like you to answer the ten alphabetic questions below.

First, I'd like to ask you the following 3 questions (a, b, c), which can be very conclusive:
a) Do you experience the same performance issues when you deactivate The SEO Framework?

Then I'd like to ask you to do the following:

1. Go to the product overview.
2. Select "Screen Options" at the top right of you screen.
3. Within Pagination, note the current number. And lower it by 50%. Hit "Apply".

b) What was the previous number?
c) Did the performance improve notably when lowering that number?

If there's nothing conclusive as of yet, continue. If you're unsure, either guess (and state it) or leave blank:

d) What PHP version are you running?
e) Are you using Nginx or Apache?
e.a) If Apache, do you know which PHP handler you're using? (DSO/mod_php, Fast-CGI, CGI, suPHP, etc.)
f) Are you using shared or private hosting?
g) How much memory have you allocated to WordPress?

That information should yield if your PHP caching modules should be or can be working correctly. It should also contain slight information on how many request your system can handle.

I want to ask you to do the following:

1. Get https://wordpress.org/plugins/query-monitor/ and activate it.
2. Go to the affected slow page.
3. In the admin bar, you'll see a lot of information. Hover over the new item.
4. Select "Queries". You'll be navigated to all queries taken on that page.
5. Under component (4th column), select "Plugin: autodescription"
6. Sort it by query time (final column) by hitting the V beneath it.

h) Are the first three queries slower than 0.01 seconds? If so, could you post those?
i) Go to any page on your website, and refresh it once. The estimated load time is shown in the admin bar, what's the number?

And last but not least:

j) Are you using a caching plugin?
j.a) If so, does disabling improve the performance notably?

I know it's a long list, but this will certainly help both you (website performance) and me (eliminate bugs) 👍.

I await your response, have a wonderful day!

[sftsk]

Hello,

thank you so much for helping with this!
Sorry for only having time to go through the steps now.
Here my answers:

a) no, as soon as I take it off everything is fine
b) 20
c) a little but not so much
d) 7.0.8-0ubuntu0.16.04.1
e) nginx/1.10.0
f) own aws ec2 c4x instance
g) 512MB
h) combined time 0,0005 (only two queries run)
i) front-page 0,12s
j) no caching plugin

it's really weird. by pure numbers nothing seems to be going wrong, the loading is noticeable slower though :(

Here you can find two videos to show the difference: https://drive.google.com/folderview?id=0BxVepw957xpCWnMtM0NORENoMXM&usp=sharing

[sybrew]

Hello Lukas,

That information does look promising.
Does your website lag when you're performing a search query on the front-end? If that's so, I think I might need to rewrite something. The methods below confirm this case.

The SEO Framework 2.6.6.2 has a known issue with some caching within the admin and a combination of some themes. Normally, this isn't an issue (therefore no update has been released to resolve that as of yet).
This might cause a very heavy filter script to run - which parses all of your 70k+ items.

To resolve this, I'd like to ask you to do either (or both) of these methods:

Method 1:
Grab a copy from this GitHub's master release. The 2.7.0 (aka 2.6.6dev) release has fixed the mentioned caching problem.

It's a (quite stable) beta version. There is only one known bug that outputs an incorrect "settings saved" message when you're resetting the SEO settings.

If that doesn't help, please try method 2.

Method 2:
Use this code snippet:

add_action( 'init', 'my_remove_search_filter' );
function my_remove_search_filter() {
    if ( function_exists( 'the_seo_framework' ) )
        remove_action( 'pre_get_posts', array( the_seo_framework(), 'search_filter' ), 999 );
}

That code snippet removes the "remove page from local search" hook, it pretty much runs every search query. The admin page overview is essentially a search query.

I hope this resolves it. Have a great day and good luck!

[sftsk]

Hello,

thank you for this!
I have tried both of your suggestions.

It seems like the performance has improved a little with the updated plugin but unfortunately it is still not perfect. The page pretty much loads the list of products (and displays it right away) but then it is quite stuck loading the pagination which only appears after some seconds.

Method 2 has not really changed anything from what I can see. This seems to be a tricky one..

One thing came to my mind, I have php-apcu installed on the server, do you think that might impact the caching somehow?

Have a wonderful start into the week and thank you so much already!

[sybrew]

Hi Lukas,

Thank you so much for all the information :). If anything, the worst APCU can do is speed it up :).

I believe we're stuck here with either a theme conflict, a massive WooCommerce overload, a memory leak or WordPress core object cache conflict or something you and I just can't seem to put our finger on.

For me to find the root cause I will need to use xDebug. xDebug is something you do not wish to install on a production site as it keeps track of every single little PHP action.

Therefore, I want to ask you to go to /wp-admin/export.php and export Products. This will most likely generate a huge file so please be patient. After that, please store that .xml file in a zip container and upload it securely to a hidden location.

Please head over to https://theseoframework.com/contact/ and refer to this issue.
I will need the following information:

1. The hidden URL location to where you've stored that export file.
2. The name of the theme you're using. If it's premium, could you provide a zip it as well?

Such a huge product list will help me debug everything up to otherwise the nanosecond and a possible inconsistent caching conflict.

Thanks and have a great day :).

[sftsk]

I have just sent you a message via the contact form.
Have a wonderful day as well!

[sybrew]

Confirmed to be a special use case scenario.

Further details are still being discussed and a fix will be planned after the 2.7.0 release.
However, it's still not known what the cause for this issue is and I can't seem to replicate it.

[sybrew]

Maybe related: https://wordpress.org/support/topic/spinning-wheel-on-products-firefox-and-mac-os-x/

It's almost definitely a bug performing on JavaScript level.

[sybrew]

Reopening: Accidentally closed through commit.

@sftsk Could you test this patch, by disabling the SEO Bar settings there, and possibly adjusting the cache settings? Cheers! 😄

[sybrew]

The patch or this patch seems to have fixed the related issue on WordPress.org

I'm closing this issue for now; however, if the issue is still occurring, please do let me know and feel free to re-open this issue.

Happy New Year!

[sftsk]

Hello @sybrew and Happy New Year!
Sorry I only got to check this now. I updated the plugin on production (2.7.3), unfortunately the plug in still significantly slows down the loading of the page, I did get a beach ball from time to time.
It seems like this indeed might be a low level JS issue :(

Tested on Safari 10.0.0.2 on macOS 10.12.2

[sybrew]

Happy New Year @sftsk!

No harm done 😄

Have you tested out the GitHub Master version yet? The SEO Framework 2.7.3 doesn't include most of what has been done since 14th of September 2016.

TSF 2.8.0 development is almost going on for half a year, including over 250 changes 😄.
The updates of 2.7.x are merely fixes for explicit bugs.

Cheers!

[ianregister]

Hey guys

I'm having a similar problem. Looks like it's a browser thing with Safari having some issue with JS. I have TSF on pages that have large ACF content builders. I'm usually logged into WP in Safari, and developing the front end in Chrome. I have now completely disabled the SEO bar, and disabled custom meta fields (ie core WP ones) on those pages, and now if I log in to WP via Chrome everything is fast enough. Locally I'm still experimenting with xdebug on / off, transient caches on / off. I'm measuring with the Debug Bar, Debug Bar Slow Actions, Query Monitor plugins, and xdebug.

I'm using v2.9.0-beta2017.03.18.1. I've noticed that 301 redirects function correctly with this on our nginx server (based on the Trellis project) whereas with the 2.8 they were not working.

I'm also using add_filter( 'the_seo_framework_show_seo_column', '__return_false' ); with v2.9 but haven't tested this actually works. Can you confirm it has any effect on v2.9?

I also think v2.9 is prettier.

I'll let you know if I find any issues and have to revert to v2.8.

[sybrew]

Hi @ianregister,

Which Mac OSX version are you using, also Sierra? I can then pinpoint and simulate this, thanks!

That 301 redirects work again on NGINX is a fortunate consequence of making the code structure more in-line with WordPress' flow 😄, thanks for notifying!

The filter the_seo_framework_show_seo_column has no effect if the options in the General SEO Settings have been turned off, because the filter runs a little later than that check.

Please note that the 2.9 release is planned for this weekend, so if you find any issues in the meantime do keep me updated! Thank you so much!

[ianregister]

Gidday Sybre

Yes OSX 10.12.4 and TSF 2.9.1.

I've actually got the same issue in Safari / Safari TP / Firefox all updated to latest. Chrome seems able to cope. The issue seems to be when both ACF Pro 5.5.11 and TSF 2.9.1 are both activated. Deactivating either seems to cause no problem.

I'm on NGINX and PHP-FPM v7 and 7.1. My error logs for PHP and NGINX and the WP debug.log file are all showing no errors. Xdebug yields nothing either. I'm going to try New Relic and Blackfire profiling.

Anything else you think I could send you? Or any other profiling I could try?

[sybrew]

Hi @ianregister,

There will be a delay in confirmation because this is now a backlogged issue.
I'll test out your scenario in the appropriate applications.

NewRelic, xDebug and other applications won't give you any worthy results, as this is a browser issue; not a PHP issue.

[ianregister]

Thanks for that! Are you sure New Relic Browser profiling of the JS won't help. I've just set it up quickly and it's showing a long 90s GET request to ajax-admin. I'll let you know what else I dig up.

[sybrew]

@ianregister

Odd....

user_can_richedit() is the only function that makes an exception for Safari, and that exception is only different for when it finds an iPhone or iPad.

What's the full page URL you conducted your test upon (you may exclude your domain)?
e.g. https://example.com/wp-admin/edit.php?post_type=product

[sybrew]

@ianregister It might have to do with a:visited history. The SEO Bar might be better set as "span" tags rather than "a" tags. It might be good to see if private browsing in Safari will resolve it for you. If so, then the browsing history is relatively full.

SEO Bar improvements are planned: #57

[ianregister]

Hi!! Sorry didn't get back to your last email. Here is the URL wp/wp-admin/post.php?post=352&action=edit which is an ordinary unmodified WP page and not a custom post type. Note that our WP solution is restructured using the Bedrock project https://roots.io/bedrock/ Issue in Safari is still present in normal and private modes. Not quite sure what you mean regarding span and a tags? I also have disabled the SEO Bar, in fact it's been disabled in all of my previous comments above.

[sybrew]

Not quite sure what you mean regarding span and a tags?

They're technical details that affect how browsers parse the content 😉 It's my job to look into those.
Don't worry about that.

[sybrew]

From what I've gathered, this issue:

• is on Mac OSX.
• seems to be related to PHP only.
• seems to be related to database queries.
• seems to be related to CPT only.
• isn't affected by the presence of TSF's scripts.
• is not related to browser history.

I've tested it and produced no notable results, whatsoever.

I'm leaving this open whilst waiting for someone to provide a hands-on experience for me, or a working solution.

[sybrew]

In the latest commit, I've reduced the number of attached events from about 500 to 30 per page. They build themselves up as required, and they break themselves apart when they're no longer needed.
This is the main source of optimization, and on lower-end machines you'll notice lower browser load time.

I've also optimized CSS by removing more global type selectors. This lowers both memory and CPU usage on-load, thus lowering browser page load time.

And, I've optimized HTML, as there are no more use of "fake" links initiating more JS calls, and with a lower probability of browser history bug invoking (see #18 (comment)).
This is an all-round optimization, that should reduce cache hits. This might be notable on heavily used machines still using hard drives.

To top it off, EdgeHTML touchscreen support has been implemented 😄.

In an earlier commit, some visual improvements and CSS improvements have also been implemented. This is a nice touch for when you wish to play around with admin themes.

I hope this all is enough to alleviate the performance issues.

Feel free to test it on a disposable dummy site or staging site.
I do not recommend using 3.0.0 in its current state on any site in production, although it's running perfectly live at https://theseoframework.com/.

I'm leaving this open until confirmation of resolution.

[ianregister]

I look forward to testing! [moderated email footer]

[sybrew]

I'm closing this issue as I haven't heard any complaints since 3.0.0.

[LucidNinja]

Did anything end up getting resolved here? I'm having basically the exact same issue as @ianregister. Using Safari (Chrome is fine) with ACF Pro 5.6.10 and TSF 3.0.6. When I have a Page with ACF's Flexible Content areas and with TSF enabled, Safari gives me a spinning wheel and hangs for about 10-15 seconds before finalising the page. Query Monitor doesn't seem to be returning anything that would flag my attention. I'm just migrating from Yoast SEO and am testing the TSF plugin for my scenario. So far I like it, but if page hanging is an issue, then it will be unworkable. As for server environment, I'm using Laravel Valet on MacOS 10.13.5 and Roots' Bedrock solution also. @ianregister did you find a solution?

[sybrew]

@LucidNinja Could you open a new issue? Feel free to solely write this for the issue content:
"Follow up: https://github.com/sybrew/the-seo-framework/issues/18#issuecomment-404038769"

I believe this thread (originally) was for the product overview page (../edit.php), not the product edit page (../post.php). I'm sensing this got a bit off topic and went over my head in the process.

I currently don't have easy access to an OSX machine nor ACF Pro, so debugging might be a bit though. I'll ask around.

[LucidNinja]

Thanks @sybrew - I have created a new issue as suggested.