In my last article, “Using Google PageSpeed Insights to Analyze Your Web Page Performance” I discussed how a Google product called PageSpeed Insights can examine your website and make recommendations for manual improvements. The counterpart to this feature, Google’s PageSpeed Service can apply those recommendations for you to cut the load time of your pages. This can be a great benefit to your company and the users involved with running the site or administering the content, whether in IT, Marketing or some other group.
What does PageSpeed actually do?
The Google PageSpeed site states that “PageSpeed Service fetches content from your servers, rewrites your pages by applying web performance best practices and serves them to end users via Google’s servers across the globe.” You don’t have to provide Google with any confidential data or administrative access to your website for this to happen; basically your site traffic gets directed through their servers which do the heavy lifting.
Techcrunch.com has a good article which helps break down the benefits of how the PageSpeed Service works. The article states:
Can I get a trial of PageSpeed to see how it will benefit my site?
Right now PageSpeed itself is technically a free trial, but you can use a site called WebPageTest to get concrete information (not a lot of hocus-pocus carnival barker claims) on what PageSpeed will do for you. (Figure A)
All you have to do is enter your website URL, select the location you want to test FROM, and then choose the browser version to use for the test (options include IE6-IE10, Chrome, Firefox, Safari and some mobile browsers). Then click “Start Test.”
For example, Figure B shows the test results for www.microsoft.com.
According to the above screenshot, Google PageSpeed Service could shave a second and a half off load times.
There is a video file available showing the actual load times of the original vs. optimized site so you can visually compare the two. You can also click on “View test” in the “Full Test Result” section under the page load time counts to access the specific details for either the original (as-is) site or the optimized Google version. This brings up a series of images showing statistics for each test run. (Figure C)
In the above example, the W3C Navigation Timing test was conducted seven times on the ORIGINAL site. You can click each of the “Waterfall” images to zoom in and see the exact timing sequences. (Figure D)
(Note for many of these screenshots this is just part of the data shown so that you can get a feel for what to expect).
You can even see CPU Utilization and Bandwidth usage statistics in the test results. (Figure E)
There is a similar Connection View graph next (Figure F), which outlines the manner and sequence in which sites were hit to load various types of data.
Next there is a chart showing the request details and what type of content is delivered. (Figure G)
The test results page (Figure H) will also show you all Request Headers.
Without being tedious, suffice to say that clicking on the “View test” link on the test results page for the OPTIMIZED version of the site (in other words, what Google would give you) will show you corresponding data explaining where the performance is coming from in terms of connection times, data loaded and request details. This will enable you to analyze what’s really going to happen behind the scenes and decide whether this is a service worth moving forward on.
Full documentation for WebPagetest is available if you’re interested in drilling down through all the procedures involved.
How can I start using PageSpeed?
Page-Speed has been in beta form since it was released on July 28, 2011 (Google does have a history of lengthy betas). That means it’s currently invite-only. Right now, it is free, however, if you are approved for use (Google states “it is offered to a limited set of webmasters.”) Pricing information if it moves to a cost-base model has not yet been revealed.
To get started, follow these steps:
Fill out this simple form to request access.
If approved, you then log into the Google APIs console (which is accessible by a link Google will give you) and agree to the Terms of Service.
Provide Google with the name of the domain you want to optimize; e.g. www.mysite.com. You will need to create a DNS TXT record for this domain using a specific verification string Google provides. This confirms you own the domain in question. This is mandatory to use PageSpeed Service.
Provide Google your origin host (the server from which PageSpeed will fetch content for optimization). This may involve creating a new public record for your website such as origin.mysite.com which points to the IP address of your webserver.
Configure a public CNAME DNS record for your serving domain address (the URL users will connect to, e.g. www.mysite.com) to point to pagespeed.googlehosted.com. This means Google receives your website traffic and directs users to your origin host after improving your page response times.
These last two steps can be somewhat confusing, but the following example (Figure I) from Google helps clarify them.
As shown above, in the original configuration www.mysite.com points to 126.96.36.199. In the PageSpeed version, the www record points to pagespeed.googlehosted.com while the origin record (from which Google loads your site) continues to point to 188.8.131.52.
This page describes the setup process in detail.
What options do I have for measuring how PageSpeed is working for me once its running?
The Google APIs console will allow you to operate your site with PageSpeed. You can view traffic, change domains, and modify settings. For instance, the “Overview” section shows you traffic statistics and will let you add a new domain. (Figure J)
The “Configure Rewriters” section (Figure K) allows you to get right into the settings applied to your website, in case you wish to change any of the recommended settings.
There is a “Caching and Errors” section which can be used to monitor performance or flush caches if needed. (Figure L)
Here’s a cool feature! You can specify “block requests,” meaning PageSpeed can keep traffic from your site based on URLs, IPs or user agents. This can be a big plus if you have restrictions in mind which you want to implement, or have already implemented on your website. (Figure M)
Finally, there is an Audit Log section for change logging. (Figure N)
Are there any limitations?
There are some limitations which are important to consider. Here are a few of them:
- If you are unable to create a DNS TXT record to confirm ownership of your domain with Google you cannot use PageSpeed Service. There is another option available from Google called “mod_service” if your site runs Apache, however.
- If Google’s PageSpeed site goes down, traffic to your site will be impacted. You should have a plan in place to update your DNS records accordingly if needed. You may want to examine your TTL (time to live) settings which control how long other hosts cache your DNS records so that if you need to make an emergency adjustment repeat visitors will quickly be directed to the appropriate target host.
- PageSpeed has to be set up for your full domain (e.g. www.mysite.com - if you have a “bare” domain which points to your full domain (e.g. mysite.com) you’ll need to use a server-side redirect (301 redirect) to send traffic to the full domain. This may already be in place for many sites, however.
- PageSpeed will work with secure sites using https but you must contact firstname.lastname@example.org for details on how to set this up.
- Google warns that: “Once a domain is CNAME’d to Google, it is not possible to simply exclude HTTPS traffic from PageSpeed Service. To achieve that, you need to serve your HTTPS traffic from a separate sub-domain that is not CNAME’d to Google. For example, if your site is www.example.com, then serve HTTPS traffic from secure.example.com. If the domain being CNAME’d to Google supports other services (e.g. ssh, ftp etc.), those services will no longer work.”
Faster websites may not be a high priority for everyone, whether a user or a site administrator. A largely text-based site such as Project Gutenberg, which allows you to download free e-books, isn’t going to receive much benefit from PageSpeed Service, nor will the people visiting or running it see a need for it. It might be easier to say that it should be geared towards “critical sites” with a lot of people relying on up-to-the-second access, or e-commerce sites where any latency might cause potential customers to grow apathetic about their intended purchases. Right now the price is right to try Google’s PageSpeed Service - I recommend doing so with a test site first, of course, before changing any production sites.