Beta 8 - Reduced performance mobile

[Matt]

That will cache the HTML, it does not reduce the size of the HTML so it should not have any affect on FCP times.

[EliasM]

1 hour ago, Adlago said:

I set it to 3 minutes I will try to increase it and check the difference

[Adlago]

1 hour ago, Matt said:

That will cache the HTML, it does not reduce the size of the HTML so it should not have any affect on FCP times.

Even in older versions 4.x I found that when the time cache block expires there is a sharp increase in the first byte (i.e. the first visitor to a site gets it) - that's why this parameter was always set to 1 hour for me. Now it's the same on 4.7.19. I had it set like that back in the first beta 5.0.
Now in beta 8 - I noticed that only the cache block expiration time test has excellent results. Or simply put, with 1 hour cache a site is doomed to poor results for 1 hour. Now with 5 minutes - there are many more excellent test results.
My suspicion is that after caching blocks, the first visitor to a site has an excellent experience (after which probably for some reason all blocks are non cached until the expiration time set in ACP - advanced, and then cached again until the first next visit) - i.e. please test this hypothesis.
Keep in mind that PSI test uses additional network latency for mobile (slow 4G). I used "fast 3G" in my tests - and what I noticed was a very slow loading of "fa-solid-900.woff2" - about 6 seconds. Then I activated one of my hooks with which I eliminate "preload font"
and this loading time for the font dropped to 2 seconds.
Then I noticed a high result of the network indicators-PSI test, at a time of already cached blocks - and the next test was again 30 points worse. After lowering the cache block time to 5 minutes - excellent results are much more and more regular.
I.e. in my opinion there is some issue with the management of cache blocks.

[EliasM]

12 hours ago, Adlago said:

This issue is related to cache blocks. I reduced the cache time to 10 minutes and after a few tests:

Then again bad tests, but after 10 minutes again very good.
Now I left it at 5 minutes - and again often very good test results.
@Matt   Please review the "Cache sidebar, header and footer blocks" management.

I changed it to this and it didn't affect the speed of the site

[Adlago]

Just now, EliasM said:

I changed it to this and it didn't affect the speed of the site

Achieving good results does not happen by changing just one parameter. Your site probably has other reasons for delays.
If you want, send me a PM with a link to your site so I can do some tests.

[Dll]

@Adlago, you appear to be misunderstanding how the caching works. It's not a local cache on a users machine, it's caching the html for the block server side, so the backend isn't generating it each visit. If you cache it for 1 hour, it'll retrieve the html from that cache for 1 hour, and then check again for an update the first load after that. Once it's done that, it'll cache it again for an hour. 

So, setting it for one hour will make it faster across the hour than setting it for 5 minutes. 

[Matt]

[Matt]

Also, as far as I know, the FCP timer starts as soon as the browser receives the content, the timer doesn't start when the test starts so a slow return from the server will not affect FCP.

In other words, if it takes 10 seconds for the server to generate the page and send to the browser, the FCP time will not be 10 seconds + browser render time.

[Adlago]

On 12/18/2024 at 3:47 PM, Matt said:

Also, as far as I know, the FCP timer starts as soon as the browser receives the content, the timer doesn't start when the test starts so a slow return from the server will not affect FCP.

In other words, if it takes 10 seconds for the server to generate the page and send to the browser, the FCP time will not be 10 seconds + browser render time.

I'm not sure what the reason is, hence this topic.
Another similar example - I created two identical pages in 4.7.19 and in beta 9.1 with the title 444.
In each of these pages there is one block with the same image. That is, they are almost identical.
Here is a mobile tests:

4.7.19

5.0.beta 9.1

 

I won't comment, but there is an obvious difference in performance, but not in favor of 5.0.

[EliasM]

1 hour ago, Adlago said:

I'm not sure what the reason is, hence this topic.
Another similar example - I created two identical pages in 4.7.19 and in beta 9.1 with the title 444.
In each of these pages there is one block with the same image. That is, they are almost identical.
Here is a mobile tests:

4.7.19

5.0.beta 9.1

 

I won't comment, but there is an obvious difference in performance, but not in favor of 5.0.

Beta 9.1 speed dropped dramatically🤦

[Matt]

11 hours ago, EliasM said:

Beta 9.1 speed dropped dramatically🤦

It really didn't.

[virap1]

1 hour ago, Matt said:

It really didn't.

I don't understand. v5 was presented to have major speed improvements which is big for us all. Here people share actual data and a more comprehensive explanation, reply other than  "It really didn't" would certainly help here.

[Matt]

3 minutes ago, virap1 said:

I don't understand. v5 was presented to have major speed improvements which is big for us all. Here people share actual data and a more comprehensive explanation, reply other than  "It really didn't" would certainly help here.

 

Are you basing that opinion off screenshots from Adlago?

He has spent years optimising his v4 installation to get the best PageSpeed score possible. I'm unsure how long he has spent with v5.

In any case, a good portion of PageSpeed is down to the server, the use of CDN, etc. It's not just the software. Running the same test three times will give you three different scores, it's not an exact science. Likewise, running "grid" or "feed" view in v5 will result in lower performance scores because there's more images on the page; but I wouldn't just optimise for PageSpeed, actual humans use your community.

In terms of "out of the box and running on the same hosting set up", here's our v4 compared to v5.

[virap1]

Thank you Matt. Is there some data how the testing was done and how it is more accurate and reliable than what the users are sharing here. YEs, my post was based on the information in this topic. I am still on v4.

