Yeah, we considered setting up a Cloudflare proxy for a while, but at least for logged-in users, LW is actually a really quite dynamic and personalized website, and not a great fit for it (I do think it would be nice to have a logged-out version of pages available on a Cloudflare proxy somehow).
I was referring to their (free) DDoS protection service, rather than their CDN services (also free). In addition to their automated system, you can manually enable an “under-attack” mode that aggressively captchas requests.
Setup is simply pointing DNS name-servers at Cloudflare.
Caching HTML pages for logged out (i.e. cookie-less) users is a trivial config (“cache-everything”).
Oh, interesting. I had not properly realized you could unbundle these. I am hesitant to add a hop to each request, but I do sure expect Cloudflare to be fast. I’ll look into it, and thanks for the recommendation.
It’s a solution! However it comes with its own downsides. For instance, Codeforces users ranted on Cloudflare usage for a while, with following things (mapped to LessWrong) highlighted:
The purpose of an API is defeated: even the API endpoints on the same domain are restricted, which prevents users from requesting posts via GraphQL. In particular, ReviewBot will be down (or be hosted in LW internal infrastructure).
In China, Cloudflare is a big speed bump.
Cloudflare-protected sites are reported to randomly lag a lot. > I had been assuming that this is a server problem, but from talking to some people it seems like this is an issue with differential treatment of who is accessing CF. Lack of interaction smoothness might be really noticeable for new users, comparing to current state.
I recommend Cloudflare.
Yeah, we considered setting up a Cloudflare proxy for a while, but at least for logged-in users, LW is actually a really quite dynamic and personalized website, and not a great fit for it (I do think it would be nice to have a logged-out version of pages available on a Cloudflare proxy somehow).
I was referring to their (free) DDoS protection service, rather than their CDN services (also free). In addition to their automated system, you can manually enable an “under-attack” mode that aggressively captchas requests.
Setup is simply pointing DNS name-servers at Cloudflare. Caching HTML pages for logged out (i.e. cookie-less) users is a trivial config (“cache-everything”).
Oh, interesting. I had not properly realized you could unbundle these. I am hesitant to add a hop to each request, but I do sure expect Cloudflare to be fast. I’ll look into it, and thanks for the recommendation.
It’s a solution! However it comes with its own downsides. For instance, Codeforces users ranted on Cloudflare usage for a while, with following things (mapped to LessWrong) highlighted:
The purpose of an API is defeated: even the API endpoints on the same domain are restricted, which prevents users from requesting posts via GraphQL. In particular, ReviewBot will be down (or be hosted in LW internal infrastructure).
In China, Cloudflare is a big speed bump.
Cloudflare-protected sites are reported to randomly lag a lot.
> I had been assuming that this is a server problem, but from talking to some people it seems like this is an issue with differential treatment of who is accessing CF.
Lack of interaction smoothness might be really noticeable for new users, comparing to current state.