AddThis and WebPerformance: taking my page load time from 4 seconds to 1.5 seconds

Recently I have been getting more and more into web performance. I have been looking for ways to make my faxdocs.tv site faster and more responsive. On the side, I have been looking at doing the same with my personal sites. These include technovangelist.com, envl.pe, and chromagenic.com. I have also recently setup a test Drupal site using PhpFog (a great way to get a free copy of Drupal and ThinkUp going). 

So how does one get into web performance and what are the resources out there. Well, ask anyone who is in the business and they will mention one name. They might list a few others, but at the very least they will mention the name of Steve Souders. He has two books out there on the topic and even though the older one is 4+ years old, its still the go-to reference on the topic.

High Performance Web Sites describes 14 specific rules of what should be done to speed up web sites. Some of the steps are easy to achieve, others require a bit more work. Most of them seemed kinda obvious, but almost none of them had been implemented by me. Its available on Kindle where I have my copy today. His newer Even Faster Web Sites goes into even more detail about three specific categories of areas to improve on. At first I thought the second book was an update of the first, but after reading them, I can see that both are worth having. Unfortunately the newer version is not available on Kindle from Amazon, but I ended up buying the PDF and MOBI versions from O'Reilly so I could load it up on my Kindle.

Both of these books are very interesting, especially if you are just getting started, but do you need them? Well, no. It turns out I already had access to a lot of the information and to a great toolset on my laptop, but the books made for interesting reading on the 60+ hours of flights I have been on in the last 4 weeks.

You may have the right tools too. They are built in to Google's Chrome browser. Just bring up the developer tools and take a look at the Network tab. There you will see a chart often called a Waterfall chart describing how long each component takes to load up. I didn't have to know a lot of details to see that there are just a few resources taking most of the time on my sites.

For this article, I am just going to take a look at this page on technovangelist.com. I loaded it up and opened the dev tools to the Network tab. At the bottom of the page I could see that it took nearly 4 seconds to load. I repeated this 5 times and saw that the average was about 3.9 seconds. Scrolling up and down in that list I noticed that a lot of social media icons were getting loaded. Scrolling down on the page I saw that under each post I had added a widget from AddThis which offered the ability to quickly +1 with Google, and a few other things. On the lower right of the page, I had links to all my accounts on G+, Flickr, LastFM, and more. And each of those had an image next to them.

So my first step was to change the SquareSpace Social Widget to display text only instead of text and an icon for each destination. I then logged out and refreshed the page 5 times to see that the average had dropped down to 3.8 seconds. A tenth of a second was good, but I was actually hoping for more. 

I noticed that the Google Plus One widget for AddThis was loading up some javascript 10 times, once for each post that was shown on the Technovangelist home page. So I went into the Blog configuration on SquareSpace to modify the AddThis widget. I simply removed the Google part of the widget, logged off, refreshed the page 5 times to get an average load time. This was the kind of improvement I was hoping for. It dropped to 2.15 seconds (with a fastest time of 1.9 seconds).

That was a big improvement! So what happens if I get rid of AddThis altogether? How much faster can things get? I logged in, removed any mention of AddThis, logged out, refreshed 5 times. Now I was down to 1.5 seconds (with a fastest time of about 1.4 seconds). Wow! 

So I guess the question I should be asking myself is whether a Google Plus One button is worth it. Do I want my users to have to wait 2.5 times as long, just so they can click a button to rank me higher on G+? I don't think it is worth it.

So in summary, I was able to look at my SquareSpace hosted site for just a few minutes and shave a huge percentage off of the page load time for the few visitors I get. I'll do the same thing for some of my other sites and share my findings here. Although there is quite a lot I won't be able to do since SquareSpace is a bit of a black box, I can clean up what I add myself. Hopefully you found this interesting and if you have any comments, please leave them below.

How To Download A Secret and Save To An Adobe Air ELS

One of the problems I had to solve with my recent management app was about how to store secret information. My app needed to have access to an API key, and a special username and password. All three of those things were items I would rather keep out of my user's hands so storing it in the Javascript that is part of the Adobe Air app was not a solution. But I found another way.

Let me explain the plaintext part of the problem. With any Adobe Air app, you can very easily look inside and see all source Javascript in plaintext. Since all the logic in my app is in the Javascript, thats a problem. So I decided to store that secret info on a secured page on a Squarespace site. If you type in the right login, you can see the page (assuming you know where to look).

The information stored on the page is in a JSON string, which is then encoded with Base64. So I set up my app to login, download the information, decode it, parse the JSON, and finally store the info locally using the Adobe encrypted local store. Almost all of that is done in that one ajax call.

Take a look at the source code below. It's actually written in CoffeeScript, since thats just how I roll. If you are unfamiliar with CoffeeScript, take the few minutes to learn it.

Even if you aren't using Adobe Air, this is a valuable little snippet. Change the last three lines to do something else with your newly found secret info. Not using Squarespace? Well, that will take a bit more work to get the URL and parameters just right.

