Adlago

This missing in your source code. Check it. =================================== You have incorrectly followed this instruction of mine. Yes script is missing before </head> but you did not put it below where I indicated. ======== Using a cookies-free domain will improve Yslow in loading your site. Instructing and implementing this is more complex, and I doubt if you will be able to follow it accurately. I will wait to you add correctly the previous tips.

Yes, I can write you a cookie-free domain instruction, but tomorrow night.

@Gauravk Before </head> you load this script <script type="9b96b7e963e1da54ba1fa8c3-text/javascript" src='https://carnity.com/applications/cms/interface/external/external.js' id='ipsWidgetLoader'></script> Move it down, after </footer> before {template="includeJS"if="theme.js_include == 'footer'" app="core" group="global" location="global" params=""}

I will test your site a little later and if I have any idea I will write.

Well, here's an easy-to-use option that will make the results smile for you. 1. Create a new template with this data (in your theme) 2. Open template core_global_analysis/preload_css, and put this {{foreach array_unique( \IPS\Output::i()->cssFiles, SORT_STRING ) as $file}} <link rel='preload' href='{expression="\IPS\Http\Url::external( $file )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style"> {{endforeach}} {{$customCss = \IPS\Theme::i()->css( 'custom.css', 'core', 'front' );}} {{foreach $customCss as $css}} <link rel='preload' href='{expression="\IPS\Http\Url::external( $css )->setQueryString( 'v', \IPS\CACHEBUST_KEY )"}' as="style"> {{endforeach}} 3. In your global template, before {template="includeCSS" app="core" group="global" location="global" params=""} put this {template="preload_css" app="core" location="global" group="analysis" params=""} 4. Create new template pleload_fnt - as I mentioned earlier 5. Open core_global_analysis/plreload_fnt, and put this <link rel="preload" href="/applications/core/interface/font/icomoon.woff?v=-29n77j" as="font" type="font/woff" crossorigin="anonymous"> <link rel="preload" href="/applications/core/interface/font/fontawesome-webfont.woff2?v=4.7.0" as="font" type="font/woff2" crossorigin="anonymous"> 6. In your global template, after close footer (</footer>), before {template="includeJS"if="theme.js_include == 'footer'" app="core" group="global" location="global" params=""} put this {template="preload_fnt" app="core" location="global" group="analysis" params=""} 7. Remove cache site, and do tests I'm applying one more idea - I'm adding a script that delays loading images after onload time (it's not a lazy load - I don't like a lazy load) With this script, I postpone images loaded with img src as well as background images, incl. those that load with SuperGrid, for example, by splitting up time for mobile and desktop. With a desktop, it takes a little delay time, while a mobile one needs a delay of about 3 seconds. But this is much more complicated to instruct, and I usually only do it when I spend a lot of hours analyzing a site. PS. Write about the results after applying what I wrote above.

You may have put in a block, or in global template code without the "}" Share a link to a site and someone will easily find the error.

Calendar - missing „eventAttendanceMode“

All this reports for PSI, is solved with elemental optimization - the exception is only unused css.🙂

Can you be more specific please. Here is the performance test of this forum now Do you envisage a reduction in the css package for mobile, which is now a measurement parameter for unused css.?

You have one bad request - this If you are worried about a PSI test speed report - it might be a good idea to add preload-css to your head. This will eliminate the PSI report, and you will get better results in a report. If you are interested, I can write here an instruction how to do it. PS. Remove errors validation html5 also improves website functioning https://validator.w3.org/nu/?doc=https%3A%2F%2Fcarnity.com%2F PS2. Take a look at this test - here you will find many factors that delay your site. https://yellowlab.tools/result/flq7nrg1fi

Also check out how a developer tool sees loading your site for mobile.

Yes, a very long waiting time. How many html size does your site create Do you use a guest cache page? It is possible for some of your applications to create a server delay in the creation of html. You can test your server with a simple html file in the root directory and compare the same time waiting server response.

View fragments Invalid object type for itemReviewed "Search Console now maintains a new advanced report for review fragments. This report shows any issues with tagging the review fragments found by Google on your site."

I also recommended this - but in this case, I only did help to a friend ...😀

This is found in ipb 3.4.x - A few hours ago I made such a change to a one site with this PP. Now I checked - Google check is OK.

In my test, your site has the same issue with waiting time. This is after my 3th test

Do you have these results in several consecutive tests - example 5 tests through 1 min. Thanks

In my site I use cache block time of 16 minutes. In 16 minutes I do more than 10 tests as above - all tests are in the range of 90 - 900 ms. Ie this cache is unaffected. I do not use the guest cache page - ie. and this does not affect me in the test. If this happens within the 10 minute test interval - for a test every minute, then only one of the tests will be affected. But this is not observed. Ie this is not the reason for the unclear game of waiting time. If this game only happens on my installation - yes, I'll be happy to create a ticket. But I test many sites with different servers and at a different distance from me as a client to a server. This waiting time on all the sites I've tested is throbbing in the same vague way. That's why this topic is ... Look and if you can find a reason ... Before creating this topic, I have done thousands of tests, incl. and a few tickets to my host. I wrote in the beginning about what the host replied. Also, I have checked and tested sites with another software platform - I was looking for a similar amount of CSS and JS and content ... And yes, the overall status of these sites, according to test server readings is average - but the weird thing is that waiting time to test such sites varies from 100 - 190 ms, and very rarely up to 300 ms ... But your platform with so many benefits failed in the first byte about a year ago, and it continues. I'm sorry if this offends you, but these are my observations - and they are not a small amount ...

For a sleep -this is the opinion of my host company. There may be another reason. In the last hour I have screenshots from tests on this site with over 1 second waiting time. If you want I will post them. Although you too can get such results. In these cases, the distance from the client to the server does not matter, because the time we are discussing is the running time of the server after it is connected for create html. I will repeat myself again - in the process of producing html there is some problem - it is not correct to have such a wide range for waiting time. And what causes this - I would be glad to know, but since May 2019 I have not found one yet. In the previous version before May 2019, there was no such ripple of this waiting time ...

@bfarberThese are the tests for your site from the Chrome browser console. 5 tests every minute. How will you explain this wide range of waiting times? This is observed in all sites using version 4.4.x - a large range of waiting time - you use the CDN and it happens again. Other sites use the one server - no matter Apache or Nginx- the results are the same, great waiting time game ... There is some mistake, I think, when creating an html file , what is it I don't know.

Please check the whole logic for this. More than 2 hours - I changed sleep from 1 second to 100 ms using usleep. More than 95% of my first byte (waiting time) are excellent - 90-140 ms, in other cases they are from 200 to 500 ms. Probably the logic of what you say does not work of plan.

I have more test observations - but with Christmas calm in the forum, it's a weird 900 ms waiting time ...

Now I've tested your site - the same first byte behavior - from several tests in 5 minutes, and in your site the first byte changes in the interval from 50 to over 800 ms. And it is a waiting time. You use CDN, I'm only Apache - but this first-byte behavior is the same, ie. you have some bug in the source code software. See test screenshots

I have Opcache turned on. These are all PHP modules included. But my host replied that there was no reason other than that already stated. Does it make sense for your research to I create a ticket? This first-byte variable behavior started with me after May - I don't remember which version it was before - but I used this host packet more than 5 months ago - and there was no problem with the first byte. Or any idea what I should change?

thanks I have sent your reply to my host. If they have more questions, I'll add to this topic.