Adlago

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...

Thanks for your opinion. I described this problem to my host company and the boys there looked at this thoroughly. They solved this problem. In your command for Cron, you use this /opt/cpanel/ea-php73/root/usr/bin/php -d memory_limit=-1 -d max_execution_time=0 /home/... They changed the command to /opt/cpanel/ea-php73/root/usr/bin/php -c /home/... and it all works like a Swiss watch ...

I have not tested with a new installation. My test site is currently with 4.4.3 beta 2. There is also this issue. I do not use plugins