August 16, 2013 at 8:28 am #8652
Give this code a test drive – do benchmark tests with Firefox, Firebug, Firephp and Yslow. You may see a minor website load speed improvement or a significant website load speed improvement.
1. Copy the Speed Boost .htaccess code into this Custom Code text box: CUSTOM CODE TOP PHP/PHP.INI HANDLER/CACHE CODE: Add php.ini handler and/or plugin cache code here and click the Save Root Custom Code button.
2. Go to the BPS Security Modes page and click the Create secure.htaccess File AutoMagic button and then activate Root Folder BulletProof Mode.
NOTES: If you are using a php/php.ini handler in your root .htaccess file then it should also be added/copied to BPS Custom Code. Copy this Speed Boost Cache code below your php/php.ini .htaccess code. If you are using a caching plugin that creates .htaccess caching code then you can also add that plugin’s caching code directly above this Speed Boost caching code. The order of the code is: 1. php/php.ini handler .htaccess code (if you have php/php.ini handler code), 2. caching plugin .htaccess cache code (if you are using a caching plugin) and then this Speed Boost .htaccess code.
You can use the code exactly as is or if you want to see if you can get a couple more milliseconds of speed:
Test using no ETags by commenting out (adding a pound sign #) all the ETag lines of .htaccess code below (#FileETag MTime Size, #Header unset ETag, #FileETag none) and benchmark test website performance, then benchmark test using Header unset and FileETag none (this is currently the default code shown below) and then benchmark test using FileETag MTime Size (uncomment FileETag MTime Size and comment out #Header unset ETag, #FileETag none). Whichever ETag combination/choice makes your website perform the fastest is the one you want to use/keep. On Go Daddy it seems that using Header unset ETag and FileETag none is slightly faster in milliseconds (as shown below).
Testing examples explained above are here: http://forum.ait-pro.com/forums/topic/htaccess-caching-code-speed-boost-cache-code/#post-9707September 10, 2013 at 4:26 pm #9547
Question copied from another topic to this relevant topic:
Whichever ETag combination/choice makes your website perform the fastest
On Go Daddy it seems…
Do you have practical knowledge what’s best on 1and1 managed servers?
NaneSeptember 10, 2013 at 4:27 pm #9550
Nope, each person will have to test whichever works best for their Host and if you want to post back here that would be great to help other folks out.September 11, 2013 at 6:54 am #9593
Hi, i don’t understand what i must do it.
Can you clarify, what i must do?.
Thanks in advance.September 11, 2013 at 7:38 am #9594
Watch this Custom Code Video Tutorial. If you still have any questions after watching the video tutorial then post those questions.September 13, 2013 at 4:57 pm #9705
I have been dicking with this for half a day trying to figure out what I’m supposed to comment out/in. I don’t get it and the video was no real help. Remember, most of us are not engineers or have degrees in computer science. What is “Header unset” and ”FileETag MTime Size” and what does it look like in that list of code or in short WTF am I doing.
Just goes to show you if you don’t put it layman terms, so everyone can understand it, you get a lot of stupid questions.September 13, 2013 at 6:28 pm #9707
Ok let me try and make this a no-brainer.
The first test should be done with all of these things below commented out with pound signs #
# Test which ETag setting works best on your Host/Server/Website # with Firefox Firebug, Firephp and Yslow benchmark tests. # Create the ETag (entity tag) response header field #FileETag MTime Size # Remove the ETag (entity tag) response header field #Header unset ETag #FileETag none
The next test should be done with these things commented out
# Test which ETag setting works best on your Host/Server/Website # with Firefox Firebug, Firephp and Yslow benchmark tests. # Create the ETag (entity tag) response header field FileETag MTime Size # Remove the ETag (entity tag) response header field #Header unset ETag #FileETag none
The final test should be done with these things uncommented/commented out because most likely this is going to be the optimum choice.
# Test which ETag setting works best on your Host/Server/Website # with Firefox Firebug, Firephp and Yslow benchmark tests. # Create the ETag (entity tag) response header field #FileETag MTime Size # Remove the ETag (entity tag) response header field Header unset ETag FileETag noneSeptember 23, 2013 at 8:07 pm #10084
So the first step is to test the code.. having all the *test instructions disabled with the pound symbol “comment out”.
And what are we to observe after this step?
Step 2, same thing only this is enabled (FileETag MTime Size) by the removal of # comment tag.
And again, why are we doing this or what am I to observe from this test?
Step 3: Is even more confusing, we are suppose to enable or disable what? You have only requested that we enable the one line of code in step 2, and somehow we should know what to disable or enable. How does step one, (no changes) and step 2 lead to step 3′s list of optimal settings?September 24, 2013 at 10:26 am #10105
@ Zac – Ok how about this for simple: Use the code exactly as it is and it will work fine. Benchmarking speed testing would be done using Firefox and these Firefox add-ons: Firebug, Firephp and YSlow. This is actually not really necessary because the difference in speed is going to be only a couple of milliseconds difference max, so therefore it is not really necessary to benchmark test for a speed differences since a couple of milliseconds is going to be completely insignificant for most folks. Some folks care about a couple of milliseconds, but most do not. ;)October 14, 2013 at 1:32 am #10506
Look you guys are brilliant. You have kept my sites hack free for 2 years and counting now! [knock on wood], but you are not the most user friendly designers. You basic security plugin is a nightmare for novices. Think ONE CLICK.
This is a perfect example. I gave up on your speed fix, after having broken a couple of sites. The restore wasn’t a problem, but it points out that you need this in a plugin with a single click interface. I won’t mind paying for it – but keep life simple for those of us that have to maintain our sites.October 14, 2013 at 8:49 am #10524
@ Tim McGuinness – we have taken your thoughts into consideration. Thank you.
You must be logged in to reply to this topic.