We all know that 3rd party content means you no longer control all the factors which affect page load time. A sleek, well-tuned, and optimized site can still deliver a poor user experience because of problems with 3rd party content. Steve Souders even used to publish a series of blog posts where he analyzed and rated the performance of 3rd party content snippets. (Dear Steve, please bring this back, it was awesome). Mathias Bynens took this one step further, showing how to additionally optimize Google’s markup and JavaScript snippets.

The surprising lesson to learn from Steve and Mathias is that if you want a fast site and 3rd party widgets, then you need to examine the 3rd party content for performance problems, even when a snippet comes from a trusted authority on web performance. So this post isn’t really going to be about 3rd party content. It’s going to be about trusting advice.

Last week a Zoompf customer, the online precious metal exchange GoldMoney, contacted Support about an issue our technology flagged on their site. We had detected an issue with Google’s JavaScript library for their Google+ button. Zoompf WPO was suggesting the customer do something which was contradicting Google’s advice. And that was enough to give GoldMoney pause.

The specific issue that Zoompf was flagging was that Google’s plusone.js library was being referenced using SSL from a non-SSL page. SSL is important because, if used properly, it provides communications privacy and integrity. However, a CSS file, or JavaScript library, or even a Favicon that is referenced using a SSL-enabled hyperlink from an HTML page which is not served over SSL most likely does not contain information that needs protecting. Since SSL provides these security features with a cost of a decrease in web performance (as discussed below), it is important to only use SSL when you have to.

In this case, the Google plusone.js button library does not contain personal or private information. Zoompf’s suggestion was to instead retrieve the Google+ library using http:// instead of https://. Here is what Google’s documentation has to say (emphasis added):

The +1 button code requires a script from Google’s servers. You may get this error by including the script via http:// on a page that’s loaded via https://. We recommend using https:// to include the script:
<script type="text/javascript" src="https://apis.google.com/js/plusone.js"></script>
If your web page uses https://, some browsers and verification tools will show an error when any assets on the page are called via http://. If your site serves pages via https://, make sure that the +1 button code on those pages also uses https://. (In fact, it’s fine to use https:// in the button code for all pages, even if they are only served via http://.)

The “error” that Google is trying to avoid is a mixed content warning. It looks like this:

A mixed content warning happens when an HTML page served with HTTPS references resources using HTTP. Due to some serious design flaws in modern browsers, mixed content can allow privileged information like the DOM, cookies, referrer URLs, session IDs, and more to be access by untrusted parties. Browsers usually display a confusing dialog box or just fail to render the page, depending on its security settings. Google’s solution to avoid all is to just always request the plusjone.js file using SSL, even when SSL is not needed.

But using SSL, just for the fun of it, is not a good idea. SSL impacts web performance negatively in several ways:

In short, SSL is great but it’s not free. Don’t use it if you don’t have to.

The solution here is to actually use a protocol relative URL. A protocol relative URL is a way of referencing a resource on a different host name without specifying what protocol to use to retrieve. So instead of src="https://apis.google.com/js/plusone.js" you can use src="//apis.google.com/js/plusone.js". Consider an HTML page which uses a protocol relative URL to reference plusone.js. If the page was served using https://, then plusone.js is requested using https://. Security is maintained and no mixed content security warning will appear. If the page was served using http://, then the library will be served using HTTP. No performance hit happens and no caching issues come up either.

Now, I know what you might be thinking. “Did Stoyan seriously allow some guy a spot on the Performance Calendar to talk about protocol relative URLs for eleven paragraphs?” Well yes, I did talk about something cool that many people are not familiar with and which provides an elegant solution to a surprising common problem. (If fact there tons of other stuff to talk about with protocol relative URLs, like a non-standard IE6 configuration which causes a weird certificate error, or the double downloading bug in IE7 and IE8. So count yourself lucky!) But as I said earlier, the magic of protocol relative URLs is not the point of this post.

The point of post is that you need to be careful about performance advice. Not just where you get it, but what it says to do. Google is awesome. They are one of the strongest supporters of web performance in the industry today. But no one is perfect. Mathias improved upon their Google Analytics snippet. Their Google Doodles are always ludicrously high quality JPEGs that needlessly waste bandwidth. And sometimes, like in this case, their advice is not just right. As the Buddha once said:

