.htaccess Recommendations
https://gtmetrix.com/ notes that redirects are the largest culprit in slowing down my page loads

gtmetrix.com's &quot;suggestion&quot; in this regard is arguably &quot;incorrect&quot; (or rather, not nearly as serious as it implies), assuming you are already consistently linking to the canonical URL*1 throughout your site (and you have no other redirects in your application code). These redirects are only likely to affect a &quot;very small fraction&quot; of your site visitors on their very first visit.
(*1 Canonical URL being HTTPS + non-www + no .html extension.)
You have 3 external redirects in the .htaccess code you posted:

#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^(.*)$ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www.example.com [NC]
RewriteRule ^(.*)$ https://example.com/$1 [L,R=301]

#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ /%1 [NC,L,R]


If you have implemented HSTS then you need to redirect from HTTP to HTTPS on the same host, before canonicalising the www subdomain - which is what you are doing above in the first rule. This is a requirement of HSTS and the &quot;preload list&quot;. So you cannot avoid having at least 2 redirects (worst case) in this scenario.
However, if you have no intention of implementing HSTS then you can combine the first two redirects into one. Which you can do by simply reversing the order of the first two rules. For example:
#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The first rule, that redirects www to non-www, also redirects to HTTPS, so there is never a need to execute the 2nd redirect as well. So, there is only ever 1 redirect to canonicalise HTTPS and non-www.
I also removed the redundant capturing subpattern (ie. (.*)) in the &quot;HTTP to HTTPS&quot; RewriteRule pattern, since you are using the REQUEST_URI server variable instead. And changed the other &quot;www to non-www&quot; redirect to be consistent. Note that the REQUEST_URI server variable contains the full URL-path, including the slash prefix, whereas the captured backreference omits the slash prefix.
The above two rules could be combined into a single (marginally more complex) rule, but there is no benefit in doing so.
The rules could also be made more &quot;generic&quot;, without having to explicitly state the canonical hostname. However, how you implement this and whether this is easily possible is dependent on whether you have other subdomains or not. But again, this serves no &quot;benefit&quot;, other than being more copy/pastable. Generally, it is preferable to be explicit here - less prone to error.

#URL EXTENSION REMOVAL
RewriteCond %{THE_REQUEST} /([^.]+)\.html [NC]
RewriteRule ^ /%1 [NC,L,R]


You can also avoid the .html &quot;extension removal redirect&quot; from triggering an additional redirect by including this redirect first (before the above two canonical redirects) and redirecting directly to HTTPS and non-www (the canonical scheme+hostname) as part of the redirect.
UPDATE: This should also be a 301 (permanent) redirect, not a 302 (temporary) redirect that it is currently. A 301 redirect is cached by the browser by default, so it avoids unnecessary round trips to the server. When you don't explicitly include the status code with the R flag, it defaults to a 302.
The NC flag is also not required on the RewriteRule directive, since you are not matching anything here that is case-sensitive.
This rule to remove the .html extension probably works OK for your URLs, however, it's not necessarily correct and could possibly be made more efficient. The reason for checking against THE_REQUEST server variable, as opposed to the RewriteRule pattern or REQUEST_URI server variable is to avoid a potential redirect loop by preventing rewritten requests from being redirected. This is because THE_REQUEST does not change after the request is rewritten - it contains the first line of the HTTP request headers. However, THE_REQUEST also contains the query string, so it's possible for a legitimate request that contains .html as part of the query string to be incorrectly redirected.
For example, request example.com/?p1=foo.html&amp;p2=bar (the homepage with a query string and URL parameters containing the value foo.html) and this will be incorrectly redirected to example.com/?p1=foo, truncating the query string.
The regex /([^.]+)\.html will also fail to match any URL that contains dots as part of the URL-path in places other than the file extension. eg. A request for /foo.bar.html would not be redirected. Although this may be perfectly OK for the URLs on your site.
To avoid these &quot;incorrect&quot; redirects you could capture the URL-path from the RewriteRule pattern instead and either use a simpler condition and check against THE_REQUEST (to avoid a loop) or use the REDIRECT_STATUS environment variable instead, which is always empty on direct requests.
For example:
#URL EXTENSION REMOVAL
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule (.+)\.html$ https://example.com/$1 [NC,R=301,L]

