Management Matt Posted 4 hours ago Management Posted 4 hours ago 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 Posted 4 hours ago Posted 4 hours ago 1 hour ago, Adlago said: I set it to 3 minutes I will try to increase it and check the difference
Adlago Posted 3 hours ago Author Posted 3 hours ago 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 Posted 3 hours ago Posted 3 hours ago 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 Posted 3 hours ago Author Posted 3 hours ago 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 Posted 1 hour ago Posted 1 hour ago @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. TDBF 1
Management Matt Posted 34 minutes ago Management Posted 34 minutes ago 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.
Recommended Posts