I am posting the topic in this section because my goal is for the development team to study what I will write.

First, I will share that the 5th version is at least twice as easy to optimize web vitals compared to the previous 4.x, and 5.0.6 has significantly improved performance, for which I can only congratulate your team for developing an unexpected but effective improvement.

Today it occurred to me why, when my main site was still using 4.7.20, and the test site was with 5.0 beta - the PSI tests with 4.7.20 were relatively constant and good indicators, while the tests with 5.0 were strange - either deeply fixed between 60-65 for a mobile test (in fact, I won't talk about desktop anymore, only for a mobile test) - and for a period of at least an hour, for tests every 10-15 minutes, or with a sharp improvement of the order of 85-95 again for an indefinite time, about an hour, with tests at the same intervals...

And here I remembered today - in 4.7.20 I used only forums and pages...and in 5.0 it's all APPs.

Although I haven't launched public commerce yet, I'm experimenting with this app. What I noticed - I noticed commerce tasks first. Here are my observations from today - of course my main site is 5.0.6

Today I decided and started a long series of tests - as early as 10:00 AM - I created a table in which I noted down the results of my tests every 10 or 15 minutes...I won't post it now because it's quite long and boring. But what can be summarized? These were tests that I finished around 5:00 PM.

In short - between 10:00 and 11:00 - test results were between 64-66 points - and without any difference in LCP - always around 6 - 6.5 seconds... Removing the cache site, changing the browser used for testing, and other ideas did not change the test results.

After 11:00, the tests changed abruptly and for a period of at least an hour they were in the range of 85-99 points (I didn't do anything on my site - only tests), and today my server responded quite well for all tests, i.e. the server's behavior has nothing to do with it - for the entire test period it was very good.

Between 12:30 and 14:15 my tests hit 64-66 again... I was thinking of giving up on tests for today, when at 14:30 it was 99 again... and by 17:00, when I stopped testing for today, all tests were between 85 and 99... at every moment when I ran them...

Now a little while ago my first test from my home was with 64 points. I decided to do an experiment - I manually started all the commerce tasks. Here is the first test after my action -

,

and the site at this time functions quickly and without issues.

I waited a few minutes and tested again.

What I think is that there is a function in one of the tasks with an indefinite timeout, which causes the interference that I write about above. And this is related to the slow 4G, as the PSI test is set up.

Sorry if I have bothered you, but I think there is some error that affects performance and at an unclear moment in time.

This task (generateRenewalInvoices - Generates renewal invoices for purchases nearing expiry.) creates an issue

At each launch, the site changes its operating mode - i.e. if the PSI test was very good, and you manually launch this task, the next test is fixed or 64-66 points. If you repeat the manual launch of the same task, this "blockage" disappears and the PSI test is already within the norm - 88-99 for mobile.

The strange thing is that after manual launch, this task is not executed correctly, and this message is received:

The task ran successfully and produced the following output:

SELECT ps.* FROM `nexus_purchases` AS `ps`  LEFT JOIN `nexus_billing_agreements` AS `ba` ON ps.ps_billing_agreement=ba.ba_id WHERE ps_cancelled=0 AND ps_renewals>0 AND ps_invoice_pending=0 AND ps_active=1 AND ps_expire>0 AND ps_expire<1744882125 AND (ps_billing_agreement IS NULL OR ba.ba_canceled=1) AND ( ps_grouped_renewals='' OR ps_grouped_renewals IS NULL ) ORDER BY ps_member LIMIT 50
0 matches

PS. Since last night, after upgrading to 5.0.6 - 3 pages with this error...

Its one of the reasons we advise on self hosted instances running cron jobs for tasks. Im assuming you arent on this occasion, and its running with traffic?

17 minutes ago, Marc said:

Its one of the reasons we advise on self hosted instances running cron jobs for tasks. Im assuming you arent on this occasion, and its running with traffic?

Not with traffic, I have an active cron jobs

PS. On a test site, also with cron jobs, the same is true for this task - every 30 minutes an issue is recorded