Time between URLs warmup

Resolved gregywordpress
(@gregywordpress)

4 months, 2 weeks ago

Hello again!

The option to set the time at which the warm-up should start was a very good solution. Thank you!

Would you consider adding another option?

The idea is to be able to set the time (e.g. in seconds) that should elapse between individual URLs.
For example, I would like to set 3 seconds between the warm-up of the first URL and the next URL, and 3 seconds to the next one, and so on.

Would you consider introducing such a modification?

Greg

Viewing 6 replies - 1 through 6 (of 6 total)

Plugin Author Ozgur Sar
(@ozgursar)

4 months, 2 weeks ago

Hello @gregywordpress ,

Thanks for helping us improve the plugin! Actually that’s a very nice feature request.

Instead of 3 seconds hard-coded waiting time, it’s better to add it as a setting so people can adjust it.

So, I added it to the list. Thank you!

Ozgur

Thread Starter gregywordpress
(@gregywordpress)

4 months, 2 weeks ago

Yes, that’s what I meant. Thank you very much!

In the meantime, I noticed that the preloader sometimes freezes or – to say better – stop working. For example, it performs preloading in several batches and then stops. Even though cronjobs are called, preloading does not continue. In the Log tab, you can only see, for example, ‘Scheduled next batch at index 250’ …and it stays like that. Preloading does not continue.
Could you perhaps consider generating an additional log? One that would indicate the possible reasons for the preloading stopping or show any errors or processes that could have affected the preloader’s operation?

I hope this would be another step towards improving the plugin.

Best regards,

Greg

Plugin Author Ozgur Sar
(@ozgursar)

4 months, 1 week ago

Hello @gregywordpress ,

The issues you have mentioned are fixed and improved (including the missing user-agent problem) in the latest 1.0.4 version.

Please update and test.

Thread Starter gregywordpress
(@gregywordpress)

3 months, 3 weeks ago

Hi Ozgur!

I’ve tested the plugin regarding the User Agent.
Unfortunately, the UA is still somehow being overwritten by WordPress, and it stays empty in the place where the UA should appear.
I should mention that I’m using WP Rocket, and their UA always shows up in the logs. I’m not sure why yours doesn’t… although my earlier investigation might give some hints about what’s happening.

The missing UA makes it a bit tricky to use the plugin – especially when setting up things like Cache Rules in Cloudflare.
I was thinking it might be worth considering an alternative to the UA, maybe something like a query string. For users like me, where the UA doesn’t appear, a query could help recognize the requests and trigger a bypass.
For example, every preload request could include something like ?fix-cf-preload=1.

By the way, I really like that you’ve added more flexibility to the preload frequency and duration settings. That’s a great improvement!

What would be super helpful is to also include:
* Additional batch sizes: 40, 70, and 80.
* Extra delay options: 4, 6, 7, 8, and 9.
* A more flexible scheduling system, so preload could run for example 3 times a day (because of the Cloudflare Cache Eviction policy).

Another nice addition could be preloading for mobile devices, not only desktops. That way, cache would be generated separately for both versions.

Some users, including me, use the plugin locally – within one country or region. It sometimes happens that webshare.io assigns a wrong IP (for example, the cache is built in Lisbon instead of Frankfurt).
That’s why I thought it could be useful to add something I call a “Rescue Round.” After finishing a full cycle, the plugin could check where the cache is missed and perform preload again for those locations.
For example, if the preload targeted Frankfurt (FRA) but after finishing it turns out that 40 hits went to Lisbon (LIS), it could preload those 40 missed one more time.

Thanks again for your great work on this plugin – it’s really developing nicely! Hope my ideas will find your attention.

Best regards,

Greg
Plugin Author Ozgur Sar
(@ozgursar)

3 months, 3 weeks ago
>Unfortunately, the UA is still somehow being overwritten by WordPress, and it stays empty in the place where the UA should appear.

Hi Greg, if you can provide me steps to reproduce this, I’ll be willing to test it.

If you can compare the latest changes to the http_request_functions.php, it has includes the headers that you provided with your previous solution.
```
 $response = wp_remote_get($url, [
    'timeout' => $timeout,
    'headers' => [
      'User-Agent' => WPFF_SP_USER_AGENT,
    ],
    'user-agent' => WPFF_SP_USER_AGENT,
  ]);
```
Additional batch sizes and delay between URLs can be changed to input boxes rather than dropdowns but that might causes issues for users who might accidentally enter inappropriate values which can slow down their website or cause unexpected issues.

Also, there is no such thing as mobile or desktop cache. It’s a single HTML file cached on the edge server and served just like any other asset. You need to think of it as 1 html file per URL. How it’s rendered on the client depends on the html structure, css styling and user device.
Plugin Author Ozgur Sar
(@ozgursar)

1 month, 3 weeks ago
Hi @gregywordpress just wanted to let you know that in version 1.0.6 we’ve added a filter that allows you to customize the HTTP request arguments, including the User-Agent header.

Here’s an example code that you can use in your functions.php:
```
add_filter('wpff_sp_http_request_args', function($args, $url, $proxy) {
    $args['headers']['User-Agent'] = 'MyCustomAgent/1.0';
    return $args;
}, 10, 3);
```
If you would like to check where this filter is found in our code, its at:
/includes/class-http-request.php line 50

Viewing 6 replies - 1 through 6 (of 6 total)

You must be logged in to reply to this topic.

Tags