Free static page hosting on Google App Engine in minutes
fizerkhan.com
fizerkhan.com
[1] https://developers.google.com/appengine/kb/general#naked_dom...
For example, for this case of GAE, you can use
Naked domains <=> CloudFront <=> GAEFor example, my site (justbeamit.com), runs on GAE, but the naked domain simply redirects to the www.
AWS gets away with this afaik with some magic to point to the IP address for the loadbalancer that would serve your content.
Techincally you can find the IP address for your GAE subdomain and add an A record for your apex domain, but keep in mind that this is a bad idea.
On appengine you're just deploying a dynamic app that just routes everything to a static folder, but since Google doesn't know this is a static site, it's pretty limited what they can do to set good cache headers and optimize stuff for performance. So even if they have an awesome infrastructure, BitBalloon will make your site perform better.
Here's the quick test result from the same site uploaded to AppEngine and BitBalloon:
http://tools.pingdom.com/fpt/#!/vLi9d/http://teststaticsite.... http://tools.pingdom.com/fpt/#!/dwqwvX/http://speedtest.bitb...
https://github.com/stochastic-technologies/static-appengine-...
It supports multiple domains for a single AppEngine instance, and custom URLs for each page. Pull requests for caching/headers/etc welcome!
Half a second is definitively enough that plenty of large scale tests have shown differences in conversion rate.
That difference gets much bigger for people with more than 1 page view due to perfect caching headers.
Additionally, if you actually define your static files as static, then it doesn't even need to spin up instances to serve them.
I've certainly had my criticisms of App Engine in the past, and for certain workloads it's not appropriate [1], but for mostly read only websites like blogs, news, landing pages, I even run a forum on app engine, it's perfect.
In fact, that blog post where I complain about the cost of app engine for hosting my game is itself hosted on app engine. It cost me 6c the day it hit the front page of hn. I pay more for the domain than I do for app engine hosting.
[1]: http://www.war-worlds.com/blog/2013/06/switched-away-from-ap...
Um, wow.
I can definitively say that unless Google App Engine has substantially changed in architecture over the last 12 months, it is definitely not faster to host your static site there rather than on an nginx-based VPS with someone like Digital Ocean.
My tests showed load times on GAE-hosted static sites to be around 200ms - 300ms slower than a reasonably-optimised DO VPS.
It's possible, of course, that GAE would pick up some speed if you're loading the page from somewhere a long way away from the equivalent VPS, as GAE essentially comes with a built-in CDN (to the best of my understanding).
And does Cloudflare cache HTML pages? Last I checked it only cached (what it considered) static assets and hit the origin for every page.
Yes. "It was like that when I got here." I'm working on it.
> And does Cloudflare cache HTML pages? Last I checked it only cached (what it considered) static assets and hit the origin for every page.
Yes. This is configurable.
Also, cloudflare does support clearing of individual files. There is an API for it. Pretty sure their web client does too.
I can load his GAE-hosted web site in ~300ms, and there's a useful performance box on the right sidebar of his site that breaks down how long each component takes to load on GAE:
$ time curl http://www.elie.net/ > /dev/null % Total % Received % Xferd Average Speed Time Time Time Current Dload Upload Total Spent Left Speed 100 36146 0 36146 0 0 113k 0 --:--:-- --:--:-- --:--:-- 114k real 0m0.316s user 0m0.005s sys 0m0.005s
I've been thinking of doing the same with my personal web site but haven't yet.
Do you know what language he used to implement the base setup? I had a suspicion that implementing in Go might end up being faster than Python.
When serving static pages, it is unlikely that any sort of engine will outperform something more like a CDN. I hate it when people just throw out the Google name as proof of performance/excellence/etc. Can we be a bit more scientific here?
I ran into this problem with S3 and ended up writing a simple server to handle it and deploying to Heroku.
[1] By all, I mean all except the ones to /assets or something similar.
handlers:
- url: /.*
mime_type: text/html
static_files: static/index.html
upload: static/index.html
Anything you don't want to go to index.html you can just put before that handler since it processes the app.yaml from top to bottom and stops at the first match.Because it will handle URL Re-Writes you can host on any host in a subdirectory and still have it be your root for the customer.
I mostly abandoned this when Google Launched "PageSpeed" for appengine which was too much a direct competitor. Also when they moved to AppsForDomains you could no longer have a naked domain, and that was annoying. I don't like www. having to be on the front of my URL.
What's wrong with this sentence?
I don't think that anybody expects perfect English from people who may not have English as their first or primary language. That doesn't excuse sentences as broken and incomprehensible as the one in this case, however.
And it certainly is not "derogatory" in any way to point out writing that fails to convey whatever idea it was intended to. If anything, that's the best thing that can be done for the author. It's better for him or her to know that their writing has problems and cannot be understood properly, rather than not knowing this fact at all.
I'm sure that if the author of that sentence doesn't master English yet, (s)he's pretty aware of it, and knowing that no matter what people can more or less understand really helps ensuring that (s)he will try again.
A wise man once said: If you want something done, ask the laziest person in the room how to do it.
A team made by the right combination of those two types will kick asses.
"All the services have their advantages and disadvantages over others"
Each of these differences may appear significant to a native speaker, but the basic meaning of each word is almost the same.