One of the most sought-request we have received so far has been the implementation of Mod_PageSpeed.
We have deliberately delayed this as the module is tested for compatibility, performance, and reliability.
Having done some real-world testing for some of the core filters, we will go ahead and enable it for servers located at our Portland, Oregon, Ashburn, North Virginia and Tokyo, Japan data-centers at UTC Coordinated Universal Time 01:00 Mon on Nov. 5th, 2018
Again, it is important to point out that mod_pagespeed is still in a beta offering, its features might change and thus, we cannot completely guarantee that any enabled modules will not conflict with your website existing content.
This will be turned on at:
- UTC Coordinated Universal Time 01:00 Mon, Nov 5
- Wilmington EST Delaware 20:00 Sun, Nov 4
- Tokyo JST Japan 10:00 Mon, Nov 5
But as we also pointed out, it is important to know that mod_pagespeed is still in a beta offering.
It means that its features might change and thus, we cannot completely guarantee that any enabled modules will not conflict with your website existing content or that we will keep enabled permanently.
If we notice that it is triggering issues on customers websites on this server, we will disable it.
You can check your website speed before and after it enabled by going to:
You can see if your website is using Mod_Pagespeed from https://ismodpagespeedworking.com/
curl -D- https://www.domain.com/ | less
If you do see the header, but it doesn't look like PageSpeed is making any changes to your page, it is possible that none of the active filters are finding anything to rewrite.
Try comparing your page with PageSpeed off and with the collapse_whitespace filter enabled:
curl -D- 'https://example.com?ModPagespeed=off' | less curl -D- 'https://example.com?ModPagespeed=on&ModPagespeedFilters=collapse_whitespace' | less
If you experience issues with your website or need to see everything as it is by default or notice that the changes you are making on your website are not reflecting in real time), turn Mod_PageSpeed "Off".
Turning the module on and off
To turn PageSpeed temporarily off, just set this on your .htaccess (Please see the attached mod_pagespeed.txt for examples):
ModPagespeed standby OR ModPagespeed off
If that didn't work, disabled pagespeed in .htaccess and Pagespeed is still running, please insert "?PageSpeed=off" in the URL.
To turn it on again, replace the "standby" or "off" with "on"
WordPress and Mod_PageSpeed
While it is the most popular CMS on the planet, from a developers point of view, WordPress is not the fastest platform out there.
So customers using WordPress often have to use WordPress plugins that deal within minification of JS and CSS files to speed up the application.
Please be careful with these plugins if you are using them on your website along with PageSpeed as they may completely screw up your site and contact forms.
We recommend disabling these first and then gradually adding them back if you must use them.
Be careful using both these tools together as it may take time before the conflicts show up. Test, test, and test again before enabling it fully for your WordPress website(s).
Pagespeed can optimize most common image formats, including GIF, PNG, and JPEG, and convert them to PNG, JPEG, or WebP. GIF, PNG, and JPEG are supported by all browsers.
WebP is a modern image format that can compress images over 25% more than older formats and is currently supported by many browsers, including Google Chrome, Android 4.0+, and Opera. Note that not all browsers support this: https://caniuse.com/#search=webp.
PageSpeed-optimized images are converted to the best format supported by the target browser, i.e., to WebP if it is supported, or PNG or JPEG if not.
I'm A WordPress Use And My Pages Are Blank After Mod_pagespeed.
Disable compression in any WordPress plugin you are using, so that mod_pagespeed will process uncompressed HTML. mod_pagespeed ensures that its output will be compressed by enabling mod_deflate.
PageSpeed May Have Broken My Website - Now What?
First of all, sorry about that.
We put a lot of work into validating our rewriters against a large corpus of websites and we disable filters that cause problems as soon as we can, but sometimes things slip through.
If it's still breaking your site, please try appending ?ModPagespeed=off to the URL.
This deactivates PageSpeed.
If the site is still broken, it is not a rewrite or HTML parsing problem.
If that fixed the site, try appending ?ModPagespeed=on&ModPagespeedFilters= to the URL.
This turns on PageSpeed, but no filters.
If the site is broken now, it is an HTML parsing problem.
If the site still worked, try appending ?ModPagespeed=on&ModPagespeedFilters=foo for various filters "foo".
For example try:
You may have to reload them a few times over several seconds to make sure they have had time to load sub-resources into cache and rewrite them. If one of these breaks your site, you now know which filter is at fault.
Caching & OpCache
Opcache "validate_timestamps" is disabled on our servers for best performance.
With this directive disabled, you must reset OPcache manually via opcache_reset(), opcache_invalidate() or until the server is restarted for changes to the filesystem to take effect.
Yes, it is a pain in the ass, but you should use it.
Well, the problem with deploying new code to a running server is quite simple to understand.
A request that starts on one version of the code might access other files during the request and if those files are updated to a new version during the request you end up with strange side effects.
In PHP you might autoload files on demand when instantiating objects and if the code has changed mid-request the caller and the implementation could easily get out of synch.
To make the above easier, it means that while you're updating or deploying code, new code files may get mixed with old ones — the results are unknown.
So it's unsafe for a production environment.
In a development or staging environment, having "opcache.validate_timestamps=1" and "opcache.revalidate_freq=2" is OK because scripts will be stated on every compile request to see if they are changed.
If you encounter weird problems (making changes and not seeing them), you may need to also tinker with OpCache.
One of the ways to flush OpCache is to add below to your .htacess file:
<FilesMatch "\.(css|flv|gif|htm|html|ico|jpe|jpeg|jpg|js|mp3|mp4|png|pdf|swf|txt)$"> ExpiresActive Off FileETag None Header unset ETag Header unset Pragma Header unset Cache-Control Header unset Last-Modified Header set Pragma "no-cache" Header set Cache-Control "max-age=0, no-cache, no-store, must-revalidate" Header set Expires "Thu, 1 Jan 1970 00:00:00 GMT"
# DISABLE CACHING Header set Cache-Control "no-cache, no-store, must-revalidate" Header set Pragma "no-cache" Header set Expires 0
We strongly recommend that you only edit your configuration files with cPanel's MultiPHP INI Editor interface (cPanel >> Home >> Software >> MultiPHP INI Editor).
Another method of turning opcache off is adding the below to your htaccess:
php_flag opcache.enable Off
Remember that .htaccess files are read from top to bottom, so if you want these directives to occur before something else, then they should be placed higher within your .htaccess file.
Also, it is important to point out that there may be multiple .htaccess files and that .htaccess files placed above another in a directory will have precedence over the one placed in a sub-directory.
Cloudflare & Mod_PagesSpeed
Until we are shown otherwise, we kinda believe that Google's mod_pagespeed and Cloudflare have no known conflicts at this time.
However, that doesn't mean that websites with mod_pagespeed enabled cannot experience issues with domains using the CloudFlare.
If it happens, it is because of the fact that both CloudFlare and mod_pagespeed attempts to use compression when serving the website.
This can often be resolved by disabling compression through CloudFlare to avoid redundancy.
Also, if you have added CSS and JS minifications to your .htaccess file, disable the minify JS and CSS options in Cloudflare since you have already enabled them in Pagespeed configuration.
If you have a web designer or a web developer managing your websites for you, please send this to him or her as s/he will find it more useful and will be able to use this information it contains.
We hope that you will find this tool a great addition to your system and will be looking forward to your feedback.
Sunday, November 4, 2018