Switch to CloudFlare?

[RReverser]

@fkling Would you be interested in putting astexplorer.net behind CloudFlare? Free plan should work perfectly, and will give HTTPS, HTTP/2 + SPDY and CDN out of the box which should speed up loading our bundles for users.

[fkling]

Just looked a bit into it, looks reasonable. Will give it a try soon!

[RReverser]

@fkling Let me know should you have any questions 😉

[fkling]

Ah right, you work there 😄

[RReverser]

Guilty 😄 But this is definitely not something I'm paid for, just really think it's a good idea - we have relatively big yet separate bundles, and they can benefit from HTTP/2 a lot :)

[fkling]

No worries, I trust you :) I just registered and enabled it... that was really easy! Now I just need to wait for the nameserver to update.

Given that the JS files are now cached, I think we have to configure webpack to add hashes to the bundle files, and somehow update index.html to refer to the correct files. I guess https://www.npmjs.com/package/html-webpack-plugin will help.

[RReverser]

@fkling Just so that we don't wait later - did you enable HTTPS, HSTS and HTTP/2?

[fkling]

Seem to be enabled by default, except HSTS. Is it worth enabling for us though?

[fkling]

Nameservers are now active btw. Can't really test it though since the DNS entries seem to be cached somewhere between my computer and the nameserver ;)

[RReverser]

Ah cool. I don't know, maybe not, but in practice way too many Wi-Fis at cafes tend to insert own banners or tracking codes when website is sent over HTTP connection, so better to have HTTPSed everything possible.

[RReverser]

Hmm, my nslookup already returns CloudFlare IPs after DNS flush, but seems to be still sent over HTTP.

[RReverser]

Ah right I was still visiting HTTP version and HTTP/2 works only over secure connections (one more reason to enforce it ;) ). It works!

[RReverser]

Ah right, we don't benefit that much because our bundles are not loaded in parallel and parse-1.3.0.min.js is loaded from 3rd-party so blocks most of the page.

[fkling]

So this was all for nothing? :P

[RReverser]

Fast and secure! :P
If serious - put parse-1.3.0 onto same server, it should speed it up a bit.
If loading it asynchronously, it would speed up even more, as it's currently the main blocker:

[fkling]

The Parse SDK loads fast for me, but sure, I can try serving it from here. I need to update it anyway.

[RReverser]

There are some more points I can think of in terms of performance, will probably play with it somewhat later.

[fkling]

👍

[fkling]

I made a couple of changes:

• Use webpack to bundle CSS and font files
• Use webpack to add hash (cache breaking) to bundles
• Use Parse npm module instead of third party script
• Set CloudFlare browser caching to one month

At least for me, the site is super fast now (without browser caching):

[RReverser]

Use Parse npm module instead of third party script

Haha, did this locally, too!

At least for me, the site is super fast now (without browser caching):

I always enable 3G throttling for network perf tests in order to be sure it's not just my internet speed, but yeah, looks much faster to me even in such mode, great!

Same for me, great! I always try to enable 3G/4G throttling for testing in order not to depend on own internet speed, but it's still great.

[RReverser]

@fkling One more suggestion: split vendor code (React + CodeMirror at least - they take most of the size) and app code itself. This will allow both to parallelize their download, and improve caching, as React and CodeMirror update much more rarely than code of ASTExplorer itself, so user will get much smaller diffs.

[fkling]

OK, I did that, but not sure I did everything correctly :P

[RReverser]

@fkling Me too :D Can probably check generated app.js - if it doesn't contain those deps code, then should be fine.

[RReverser]

Looks good to me, DOMContentLoaded reduced from 6s to 4s on 3G throttling without cache \o/

[fkling]

Any idea why the cache rate is so low? Could this be requests to index.html only and the JS files are served from the browser's cache?

[RReverser]

Note that this graph represents CDN cache results to original server responses, and doesn't say anything about browser cache. However, I did look at headers of requests/responses with caching enabled, and it looks like HTML is the only one that doesn't get CF-Cache-Status: HIT in response (the only one served directly from your server or client browser's cache). That's because CloudFlare by default doesn't cache HTML on their server as it's pretty dangerous to assume that you can just return it and that it shouldn't be revalidated on server. However, for static websites as ASTExplorer, it's possible to override this behavior using page rules - please check https://support.cloudflare.com/hc/en-us/articles/200172256-How-do-I-cache-static-HTML- on how to do that.

[RReverser]

One more thing - you probably want to increase timing, as max-age for HTML says it should be cached only for 10 minutes, so that someone who opens ASTExplorer once in 20 minutes, would always hit your original server.

[RReverser]

And one more - the graph you show here is graph of # of requests, not actual bandwidth - that is, it counts HTML as 1 request, one JS file as another, and so on despite they have different size and thus impact. What does Bandwidth tab show?

[fkling]

Yeah, I'm aware of most of this.

I just can't imagine that index.html alone is responsible for that much traffic. I'm also curious how exactly 304 are handled/counted. When I refresh astexplorer, it still sends out requests for every file, but gets 304s as answer, e.g.

[RReverser]

If you see CF-Cache-Status: HIT, it's showed as "cached" in graph.

As for 304 - this is the response that goes back to your browser so that it would know something wasn't changed and local copy can be used, however original server still gets hit by each separate user requesting it, and not cached by CDN for all users at once. When many users visit astexplorer.net for the first time (e.g. from tweets) or after 10 sec they will all hit the server fully for this file, and if they visit second time, they hit it to know the status, but anyway hit happens for each separate request.

As for the bandwidth - I guess you're right that index.html shouldn't generate that much of traffic, so there might be other reasons - as mentioned above, users visiting website for the first time (which I believe is the case for most of those who came from social networks and so), cache on CloudFlare servers being purged in favor of priority customers (you know, it's free plan after all and we cache a huge piece of internet to keep it forever 😄 ), and other misconfiguration reasons that we miss here.

[RReverser]

Btw, on my blog, for example, numbers are following:

Total Requests: 1,249
Cached Requests: 250
Uncached Requests: 999

which is pretty normal for website that is not very popular and most users come from search / tweets / profiles / whatever and thus not cached for long.