This captures the URL-path before the .html file extension using the RewriteRule pattern (which naturally excludes the query string). The simple condition that checks the REDIRECT_STATUS env var prevents a redirect loop.
Bringing the above points together we have:
#URL EXTENSION REMOVAL
RewriteCond %{ENV:REDIRECT_STATUS} ^$
RewriteRule (.+)\.html$ https://example.com/$1 [NC,R=301,L]

#FORCE WWW TO NON-WWW
RewriteCond %{HTTP_HOST} ^www\.example\.com [NC]
RewriteRule ^ https://example.com%{REQUEST_URI} [L,R=301]

#REDIRECT TO SECURE HTTPS CONNECTION
RewriteCond %{HTTPS} off
RewriteRule ^ https://%{HTTP_HOST}%{REQUEST_URI} [L,R=301]

The NC flag was not required in the &quot;URL extension removal&quot; redirect.
This now triggers at most 1 redirect regardless of whether a request comes in for HTTP, www or includes the .html extension. However, as noted, this is at the expense of not satisfying the requirements for HSTS.
And it should be noted, that in real terms, there may not be a perceivable difference between 1, 2 or even 3 redirects here. Particularly since it will not affect the vast majority of visitors anyway.

Additional:

#REDIRECT FOR DATE PAGE
Redirect /date /storage/date-202010

#REDIRECT FOR HOME PAGE
Redirect /home /


Generally, you should avoid mixing redirects from both mod_alias (Redirect / RedirectMatch) and mod_rewrite (RewriteRule). The two modules run independently and at different times during the request, despite the apparent order of the directives in the .htaccess file.  mod_rewrite runs first. So, you can get unexpected conflicts.
Note also that Redirect is prefix-matching and everything after the match is appended on to the end of the target URL. eg. /date/foo would get redirected to /storage/date-202010/foo by the first rule. These particular redirects are also 302 (temporary) redirects. It looks like they should be 301 (permanent)?
However, in this case it probably does not matter whether you use Redirect or RewriteRule, but as a general rule, if you are using mod_rewrite for some redirects, then use mod_rewrite for all redirects. For example:
#REDIRECT FOR DATE PAGE
RewriteRule ^date$ /storage/date-202010 [R=301,L]

#REDIRECT FOR HOME PAGE
RewriteRule ^home$ / [R=301,L]



#BLOCKS FILE TYPES FOR USERS
&lt;FilesMatch &quot;\.(htaccess|htpasswd|ini|log|sh|inc|bak)$&quot;&gt;
Order Allow,Deny
Deny from all
&lt;/FilesMatch&gt;


You stated in comments that you are using Apache 2.4, however Order, Allow and Deny are Apache 2.2 directives and are formerly deprecated on Apache 2.4. They still work, but for backwards compatibility only and should be updated as soon as.
Note that you need to update all instances on your system since the newer directives don't necessarily mix well.
On Apache 2.4 you would use the Require directive instead:
#BLOCKS FILE TYPES FOR USERS
&lt;FilesMatch &quot;\.(ht[ap]|ini|log|sh|inc|bak)$&quot;&gt;
Require all denied
&lt;/FilesMatch&gt;

Note that the Apache server config &quot;should&quot; already be blocking direct access to .htaccess and .htpasswd files, but better to be safe I guess.


ErrorDocument 500 /allerror.php


Defining the 500 ErrorDocument late in .htaccess is probably too late to catch most 500 (Internal Server Error) responses (that result from misconfigurations). There's probably not much you can do about this, but it would be preferable to define this earlier in the server config (or &lt;VirtualHost&gt; container) in order to be more &quot;useful&quot;.