Adlago

If you use the image deferral method described above, then the script I use has a new version. In this new version there is a possibility to set different time for delayed loading images - for mobile and desktop. From many tests I have found that for desktop enough time to delay images is in the range of 100 - 600 milliseconds, while for mobile this interval is from 1500 to 3000 milliseconds. Of course, these times depend on the amount of images used on each site. Ie Using the above-described changes in image loading codes and a new script, you can adjust the image delay time for mobile and desktop to achieve the optimally good result. If you are interested, send me a PM and I will give you this script as a gift. Of course this is just for you.

Usually the widgets themselves do not delay loading a site. Delays cause images in these widgets, as well as avatars.

Try and create a new theme - manual mode. Put in Custom CSS on a new theme all the personalizations of, for example, a dark theme. Check for issues.

ops

I also hope in 4.5 that this is resolved. Particularly for mobile - for the desktop and now easily achieve results tending to 100.

A few questions: 1. What part of the root_library.js used on mobile? 2. Is it possible for a mobile to use a small root_library.js with what is needed. Why I ask - I do the test. From the source code of my site I created an html file. I removed the root_library.js in this html file. The PSI test mobile loading speed has increased by over 15 points and at least for my test I am reaching levels of 94-96 commensurate with desktop levels normally tests. When loading this html file with my phone - everything looks good. thanks

If the manifest.json file is a real existing file in root, this will help. But in the IPS suite, a manifest.json is created with this command <link rel="manifest" href="{url='app=core&module=system&controller=metatags&do=manifest' seoTemplate='manifest'}"> ie it is not possible to use crossorigine directly, i. produces an error.

I did 10 tests - by placing this link in a browser address https://www.celiac.com/articles.html/a-word-on-gluten-and-beer-r790/?page=3 The result is always https://www.celiac.com/articles.html/a-word-on-gluten-and-beer-r790/page/3/ I did this test with 3 browsers - Mozilla, Chrome and Chromium, under Ubuntu 16 OS. All tests are out of the issue. I think - is this not a issue on your computer? Have you cleared your browser cache and cookies?

Save the original file to your computer. Save this content that I uploaded above as a .htaccess file. Replace the file in the root directory with the new file.

Try this <Files 403.shtml> order allow,deny allow from all </Files> <IfModule mod_rewrite.c> Options -MultiViews RewriteEngine On RewriteBase / RewriteCond %{REQUEST_FILENAME} !-f RewriteRule \.(jpeg|jpg|gif|png)$ /public/404.php [NC,L] RewriteCond %{REQUEST_FILENAME} !-f RewriteCond %{REQUEST_FILENAME} !-d RewriteRule . /index.php [L] </IfModule> deny from 68.4.204.157 # php -- BEGIN cPanel-generated handler, do not edit # Set the “ea-php54” package as the default “PHP” programming language. <IfModule mime_module> AddHandler application/x-httpd-ea-php54 .php .php5 .phtml </IfModule> # php -- END cPanel-generated handler, do not edit

This file is located in the root directory of your forum. Exact name .htaccess

Share the contents of this file here / or attach it / for advice

Check the htaccess file - there may be a rule in this file that causes the driver error

IPB 3.4.x with a PHP higher than 5.6 create a driver error.

You should have an option in the PHP in cPanel - you now see the latest update for your account, but your server should have older versions as well - search for something like Manage PHP and switch to a lower version. You can try and add this line to your htaccess file AddType application/x-httpd-php56 .php

Which PHP version does your site have? You probably use with IPB 3.4.x and should not meet PHP higher than version 5.6. Check in cPanel - which is the active PHP version.

I also have Redis Cache = 0. I made ticket support to my host company. They did an analysis and here's what they answered: ====== " We have reviewed your request and confirm that Redis is being used effectively. We cannot confirm the reason for the administrative part of the site to write "Cache: 0", but we assume that this module sends a request to one of the bases available in redis. The keys and their values are distributed in different bases, such as they are stored, as you can see in the screenshot - many sessions. We checked the information directly in the redis port for your user, successfully accumulating objects, and we see that even the cache hit rate is high enough for MISSs: keyspace_hits: 147352670 keyspace_misses: 3603491 In conclusion - we see that the system correctly uses Redis and from the point of view of the hosting environment there is no obstacle to its optimal use. " ==== I think these analyzes confirm what @bfarber said, ie. no issue with redis cache = 0.

Isn't that the same issue? Didn't find a solution?

When using the cloud - the main Apache server and the Nginx cache server - there is a issue - if you remove the cache site with ACP , it removes the cache to the Apache server - but not the Nginx server cache - which creates an unpleasant guest experience - until the set time for the Nginx recache passes. Did you analyze this?

I think if IPS creates a cookies-free domain admission for manifest file, then it will improve the YSlow of the loading site, which will actually improve the overall loading speed of the site. And this is very tangible and important for mobile loading - which has recently been tolerated by all search engines, led by Google

Because "<link rel="preconnect"> informs the browser that your page intends to establish a connection to another origin, and that you'd like the process to start as soon as possible."

I have now made the experiment you suggested. On my site there is no difference in the different tests I made. Ie adding that doesn't make sense. There will only be improvement for ISlow if IPS adds the link loading manifest to work with a cookies-free domain as well. Here is a picture of my test without this preconnect ( the same with preconnect). But you pay attention - after many experiments and splitting of different templates, as well as finding the exact location of Google's code analytics, as well as a new script to delay loading images, after a time of "onload" - I have achieved maximum reconciliation in resources and acceleration loading site.

Test your site https://www.virustotal.com/gui/home/url

Now I'm looking at his theme in the developer tool Chrome browser

PS. D'ont remove all this code .site_intro, only row display:flex; but add code #elLogo img ...