Siteground hosting is an issue?

It sounds like you are looking in the right place. The tools you mentioned were added to the plugin to try to comply with the strict timeouts some hosting providers have.

I would keep the maximum execution time set at the default 5 minutes. The setting will most likely not be honored by your hosting provider but there is not much to gain here setting it lower. Then I would set the max script runtime to 60 seconds.

Start a new scan and see how that goes. If the scan still terminates early then one of a few things are possibly happening.

Perhaps the page that is being scanned is taking a very long time to be reported on and the timeout on your server is still be exceeded. This max script runtime feature is designed to check a page report, then when it receives the results, to see if there is still time left to check another page report. So there are cases where even at a 60 second timeout, the script might run longer if a new report is requested right before the 60 seconds expires, and the report takes a long time to come in.

Or maybe the timeouts on your server are even shorter than the 120 seconds you’ve been told. I’ve run into situations with other shared hosting providers where they had settings in apache that killed processes earlier than any setting I could see in the PHP.ini settings. Perhaps siteground is even more aggressive in killing tasks than other shared hosts I’ve tested with. Currently the minimum setting in the plugin is 60 seconds like you mentioned, however a lower setting could be set for testing purposes.

To add a 30 second option:

1. Open the file for editing: google-pagespeed-insights/templates/options.php
2. After line #183, add the following:

   <option value="30" <?php selected( $this->gpi_options['max_run_time'], 30 ); ?>><?php _e( '30 Seconds', 'gpagespeedi' ); ?></option>

3. Save your changes.

You should now have a 30 second option available to test with. If this fixes the problems you are seeing on Siteground then I will add this 30 second option into the plugin.

I will try your suggestions after you have looked at this:

The scan DOESNT terminate. Thats my issue. It updates by 2% most of the time and sometimes a little more at 3% or 4%. Then the scan progress green bar is stuck there. I do not get any terminationa message.

What is most likely happening, is that the scan *is* terminating, but because the scan got terminated, it can’t send a signal to the progress bar. So the progress bar just stays how it was.

An easy way to check for this, is to navigate to a different page in the plugin. Scans run as a separate process on the server so you can navigate around the plugin while it runs. If you navigate away, and the progress bar disappears, then the scan was terminated by the server.

Yes, I have been doing that and on migrating to other tabs of your plugin the progress bar definitely goes away. So you are right the scans are terminating.

Now I have implemented the code provided by you. New issue has come up. On options tab the 3 plus signs with which we open or shut the various option settings are no longer woring. I cant shut or open them!

In the meantime I have also shut down WP Heart beat and disabled the WP Cron and rather have real Cron enabled directy from the server as per suggestions of siteground.com support to reduce load on server and improve server response. Just keeping you aware.

It sounds like you accidentally introduced a PHP error while adding the 30 second option. Double check your code for syntax errors or revert your changes and the issue should resolve itself.

I can do a recheck. But apologies this issue developed before altering the code in your options.php file and after disabling wp heartbeat.

Also, siteground.com support has informed me that if you the plugin developer require any changes on server side settings, except the max times to be 120 seconds they would try to change them to suit your plugin reuirements, if they are permissible within the hosting environment.

Shutting down WP Heartbeat is probably the cause of the javascript errors you are now seeing in the options page. The same JS file that controls the toggling of those options also uses some of the heartbeat API stuff. I will have to add some additional checks in the future for people who have heartbeat disabled on their servers to prevent this. This plugin uses WP Heartbeat to update the progress bar.

<option value=”30″ <?php selected( $this->gpi_options[‘max_run_time’], 30 ); ?>><?php _e( ’30 Seconds’, ‘gpagespeedi’ ); ?></option>

This is what exists at line 184 now. This line begins exactly where <option appears in all subsequent lines.

Oh Ok if this plugin uses WP Heart beat to update progress bar I will remove the disable choice from Heartbeat control. This is giving me options for having Heartbeat enabled or disabled in:

Wordpress Dashboard
Frontend
Post Editor

I can have it disabled in all of them, or any of them as one rule.

By a separate rule for the one(s) you require to be not disabled but enabled we can change the frequency from 15 all the way to 300.

Please kindly tell me do you need Heartbeat in all 3 or any specific of these 3 and what is the max frequency of heartbeat at which your plugin will still work well.

Thanks.

Yes you are right.

soon as I have re-enabled Heartbeat for all three options, i.e. frontend, admin panel and post editor with freuency of 300 the options are cickable now and the scan is now running much better. It could improve, perhaps with knowing from you:

Of frontend, adin panel and post editor which heartbeats are necessary to be kept on and what is the frequency ideal for heartbeat for the required items. Then I guess the scan will get optimized.

Also one more question: Now that scan has improved with the 30 seconds script run time option do you feel if it still doesnt complete I can have one more option of 20 seconds or 15 seconds?

Heartbeat is only needed in the admin panel for my plugin. The frequency is up to you. Assuming this overrides the settings I’ve chosen in the plugin, the higher the number, the longer you will wait to see progress bar updates happen.

As far as scan max run time, hopefully 30 seconds does the trick. The lower the max run time, the longer the scan is going to take in the long run to finish, as it will not be able to run very many page reports before having to stop and schedule an additional check.

So many thanks. You have supported on this free plugin like a rock star. I am compelled to give only 5 stars as by norm thats the highest. But you deserve likely 10.

Update:

Please go ahead and do the 30 second option also for all your users. It has resolved my situation and its working fine.

I had enabled Heartbeat only for the Admin Area with frequency at 60 seconds now and disabled for Frontend and posts.

I read somewhere here that your latest version allows snapshot comparison and other features. I am unable to locate that. If in case you have a way to indicate where to find it will be very obliged.

Thanks for the review. Glad that sorted it out for you. I will add the 30 second option in the next update.

I read somewhere here that your latest version allows snapshot comparison and other features. I am unable to locate that. If in case you have a way to indicate where to find it will be very obliged.

You can read more about these features in the official documentation. Check out the section on snapshots.