Adlago

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

In this topic, @ASTRAPI made a detailed description of what is and what the first byte contains, for which I thank him. For a few months now, I've been doing a lot of first byte analysis and testing in my installation. Here are the results I get - pay attention, these results are when tested with a Chrome browser developer tool and I only look at the waiting time, ie. real time in which the server started to work after request, and produces source code. Sorted as my stats, the results (probably over 1000 test) look like this: 70% - waiting time in the interval 90 - 150 ms 20% - waiting time in the interval 150- 400 ms 8% - waiting time in the interval 400- 1000 ms 2% - waiting time in the interval over 1 second, often over 2 seconds I created a ticket for my host company because my host plan is expensive and with good parameters guaranteed. The guys from the host company have done more than 24 hours of analysis and here's what they found Below I post their response. ====================== In one of the many checks that it develops, we notice that "sleep" during loading and run all that are generating source code scripts. To look at the sleep effect of the application, apply a sample of the command that checks all file calls (at system level) during site loading: 16:03:15.969084 open("/home/database/public_html/system/Session/Front.php", O_RDONLY) = 4 16:03:15.970734 open("/home/database/public_html/system/Session/Session.php", O_RDONLY) = 4 16:03:15.971749 open("/home/database/public_html/system/Theme/Theme.php", O_RDONLY) = 4 16:03:16.983086 open("/home/database/public_html/system/Node/Model.php", O_RDONLY) = 4 After executing the /home/database/public_html/system/Theme/Theme.php file, we see that it is almost a second before the next script is loaded and /home/database/public_html/system/Node/Model.php. For more precision, we see that Theme.php started its implementation at 16: 03: 15.971749, and a second later, at 16: 03: 16.983086, the Model.php implementation started. This second delay is due to the following snippet of Theme.php code: /* If we don't have a compiled template, do that now */ if ( ! $cachedObject and !isset( \IPS\Data\Store::i()->$key ) ) { /* It can take a few seconds for templates to finish compiling if initiated elsewhere, so let's try a few times sleeping 1 second between attempts to give the compilation time to finish */ $attempts = 0; while( $attempts < 6 ) { if ( $attempts === 5 ) { /* Rebuild in progress */ \IPS\Log::debug( "Template store key: {$key} rebuilding and requested again ({$app}, {$location}, {$group})", "template_store_building" ); /* Since we can't do anything else, this ends up just being an uncaught exception - show the error page right away to avoid the unnecessary logging */ \IPS\IPS::genericExceptionPage(); } $built = $this->compileTemplates( $app, $location, $group ); if ( $built === NULL ) { $attempts++; sleep(1); } else { break; } } /* Still no key? */ if ( ! isset( \IPS\Data\Store::i()->$key ) ) { \IPS\Log::log( "Template store key: {$key} missing ({$app}, {$location}, {$group})", "template_store_missing" ); throw new \ErrorException( 'template_store_missing' ); } } This part of the code checks whether a compiled template is already available and if not, compiles. Several attempts are made in the compilation process, which according to the code comment may take a few seconds. In our opinion, the presence of sleep (1) is the specific reason for the delay sometimes occurring. For our part, we might recommend that you consult the developers who assisted with the site's construction. From our many attempts to reproduce the delay, we see that to a large extent the site is well optimized, but rebuilding templates is a functionality that needs to be discussed with developers. In our view, this part of the code is the reason for the TTFB indicator's unconscious state, since it directly depends on the time it takes to process all the functionality involved in generating the source code. ================================== Whether these guys from the analysis department of my host company are right - I don't know. I share it here and look forward to clarification. Thanks.

And why not a men's theme and a default women's theme as well?