The benefit of this is that I don't have to do much to manage who has rights to the app, I just have to manage who has rights to the page on Squarespace. Also, I stored a hash of the users password in the local store, so on the app's startup, I just compare the hash of the password the user enters to the stored hash to verify the user is valid and has access to the info.

I am sure there is a hole in here somewhere, but I think it is good enough for my purposes.

How Google App Engine Fixed My Main Problem With SquareSpace

As you are probably aware, technovangelist.com is hosted at SquareSpace.com. It hasn't always been that way. I switched to SS about a year and a half ago when I got tired of self hosting using Community Server and Graffiti and various other home brew solutions. SS has the advantage of making it very easy to come up with a uniform style across your pages, with some customization in every area. It's really a well designed solution and after this much time with them, I have no plans to leave. That said, I do have one beef with them: They don't offer any server-side page generation techniques beyond the sidebars.

Take a look at the home page at technovangelist.com. I have the sidebar, plus 5 other areas of content, each pulling from a different RSS feed. There are 2 feeds from my blogs here at technovangelist and at faxsolutionsblog.opentext.com. There are 2 other feeds from my videos at vimeo and youtube. Finally there is a feed from my photoblog site, chromagenic.com. The home page at technovangelist really is the clearing house for the brand of 'me'.

The only way to create this kind of page at SquareSpace is with a HTML page, meaning I have to create the HTML from scratch. Thats not a problem for me. What is a problem is that the HTML I create has to be completely client-based: HTML and javascript. Nothing can run on the server. So if I am grabbing 5 different feeds and then generating a page from that all at the server, there is going to be a delay of at least a second or two every single time someone looks at this page. Even though the content doesn't update more than once every 1-2 weeks or more.

But I did it anyway for the first version of this page. I used the magical Google Feed API which did exactly what I wanted. Every time it ran, though, 1-2 seconds were required for drawing the page. There had to be a better way. The first thought was to design a client-side app for me to run every time one of my content sources updates. So I started going down that route, working on some test projects before starting the final Mac app that I wanted. That was last Saturday.

Then during one of my little research missions, trying to find something I needed for the app, I re-stumbled on Google App Engine. Here was a hosted location that could run my own custom server-side code. The original thought was to build the page at GAE, then do some sort of server-side include of the content. But then I thought I hit a bit of a wall: the app had to be written in Java or Python.

I hadn't touched Java in 10 years. I last used it when I did some outsourced marketing projects with Sun Microsystems, building test apps that were used in instructional materials. But then I went .Net all the way working for Microsoft and then Captaris/Open Text. I felt re-learning Java was going to be a big hurdle to GAE. Python on the other hand was a bit more digestible. I didn't know the language, but I have a few friends who spend all of their working days with the language. One of my best friends from my Microsoft days was a PM with IronPython. I felt Python was more accessible.

So I started looking in to it. I installed Aptana Studio 3 which comes with PyDev which allowed me to create and build Python scripts in as easy a way as possible. And I followed the fantastic series of videos that are part of Google's Python Class. Go ahead and watch them. It will take you five hours and you'll come away with a pretty good understanding of the language. So I started looking into Python on Saturday evening around 8PM, and by 5PM on Sunday I was beginning to build my GAE app to generate my home page. The only reason it took so long was that I had a Dim Sum lunch with friends for a few hours in the middle of it all.

The end result is a page that is generated in less than a second. And it's a whole lot easier to manage too. But it's not perfect yet. For now it involves a manual step. I'll go to the GAE page and copy the page. Then go to edit my site, and paste the code in. The result is that for you, the home page is displayed as quickly as possible. And I have to run a single manual, 1-minute step every couple of weeks. In the near future (perhaps next weekend), I'd like to see about having it auto-update my SquareSpace site, or at least cache the content locally and figure a way to do some sort of server-side include.

It was a fun project and I was very happy to see a working solution by the end of the evening Sunday night. And learning Python has already proven to be a good investment. I am already leveraging it in some of the scripts I have written to automate the stuff I do at work. Maybe I'll write up some of the details of those scripts, as well as more about what I actually created on GAE....another night...

How to Create a Custom 404 Page on Squarespace

I just recently switched my blog from a self-hosted Graffiti installation to a completely managed solution on Squarespace. This is fantastic because it takes the job of patching and coding almost completely away. The downside is that some of the things I took for granted are unavailable. Like a custom 404 page. Why is this an issue? Well, if you are moving from one engine to another, they probably have different URLs for the same article. The last thing I want is for one of the rare visitors to my blog is some unhelpful error saying that the page could not be found. If you want an example of this happening, go to Squarespace’s own blog and look at this post from September 2008. Now click on the video link. Unless they have fixed it recently, you will see this:

The built in solution for this is called URL Shortcuts. The idea is that you plug in the old url and the new url into the configuration area, and anytime someone enters the old url, they are sent to the new one instead. Great…if you have 5 pages. But if you have been blogging for a while, then the job of entering those URLs is going to suck. Squarespace probably realizes this which is why you see that screenshot above. So what is the solution?

If you write to support, they will say that URL Shortcuts is the solution. But there is a better way. I found a post on their developer forum about customizing the Page Not Found form. The solution seemed pretty simple. Create a custom 404 page on your site, the paste this in the Extra Header Code section (I am pretty sure this means you need an Advanced level package from them):

