Switch to CloudFlare? about astexplorer HOT 30 CLOSED

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

from astexplorer.

@fkling Let me know should you have any questions 😉

from astexplorer.

Ah right, you work there 😄

from astexplorer.

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 :)

from astexplorer.

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.

from astexplorer.

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

from astexplorer.

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

from astexplorer.

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 ;)

from astexplorer.

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.

from astexplorer.

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

from astexplorer.

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

from astexplorer.

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.

from astexplorer.

So this was all for nothing? :P

from astexplorer.

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:

from astexplorer.

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

from astexplorer.

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

from astexplorer.

👍

from astexplorer.

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):

from astexplorer.

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.

from astexplorer.

@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.

from astexplorer.

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

from astexplorer.

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

from astexplorer.

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

from astexplorer.

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?

from astexplorer.

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.

from astexplorer.

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.

from astexplorer.

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?

from astexplorer.

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.

from astexplorer.

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.

from astexplorer.

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.

from astexplorer.