The content that is generated from the manifest file is now the following "scope": "\/", "name": "...", "theme_color": "...", "short_name": "...", "start_url": "\/", "description": "...", "background_color": "...", "display": "standalone", "icons":... These settings are made when activated and very rarely are subject to change. There is nothing stopping when a site administrator chooses to use a cookie-free domain, loading a manifest file should also be from that domain. When a cookie-free domain is used now, links in the contents of a manifest file (for android chrome icons) are generated with an address for a cookie-free domain - and there is no issues. So I think loading a manifest.webmanifest file from a cookie-free domain will create an improvement. PS. You can check - the contents of my manifest file are loaded without issue when loaded with a link cookie-free domain https://str.nophelet.com/manifest.webmanifest/

Yes, I read these articles. They look at specific site architectures, and probably used a cookie-free domain before optimizing this site - If use a cookie-free domain if the site was not optimized - images, css and js, html5 errors, and more is really pointless and has no effect. A cookie-free domain only makes sense when everything else on the site is optimized - ie. used at the end of the optimization process, or then used by CDN - depending on site need. In my observations and analysis of different sites using the IPS suite, after site optimization, the use of a cookie-free domain improves site performance and speed, especially for PSI tests relevant to sites using Google ads and other sources.

Cookie-free domain is free, ie anyone can create it on their own server and they will not pay for it. http2 is a very good working protocol. But besides the fast loading site there are other things. A cookie-free domain , for example, improves the YSlow and consequently the overall performance. When analyzing with Pingdom, at least for my site, perfor incremance ased by 5 points.

There is no logic when all resources are loaded by a cookie-free domain, incl. and links from the contents of the manifest file, to load the manifest file from the main domain ... I have no problem with speed loading, just I share what I notice - and here's to see for yourself - how to load a manifest file. And yes, I use 100% keep-alive

When a cookie-free domain is used, all resources are loaded by that cookie-free domain, including links in the contents of the manifest file. But, the initiator for loading manifest.webmanifest does not change and manifest is loaded from the primary domain. This causes: - DNS lookup - new connecting - new SSL, or about 200 ms delay for loading manifest file. If possible, include a cookie-free domain for loading manifest file, when used - this will speed up the loading site. Thanks

I suggested it be an option in ACP, as I assumed there would be objections, as it happened. This resource very rarely changes after its creation. I have run expires time tests of 2 days, 3 to 6 days, but the only minimum expires time for this resource is 1 week is considered correct by several test servers - GtMetrix, WebPageTest and others. If you decide that this exipres time should be fixed, then it should be 1 week.

I do not propose a fixed for 1 week - but the addition of an option in ACP with an expiration time at the discretion of the administrator. When was the last time you modified your manifest file?

I know that. Therefore, the main idea of this topic is: That's what I researched and wrote. On my site, an expiration time of 1 week is good. If I make changes to this file, I can still turn on 0 seconds and make changes, once I see well-functioning new things, I will still include 1 week. But if the cache expires time for this file exists as an option with values of 0 sec 1 day 1 week and 1 month, it will be easy and convenient for any administrator to make their choice.

I'm not sure what you are saying. Please explain. Thanks

With 1 week (604800) value is perfect. I did a test with several test servers.

I add in my htaccess file # Manifest files AddType application/manifest+json webmanifest AddType application/x-web-app-manifest+json webapp AddType text/cache-manifest appcache <IfModule mod_expires.c> # Manifest files ExpiresByType application/x-web-app-manifest+json "access plus 0 seconds" ExpiresByType text/cache-manifest "access plus 0 seconds" </IfModule> I tried with 1 week, 1 month - also without change. My manifest file is in root directory with permissions 0644

That's how experts advise - not just on the site linked. Personally, I would try for a 1 month expiration time.

I'm not sure because all the experiments I've done with the htaccess file do not change the expires time. If I trust these recommendations here - the expiration time should be 0 seconds. But even these tips implemented in htaccess file do not change the expires time. If you point me to which file I make a change - I could experiment and write here for a result.

