Tag: JavaScript

How to Host a Screaming Fast Site for $0.03/Month

perf

I had an idea. That’s always how it starts. Before I know it, I’ve purchased the domain name and I’m futzing around with some HTML but where am I going to host it and how much is this going to end up costing me?

That’s where I was when I came up with #DonateMyFee. “This is a site that is only going to cost me money”, I thought to myself (the whole point is for people to donate money rather than paying me). I really didn’t want to start shelling out big (or small) bucks on hosting.

Long story short, here is the recipe for a screaming fast website on a low budget:

Amazon S3

I’m not a huge fan of Amazon AWS, but S3 is useful enough to make it into my good graces. S3 is Amazon’s storage service. You upload static files into “buckets” and S3 can hold on to them, version them, and most importantly serve them via http. When configured to serve a bucket as a static website, S3 can be used to replace the load balancing and web serving infrastructure needed to serve a static website.

There are only two problems with that.

  1. You pay for S3 by the amount of traffic pulled from your bucket.
  2. Your “website” will be called something crazy ugly like donatemyfee.com.s3-website-eu-west-1.amazonaws.com

Regarding the price, S3 tries to get you three ways. They charge for the volume of the data being stored, for the number of requests made, and for the volume of the request throughput in GB. That said, the prices are very reasonable if we can keep the number of requests low. For that reason, a CDN is an absolute must. The CDN will also solve our second problem – the unfriendly S3 website name.

Often S3 is paired with Amazon’s CDN, Cloudfront, but I don’t recommend it. Cloudfront is expensive as CDN’s go and we’re on a budget. Even if we wanted to pay for the CDN, there are better performing options for less. CloudFlare is a great alternative with a free plan that will do us wonders.

CloudFlare

CloudFlare is one of several CDN by proxy + Webapp Firewall solutions that cropped up several years ago. Since the beginning, they have had a free plan and they have proven to be both innovative and competitive.

To use CloudFlare , we need to set their servers as your domain’s DNS name servers which can be a deal breaker in some cases. Once that’s setup we create a CNAME record in CloudFlare which points to the ugly S3 website name. CloudFlare has a new CNAME flattening technique which will allow us to configure this even for the root domain (without the www). This technique break some rules so I wouldn’t recommend it in every case, but in ours, it’s just what we need.

CloudFlare will cache all of our static content from S3 saving us from paying for the majority of the visits to the site. CloudFlare will also compress and optimize our content so it takes less time to reach the browser. Depending on what kind of traffic your site attracts, CloudFlare’s security settings can also protect you from all kinds of resource abuse, malicious traffic, hotlinking, etc.

Note: S3 will not properly identify the mime types for every file which means that some files might not be compressed properly by CloudFlare. You can fix this by changing the metadata for the files in S3. Specifically .ttf, .eot, and other typography related files are a problem.

Frugal Functionality

Having a cheaply hosted static website is nice but static can also be pretty useless. In order to get some functionality out of the site, you could go all jQuery on it but I that that is a road too often traveled these days. I’ve seen too many people include all of jQuery instead of writing 3 lines of JavaScript.

If we want this site to be fast we need to work frugally. If you take a look athttp://donatemyfee.com, you will see some examples of what I call “frugal functionality”.

The social share buttons are static links, not huge JavaScript widgets included from various social networks. Including external scripts is always a bad idea and they always hurt the performance of your site no matter what anyone tells you. Also, the icons and hover animations are CSS typography tricks. No JavaScript and no icon images downloaded.

The site is designed using responsive web design techniques which is “buzzword” for using a bunch of crafty CSS to make the same thing look decent on different sized screens. If we were a large company, I would say “Responsive web is for lazy companies and people without a budget to develop good looking, device targeted sites.” Since we’re on a budget, I’ll say it’s frugal 🙂

Last but not least, we have skimped on all the normal infrastructure that goes behind a website so our options for actually generating leads are a bit thin. We could go very old school with mailto links but in these days where webmail reigns supreme, they are getting pretty useless. Enter Google Forms.

Google Forms

If you haven’t been asked to fill out a Google Form yet, here’s your chance. Google lets you create fairly elaborate forms for free. The forms collect the answers and store them automatically in a Google Drive spreadsheet. There are more sophisticated options for processing the answers, and an entire extension ecosystem being built around the process. For us, the basic solution is more than enough.

