First off, if you use a DNS provider that has support for a ALIAS records or something similar, pointing your apex domain to <username>.github.io will ensure your GitHub Pages site is served by our CDN without these redirects.

I wish we could provide better service for folks without a DNS provider that supports ALIAS domains in the face of the constant barrage of DDoS attacks we've seen against the IPs we've advertised for GitHub Pages over the years. We made the decision to keep DDoS mitigation enabled for apex domains after seeing GitHub Pages attacked and going down a handful of times in the same week. It's a bummer that this decision negatively impacts performance, but it does certainly improve the overall availability of the service.

FWIW, we considered pulling support for GitHub Pages on apex domains about a year ago because we knew it'd be slower than subdomains and would require DNS configuration that would be challenging and frustrating for a large number of our users. However, we ended up deciding not to go that route because of the number of existing users on apex domains.

I think it's fantastic that you provide apex support for everyone even though it must be exponentially harder to do that just providing CNAMEs, but if you're upfront about the limitations the only people who are going to complain are the type of people you don't want to be listening to anyway.

[0] I mean that in the sense that they'll comprehend the explanation, not that they'll grok it inherently.

(I work on DNS things and am curious about what exactly a CDNs needs are.)

The root can't be a CNAME because no other record with the same name aside of a CNAME can exist. Your domain root also has one SOA and two NS records (and probably one more more MX records if you want to receive mail)

See RFC 1912 (Section 2.4)

[0] http://joshstrange.com/why-its-a-bad-idea-to-put-a-cname-rec...

Edit: Done, seeing changes will need an F5.

http://wwwizer.com/naked-domain-redirect

It'll 302 redirect naked domains to www.domain, which will resolve to whatever you've configured it for.

This should let you chain A -> 302 redirect -> CNAME and bypass the GitHub DDoS protection.

Most DNS hosts offer some mechanism for forwarding traffic from your apex domain to the www subdomain using a 301 (permanent) redirect. Then the www subdomain can be configured with a CNAME record.