5 months ago I created such a topic in Client Lounge I confirmed @bfarber moving the topic to this section - but this does not seem to have happened. This file is rarely changed. The cache does not need to be only 24 hours. This is probably fixed in the output php or somewhere else. This expires time cannot be changed with a htaccess file - I've tried all the options found on the web. Please put in ACP an option to change expires time to this cache. Thanks.

This issue is not in the CKEditor, but in the reCaptcha. After many analyzes of the CKEditor, I decided and stopped a recaptcha in my site. Site loading speed is restored as very good with CKEditor enabled. After turn off the recaptcha and do a test, for me is OK. I see in tests that this site does not use a recaptcha, too ... And this issue does not exist here. It's weird that you offer this feature to prevent Spam, but you don't use it. Why we need to waste time analyzing too poorly performing function from external servers .... It is very disappointing ...

When guest publishing permission is enabled, 21 additional requests to external servers are added to load the CKEeditor. This provides a significant slowdown in site loading speeds - more than 25 points in PSI test measurements. Here is an example of all additional requests. Please look for a normal solution - this solution that you use is appalling.

In this case, the "userPhoto" is loaded through a template core_front_system/searchResult and probably has no connection to the this JS in a global template. PS. In your forum this is already fixed.

Yes, you are right. I reviewed everything again and there is no issue with new version which is below. Including. I go back to data-src because the validator html5 finds an error in the argument dota-src. 1. Create a blank template name 'onload_av' in a group of 'analysis' as I already showed you in other topic. 2. Place this script on this template, and Save. <script> function init() { var imgDefer = document.getElementsByTagName('img'); for (var i=0; i<imgDefer.length; i++) { if(imgDefer[i].getAttribute('data-src')) { imgDefer[i].setAttribute('src',imgDefer[i].getAttribute('data-src')); } } } window.onload = init; </script> 3. Open globalTemplate and place bottom after {template="includeJS" if="theme.js_include == 'footer'" app="core" group="global" location="global" params=""} this {template="onload_av" app="core" location="global" group="analysis" params=""} 4. Open template core_front/userPhoto and replace the entire code with {{if $member->member_id and \IPS\Member::loggedIn()->canAccessModule( \IPS\Application\Module::get( 'core', 'members' ) )}} {{$memberURL = ( $warningRef ) ? $member->url()->setQueryString( 'wr', $warningRef ) : $member->url();}} <a href="{$memberURL}" {{if $hovercard}}data-ipsHover data-ipsHover-target="{$memberURL->setQueryString( 'do', 'hovercard' )}"{{endif}} class="ipsUserPhoto ipsUserPhoto_{$size}{{if $classes}} {$classes}{{endif}}" title="{lang="view_user_profile" sprintf="$member->name"}"> <img src='{expression="\IPS\Text\Parser::blankImage()"}' data-src='{$member->photo}' alt='{$member->name}'> </a> {{else}} <span class='ipsUserPhoto ipsUserPhoto_{$size} {{if $classes}}{$classes}{{endif}}'> <img src='{expression="\IPS\Text\Parser::blankImage()"}' data-src='{$member->photo}' alt='{$member->name}'> </span> {{endif}}

Why lazy load is missing I have no answer, but if you want to speed up your site, I suggest you 'onload' loading avatars images. Please see the edit below. I'm sorry for the inconvenience.

The mobile version can become very fast if IPS changes the concept of CSS rules. If CSS basic rules are created for mobile version, the responsive design only contains changes to the desktop, for example ... .ipsRule {....} @media screen and (min-width:768px) {.ipsRule {...}} @media screen and (min-width:980px) {.ipsRule {...}} @media screen and (min-width:1280px) {.ipsRule {...}} @media screen and (min-width:1440px) {.ipsRule {...}} etc using a media query with only min-width will shorten the volume of CSS and improve the performance of browsers while processing CSS rules. But, in this version 4.5, I think this will not be done.

PS. I'm not sure if this was any reason for poor performance, but after this change, my performance increased by 7 points - from 84 to 91 on the Lighthouse test report...