calzoneman
commented
10 years ago Let's tackle these one at a time.
- gzip-- this is certainly something that could be added. It might be worth implementing compression middleware for the built in express server so that everyone can use it, not just people who have configured their reverse proxy to also serve static content.
- nginx-- I'm using the current stable version available in the Debian Wheezy repositories. I would be extremely surprised if Debian did not patch security issues, but if that is indeed the case, then I would accept suggestions for an alternative stable repository. I'd rather not become responsible for compiling nginx every time there's an update. As for the slowness, nginx is currently just acting as a reverse proxy, so I doubt it's the bottleneck, but hey, if it would make it a bit faster I'll upgrade it.
- CDNs-- The reason I have not already done this is that I'm a bit hesitant to add another point of failure. I know that generally you can expect the CDNs for such highly used libraries to have good uptime, but outages do happen, and the site client is completely useless without jQuery/Bootstrap.
Some general notes: I realize there's a lot of room for improvement in how resources are served. Even though CyTube supports caching, I currently have the cache policy set to no caching for CSS/JS resources. I need to look into whether the caching middleware supports modified-since rather than max-age so that I can enable caching without having to get users to manually flush the cache when content is updated. This is one of the things that caused a lot of headaches when the site was proxied by Cloudflare.
All resources are currently served individually rather than in a minified bundle, which adds a lot of request overhead. The obstacle here is not the process of minifying and changing the script source, but the loss of useful debugging information when people report issues (one solution is to serve unminified content in a "debug mode", but the issue there is that sometimes the problems being debugged are very difficult to reproduce).
These issues are definitely being addressed and considered in the work I'm doing in the background on CyTube 4.0, along with many other improvements. The main issue is deciding what to backport into 3.0 in the meantime, since putting work into 3.0 duplicates effort and takes time away from 4.0 development.
CoolOppo
The website could definitely use some optimization. There are a bunch of really easy things to do that'll make it faster. The first of which would be to enable gzip for all of your assets. It's really easy to just use these server configs since you are using nginx. Speaking of which, the version of nginx in use right now is very out of date, and is vulnerable and slower than it needs to be. You are using version 1.2.1, which was released on June 5th, 2012.
The next change to make would be to use CDNs for the external content you're using. Bootstrap, jQuery, etc. can all be loaded from official CDNs. It's recommended because not only does it reduce your server's bandwidth usage, but a ton of the time, your users will already have the content cached from loading them on other websites.
There are a few other things that you could do, and most are listed in the Chrome audit I did:
I'll probably be making some pull requests for this stuff when I get a chance (if you haven't already done it on your own), so if you don't feel like it, don't do it.