[Matt]

I ran both tests again, and got this result.

Just now, virap1 said:

Thank you Matt. Is there some data how the testing was done and how it is more accurate and reliable than what the users are sharing here. YEs, my post was based on the information in this topic. I am still on v4.

Yes, we do benchmark, but the claim about speed is based on using native lazy loading, removing loads of JS, moving assets into correct locations, the new CSS framework being smaller and the HTML structure being more compact.

[EliasM]

12 minutes ago, Matt said:

I ran both tests again, and got this result.

Yes, we do benchmark, but the claim about speed is based on using native lazy loading, removing loads of JS, moving assets into correct locations, the new CSS framework being smaller and the HTML structure being more compact.

It would be better to test on a beta site that has been upgraded from version 4 to version 5, as most of the problems appear on the upgraded sites,

As for the speed problem, it was not affected on the mobile phone, but dropped is heavily on the desktop

So far, version 5 is much slower than version 4 on upgraded sites that have a lot of data

Edited December 30, 2024 by EliasM

[Daniel F]

4 minutes ago, EliasM said:

4 to version 5, as most of the problems appear on the upgraded sites,

This really shouldn't make any difference. An upgraded site won't load anything different to a new installation. The same templates and same JS & CSS files will be returned, it may have some slower DB queries on really really big communities compared to a new, empty installation, but that's all

[EliasM]

1 minute ago, Daniel F said:

This really shouldn't make any difference. An upgraded site won't load anything different to a new installation. The same templates and same JS & CSS files will be returned, it may have some slower DB queries on really really big communities compared to a new, empty installation, but that's all

Unfortunately the exact opposite happens, whenever the site contains a lot of data it becomes significantly slower, this slowness happens on desktop mode

[Gary]

I’m curious. When you say significantly slower, well, how much slower? Hours, minutes, seconds, milliseconds, microseconds, nanoseconds, etc?

I’m just astonished as to how many people seem to be worried about minuscule “changes to their page speeds” on their communities. Unless your community is heavily focused on discussing page and load speeds as a niche or subject matter, why does a seemingly insignificant result from a third party matter so much? There are so many variables involved. I haven’t experienced any issues with my communities relating to speed and the loading of pages. Nor have my members, and they’re the most important judge in my opinion as they use my site.

[EliasM]

Don't you know that the speed of the site is very important for search engines and the user, and when we complain, it means that it certainly affects the search engine and the user experience negatively.

[Hatsu]

Do your users actually complain about the speed?

[KT Walrus]

Two biggest possible areas for increased performance is to use SQLite instead of MySQL for app data and to use FrankenPHP in worker mode for the webserver. 

I’m working on a new Invision app that uses both these technologies and so far, things are very fast. With SQLite being an in memory database, this is a game changer for CRUD apps. 

Only issue for me is that the rest of IC5 still uses MySQL and it will take me a while to move these queries to SQLite, especially the config and theme templates. I plan to do this gradually over time, until my full site uses only SQLite. 

I don’t use any of the included IC5 apps so it is easier to use SQLite for my app’s data. I’m using the Laravel’s Illuminate/database composer package for querying SQLite databases in my IC5 apps. 

Maybe Invision should save lots of money and move Invision Cloud installations to use per installation SQLite databases? Since a SQLite database is just a single file, backups and restores are very easy and lightning fast. 

[Jim M]

1 hour ago, EliasM said:

Don't you know that the speed of the site is very important for search engines and the user, and when we complain, it means that it certainly affects the search engine and the user experience negatively.

While the answer is "yes, performance is a factor of SEO", it is not THE sole factor. If you have horrible content but a performant page, you aren't going to rank higher. 

Performance is something to keep in mind and bring up when you're testing but I think the key thing is not get obsessed and bogged down on particular results. Especially, with a tool that is impacted by so many other things like Google Pagespeed.

If you're also not testing in a production environment, these are considerations to also keep in mind as Pagespeed factors in items which are impacted by the server.

[EliasM]

19 minutes ago, Jim M said:

While the answer is "yes, performance is a factor of SEO", it is not THE sole factor. If you have horrible content but a performant page, you aren't going to rank higher. 

Here we are comparing version 4 and version 5, version 5 compared to version 4 is very bad in terms of speed, both in terms of search engine and user experience,

This applies only to a site that has a lot of data and has been upgraded from version 4, not a new installation

So far, a lot of errors appear in the upgraded sites compared to the new installation, as it does not contain these errors

[Jim M]

1 minute ago, EliasM said:

Here we are comparing version 4 and version 5, version 5 compared to version 4 is very bad in terms of speed, both in terms of search engine and user experience,

This applies only to a site that has a lot of data and has been upgraded from version 4, not a new installation

So far, a lot of errors appear in the upgraded sites compared to the new installation, as it does not contain these errors

I would encourage to post information about the slow down then rather than Google Pagespeed. What is causing it? If you're having MySQL slow downs due to queries, post the slow log as that is definable information our developers can ingest and see if there is an issue on our end 🙂 .

As mentioned though, there is a lot involved on the server end. Ensure that your server is performing like a production instance to ensure your comparison of V4 to V5 is accurate. Also, ensure you're not making large changes, i.e. adding more blocks to a page or something similar which may (prior to caching) cause a performance hit.

Ultimately, we want to help you and avoid scaring people with grand, vague statements. If there's an issue, let's work together to fix it 🙂 .