For example, at Brace (http://brace.io) we offer a guide for configuring this if your domain is on godaddy. See step 3 at http://blog.brace.io/2014/01/19/custom-domains-godaddy/. (not an endorsement of godaddy)

(edited for clarity)

Edit: Done, seeing changes will need an F5.

I found this out when I asked this question a while back: http://serverfault.com/questions/55528/set-root-domain-recor...

Secondly, you cannot simply divide by 70% to get the load time for 70% of your users, because again, that assumes a very specific distribution (a linear distribution, which doesn't exist for any site with more than 5 hits). What you really need to measure is the "empty-cache" experience, which is different from the "first-visit" experience, and is harder to measure since it's hard (but not impossible) to tell when the user's cache is empty.

Lastly, you're assuming a user drop-off rate without looking at your own data for user drop-off.

You should probably use a real RUM tool that shows you your entire distribution, but also shows you how users convert or bounce based on page load time. Looking at actual data can be surprising and enlightening (I've been looking at this kind of data for almost a decade and it still surprises me and forces me to change my assumptions).

My company (SOASTA) builds a RUM tool (mPulse), which you can use for free. Other companies like pingdom, neustar, keynote, etc. also have RUM solutions, or you can also use the opensource boomerang library (https://github.com/lognormal/boomerang/ disclaimer, I wrote this... BSD licensed) along with the opensource boomcatch server (https://github.com/nature/boomcatch).

If only 10% of visitors were first time, would that mean their average page load speed was 35 seconds? This is some crazy use of the word "average".

[1] http://helloanselm.com/2014/github-pages-redirect-performanc...

The linked site loads in less than half a second, but it costs $5 a month just for a simple page.

But I noticed that my DNS zone is quite different to how Github now tell you to do it (I have an A record to 204.232.175.78). So perhaps that is a factor.

That being said, I notice times similar to another commenter above, around 1-2s usually. I don't think I've seen a five second load time.

[0] https://github.com/laurilehmijoki/s3_website

Check it out: https://www.firebase.com/blog/2014-05-13-introducing-firebas...

In other words, they make it really easy to make your site fast but still catch users that didn't bother typing 'www.'

https://help.github.com/articles/setting-up-a-custom-domain-...

DNSimple doesn't actually implement a new DNS record type, it simply puts a TXT record on your domain that says "ALIAS for some.fqdn", and presumably it causes their DNS servers to do a recursive lookup for you (to whatever's in the TXT record) when you try and look at the A record for the naked domain.

From github's DDoS prevention's point of view the result is the same: an A record lookup points to their IP. They don't know that you got there by way of looking at DNSimple's servers and their ALIAS technique.

The TXT record is only there for informational purposes and could be removed without affecting the system.

Since we have an Anycast network you will also get a result that would be similar to a CNAME resolution, meaning you'll typically get a "close" set of IPs that would be similar to what you would get from the resolution of a CNAME, which ultimately resolves down to A records as well.

So from Github's DDoS prevention's point of view, the result is different.

What's to stop users from doing their own lookup, and setting their A record to what the result is?

https://news.ycombinator.com/item?id=7738913

If you are aiming for the fastest speed possible, check out the s3_website gem support for Cloudfront - you can host your whole static website through a CDN.

The thing is that very few blogger drive enough traffic to make money out of their blog[1]. If that's not the case, then why bother? If the content is good and free then waiting 2 seconds more is acceptable IMHO. :-)

[1]: http://daringfireball.net/ - JG being probably the most prominent example.

Here are a few resources from our blog that explain the www redirect approach:

- http://blog.brace.io/2014/01/17/cnames-aliases/#cnameconfig

- http://blog.brace.io/2014/01/19/custom-domains-godaddy/ (step 3)

(edited: added resources)

https://iwantmyname.com/blog/2014/05/alias-type-dns-records-...

Hope it's helpful!

Also, if mods are going to change titles at least get the grammar right. "Pages ... ARE slow" not "Pages ... IS slow".

"GitHub Pages" is the name of a product, therefore it's singular. (One giveaway is the capital 'P'. If "pages" had been a generic plural, it would not have been capitalized.) The New York Times publishes articles every day, The Royal Tenenbaums is a Wes Anderson movie, and GitHub Pages, according to this article, is sometimes slow.

As for the claim "loses you 35% of your visitors", it is (a) dubious, (b) linkbait, and (c) violates the HN guideline against putting arbitrary numbers in titles. Happy to change it to something better if you or anyone suggest it—but editing that bit out was not a borderline call.

Edit: in the case of Google and Amazon, I can believe that being slow will cause users to defect to other services. I don't believe that anybody will not bother to read documentation because it takes a second to load.

Edit2: If this is true, can anybody explain why users behave in this seemingly bizarre way? Do you give up on pages after 500ms? Have you seen anybody else do that? What is going on?

By analogy, to get into a different mindset, think about channel-surfing on the TV. If other channels show a picture in 0.2s, and as you flip around there's a channel that takes 0.8s to show a picture, are you more or less likely to surf past the slow channel?

Thinking about it I can well believe that if you want people to stay on your site and click around, probably because you want to show them ads or products, a small delay will impact on the number of clicks. I would imagine that's not the motivation for most github pages sites though.

Nothing can stop me if I need to buy something on Amazon or need to pay a bill online. If I'm just filling time and here's three interesting links to "fad of the day (hour?)" then slowest link might lose.

A simple A/B tester could insert an additional 50 ms to half the requests and some data analysis could calculate the slope of the graph in that area. Assuming that slope is perfectly linear for no good reason at extremes like 1500 seconds or 0.0000001 nanoseconds would be unwise.

However, Github hosting is made by programmers for programmers OR at least computer literate people. So it's exactly the group how ought to know when it's time to move to private hosting :-)

I use a subdomain of that main domain as the User Pages site.

How should DNS be setup and how should the CNAME files on GitHub read?

As an example, the domain on the left should load the site normally hosted from the location on the right:

example.com -> username.github.io/blog

io.example.com -> username.github.io

Is this possible?

We use an A record right now for root domains because DNS does not support root domain CNAMEs, and as a consequence have very similar problems.

The only practical way to deal with the problem is to redirect root visitors to www. If you go to google.com, you will notice that they do the same thing and redirect to www from a proxy somewhere. Our next implementation will probably do the same.

Thanks for your honesty! I updated the article.

https://devcenter.heroku.com/articles/moving-to-the-current-...

BitBalloon (https://www.bitballoon.com) will give you better speed with a root domain, but as with any other host you'll still loose out on some of our baked in CDN support if you don't have a DNS host with ALIAS support for apex records.

But you aren't meant to CNAME the root zone, in case you have other records at that level (MX, NS, SOA etc.)?

Running my site through their validators said too many redirects occurred.

https://devcenter.heroku.com/articles/apex-domains http://www.hyperarts.com/blog/www-vs-non-www-for-your-canoni...

No doubt there's ways around any problem with a naked domain, but why work so hard on something so trivial? No user has ever turned away from a website because it hadd "www." in front. That said, your naked domain surely needs to redirect to your "www." address if you set it up this way.

As for why, well, personally I prefer the look of a domain without the "www". It looks cleaner to me.

Let's agree that for the most part it's a bad idea to change from www to naked or the other way around after the launch of a website (for seo reasons). So you have to pick one at launch and try to stick with it. Why choose the option that looks nicer but has problems associated with it and potential vendors not supporting it, vs the one that arguably looks messy but that all users everywhere are well accustomed to and has none of the configuration issues that affect naked domains?

There's postmortems out there about using naked domains and DDoS attacks. There's issues with load balancing, with domain configuration, with cookies.

If your website gets overrun by HNers, what's your plan to compensate quickly? How much of your plan is bogged down by the fact that you're on a naked domain?

On a GitHub page are programming specific solutions for a problem a developer has.

When somebody search for a problem or find a link to a GitHub Project, he/she will visit the page.

All others don't have an urgent problem to solve, so you loose only users, that not need your solution. Can live with it. ;-)

Common Enduser surfin the web are an other species, but what should they seek on a github page ?