Note: You can link to the form or embed it in an iframe. The form will take a bite out of your page load performance (iframes are a huge performance no-no). They will also annoy you with endless warnings, all of which you can nothing about, if you test your site performance with any of the free online services (Webpagetest,Websitetest, GTmetrix, PageSpeed, etc.). In this case, I used some simple (read jQuery-free) JavaScript to load the embeded iframe if it’s requested. This has the added benefit of keeping the user on-site to fill out the form and eliminating the page load time performance hit.

Less is more

Finally, the most important advice about web performance is always “Less is more”. There is no better way to ensure that a page loads quickly than to make it smaller in every way possible. Use less and smaller pictures. Combine, compress and minify everything. Reduce the number of requests.

If you’re interested in getting my help with your site, contact me via LinkedIn or#DonateMyFee . All consulting fees go directly from you to a tax deductible charity in your/your company’s name.

Google Analytics fixed but is Google crashing?

Google has finally added Israel to the list of Countries in the sign up process which is good news.
On the other hand, they got the timezone wrong (Israel is in DST right now and uses GMT+3 till about October) and that’s after spending over a week fixing it.

What’s going on inside Google? Why did it take so long? Why wasn’t Israel on the list to begin with?
I recieved no explanation from Google but my guess is that they must of had a bug in the code generating the form fields and the javascript behind them. Look at the following code sample:

CC["ID"] = new Array("220|(GMT+07:00) Jakarta","234|(GMT+08:00) Makassar","221|(GMT+09:00) Jayapura");
CC["IR"] = new Array("257|(GMT+03:30) Tehran");
CC["IQ"] = new Array("198|(GMT+03:00) Baghdad");
CC["IE"] = new Array("300|(GMT+00:00) Greenwich Mean Time");
CC["IL"] = new Array("222|(GMT+02:00) Jerusalem");

Before the fix, Jerusalem time was present in the javascript but it was ORed to something else like the first line above.

That is still no excuse for such a system going live. Google’s quality control should have stepped in.

On the other hand it points to a growing list of technical difficulties within Google.

  1. Since Google’s last update to their algorithms, they’ve been returning pages from sites of mine that haven’t been online in years.
  2. For over a week I’ve been experiencing problems with Gmail timing out.
  3. Blogger is less than responsive as always.
  4. Analytics, in the day that I’ve been using it, has often claimed to be under maintenance one second and fine the next- I guess maintenance means “I’m a tired server, leave me alone please.”

The Register reports that Google is choking on web spam: http://www.theregister.co.uk/2006/05/04/google_bigdaddy_chaos/

Webmasters now report sites not being crawled for weeks, with Google SERPS (search engine results pages) returning old pages, and failing to return results for phrases that used to bear fruitful results.

“Some sites have lost 99 per cent of their indexed pages,” reports one member of the Webmaster World forum. “Many cache dates go back to 2004 January.” Others report long-extinct pages showing up as “Supplemental Results.”

But the new algorithms may not be solely to blame. Google’s chief executive Eric Schmidt has hinted at another reason for the recent chaos. In Google’s earnings conference call last month, Schmidt was frank about the extent of the problem.

“Those machines are full,” he said. “We have a huge machine crisis.”

While here they attempt to save face for Google by putting Schmidt’s comment in context, it’s clear that Google has been having technical problems.

Google continued to make substantial capital investments, mainly in computer servers, networking equipment and its data centers. It spent $345 million on such items in the first quarter, more than double the level of last year. Yahoo, its closest rival, spent $142 million on capital expenses in the first quarter.

Referring to the sheer volume of Web site information, video and e-mail that Google’s servers hold, Schmidt said: “Those machines are full. We have a huge machine crisis.”

Jordan Rohan of RBC Capital Markets called Google’s capital spending “unfathomably high,” noting that it spent the same percentage of its revenue on equipment as a wire-line phone company.

I don’t see how the context makes things any better. The bottom line remains that Google needed a heck of a lot more hardware than it had and who knows if they bought everything they needed. Those are only the first quarter figures- I would imagine it could take a whole quarter to deploy $345 million dollars of equipment. I wonder what they will spend next quarter?