Believe nothing, no matter where you read it, or who has said it, not even if I have said it, unless it agrees with your own reason and your own common sense.

You should always examine a code snippet from a 3rd party before including it in your site, regardless of who wrote it, even if Steve Souders or Douglas Crockford or John Resig wrote it, to make sure it does not violate any best practices that you already know.


If there is one thing Billy Hoffman believes in, it's transparency. In fact, he once got sued over it, but that is another story. Billy continues to push for transparency as founder and CEO of Zoompf, whose products provide visibility into your website's performance by identifying the specific issues which are slowing your site down. You can follow Zoompf on Twitter and read Billy's performance research on Zoompf's blog Lickity Split.

15 Responses to “Advice on Trusting Advice”

  1. Yamcsha

    many thanks for this article

  2. blobo

    thx for tip :>

  3. Performance Calendar 2011: Advice on Trusting Advice | Zoompf

    [...] excellent Performance advent calendar. I wrote a post for it which was published today entitled: Advice on Trusting Advice. Mathias Bynens summed up the post as “Always examine a third party code snippet before [...]

  4. EricLaw [MSFT]

    The IE6 error probably has nothing to do with the protocol-relative hyperlink and everything to do with the lack of SNI support in IE6. See http://blogs.msdn.com/b/ieinternals/archive/2009/12/07/certificate-name-mismatch-warnings-and-server-name-indication.aspx for details.

  5. Thierry

    Yep, and that’s not only true for script and performance. Most people copy/paste stuff without trying to understand much of it

    On the other hand ,if something is way over our head, it is difficult to ignore it (not to take advantage of it) simply because we don’t fully understand what it does. And this is why I think people in the community should not be shy to criticize code, snippets, frameworks, etc. Because at the end of the day, it saves ourselves from our own ignorance.

    Note to self: write something about the Google bar (#mngb)

  6. Pavel Paulau

    At least you should be very careful about advises from Billy Hoffman.

    Sometimes even Rivera deserves 95 quality level.

  7. Lose the Wait: HTTP Compression | Zoompf

    [...] CSS, and JavaScript files. This just reinforces what I’ve said before; you have to be careful where your advice comes from.Here is a list of common text resource types on the web which should be served with HTTP [...]

  8. Lose the Wait: HTTP Compression

    [...] CSS, and JavaScript files. This just reinforces what I’ve said before; you have to be careful where your advice comes from.Here is a list of common text resource types on the web which should be served with HTTP [...]

  9. Performance aspects of Google’s HTML/CSS Style Guide | Zoompf

    [...] is a great recommendation for performance. I’ve talked about the advantages of protocol relative URLs in the past. Not only do they both reduce page size, protocol relative URLs prevent you from [...]

  10. HTTP Compression use by Alexa Top 1000 | Zoompf

    [...] a big believer in transparency, so here are my raw data files so you can review it yourself. In fact, if you work at an Alexa Top [...]

  11. Performance aspects of Google’s HTML/CSS Style Guide « 13fqcs

    [...] is a great recommendation for performance. I’ve talked about the advantages of protocol relative URLs in the past. Not only do they both reduce page size, protocol relative URLs prevent you from [...]

  12. Trust (and the Shift Key) | Zoompf

    [...] Sign In| Contact Trust (and the Shift Key)Posted: May 16, 2012 at 6:19 pm I’ve talk a lot about trust, so this exchange from the Simpsons last night was incredibly funny to me. Homer: Oh Marge, let the [...]

  13. url shortener

    I loved as much as you’ll receive carried out right here. The sketch is attractive, your authored material stylish. nonetheless, you command get bought an edginess over that you wish be delivering the following. unwell unquestionably come more formerly again as exactly the same nearly a lot often inside case you shield this hike.

  14. Lose the Wait: HTTP Compression | Zoompf

    [...] Notice I didn’t say "text resources." Text resources, like HTML, CSS, and JavaScript certainly should be compressed because they are not natively compressed file formats. Unfortunately, most people seem to focus on these 3 types of files. In fact, a quick web search shows that most of the top results for ".htaccess compress" include instructions only on compressing HTML, CSS, and JavaScript files. This just reinforces what I’ve said before; you have to be careful where your advice comes from. [...]

Leave a Reply

You can use these tags: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>
And here's a tool to convert HTML entities