<script type="text/javascript">
   //Redirect from error page to your new custom error page 
   var redirectURL = "http://ENTER YOUR NEW ERROR PAGE URL HERE";

   if(document.title == Squarespace.Constants.WEBSITE_TITLE + " - Page Not Found"){ 
      location = redirectURL; 
   }; 
</script>

The only thing to change in that code is the page url. Actually, mine only worked when I put /custom404 rather than http://technovangelist.com/custom404.

On my Custom404 page, I put in some apologetic text explaining the situation, directing visitors to the search box. But I wanted to take it a bit further. I wanted to auto suggest a link for where they really intended to go. It might not work, but I figured it was good to try. On the Graffiti site, page urls were formatted as <site>/<category>/<page>. So I had some that were /technology/blah, and others that were /travel/blah. On the new site, all posts were under blog, so /blog/blah. What I needed was a way to convert all /travel/ and /technology/ to /blog/. I think this would be a good time to tell you that I don’t know anything about javascript other than how to spell Google.com.

A little searching on the net combined with some newbie code wrangling and I ended up with something like this:

prevurl = document.referrer;      
document.write("<font size=-1><b>You came here from "+prevurl+"</b></font>");

So that told me where I came from. When I figured out how to manipulate text I got the rest:

if(prevurl.indexOf("technology")!=-1) {
   newurl= prevurl.replace("technology","blog");
   newurl = newurl.substr(0, newurl.length-1);
   newurl = newurl +".html";
   document.write("<font size=-1><b><br>I think you wanted <a href="+ newurl +">"+ newurl +"</a></b></font>"); }

That combined with my apology was a pretty good first step. Then tonight I realized there was a problem. I looked at my Woopra stats and saw that /custom404 was one of my more popular pages. I couldn’t quickly see which page caused the problem. Woopra shows the page title, which was now “Technovangelist – Custom404”. So I had to change that title. In order to change the title, I needed to pass the bad URL somehow. A query parameter seemed like a good choice. So I changed the line that initialized redirectURL to this.

var redirectURL = "/custom404?ref="+location.href;

That got me the all the info I needed. Perhaps too much information. Now to tweak the title. I headed back to the Extra Header Code in Website Settings. After that first If clause in the script, I added another:

else if (document.title == "Technovangelist - Custom404"){
   document.title = "Technovangelist - 404 - "+location.href;

This is good, but the url in Woopra is now really long. So another edit got me this:

else if (document.title == "Technovangelist - Custom404"){ 
   document.title = "Technovangelist - 404 - "+location.href.substring(67); };

Why is 67 in there? Well, I am sure there is a cooler way, but there are 67 letters in the URL before the unique part of the url. I want to see Technovangelist – 404 - /technology/badsite, not the way too long Technovangelist – 404 – http://technovangelist.com/Custom404?http://technovangelist.com/technology/badsite.

I then added a search box to the custom404 page just in case my guess didn’t work, but I think it’s a good first step. Want to try it? Go to http://technovangelist.com/technology/time-to-move-away-from-graffiti/ and see the custom 404 page that comes up. Now click the link that I suggested. In Woopra I will see something like this:

I am very happy with this solution. Would have been easier I think to be able to override a 404 page, but this will do. Any thoughts on how I can improve this approach??? Let me know in the comments.

Time to Move Away From Graffiti

Blogging for me has always been something I enjoyed, but I managed to not do much of it. I let the tools get in my way far too much. In the early days of this blog site, I wanted to create my own software. First it was a Linux based site, running Apache, Postgresql, and PHP/FI. The a few years later (well over 10 years ago now) I switched over to a Windows-based site. That switch happened to coincide with my hiring at Microsoft. It was hosted with a variety of providers including WinISP (an MS internal project that seems to be dead now). When Telligent got started I switched over to Community Server. I entered their theme building contest with an embarrassment of a theme and won a free license. After a few years there, I moved to Graffiti. Both CS and Graffiti were hosted on my current provider: Server Intellect. But it was always a lot of work. There was no real community around either Community Server or Graffiti and although creating styles was easier than doing it yourself, it was still hard. And then there was a security problem recently. Since I was hosting it myself, I had to deal with fixing it. Ughh. 

Blogging has become a chore. But I don't want it to be a chore. I want to have a site that is easy to maintain, easy to tweak, and no real management on my part. I want an engine that doesn't feel like a kludge, ruling out a lot of the industry leaders. 

I have long loved Diggnation, having watched a good 90% of all of their shows. Recently they have been advertising SquareSpace. I always skipped over the ads so never really saw what it was about. Then I saw NewToYork.com because of a blog post about it's footer design. From there I saw other Squarespace sites, then the main site and the videos. I was amazed at how easy it all looked. I was ready to change over.

The last few days have been a lot of fun (and some frustrations). I think I have a site that I can live with at squarespace and this blog will be moving over very soon. I hope this causes the last few subscribers I have minimal downtime. I should work out all the kinks very soon.