84
votes
Performance on tildes.net
It's friggin amazing.
Who knew that keeping a site clean of ads, trackers, and all kinds of other garbage could make the internet feel fast again? Tildes is not only a place for great discussion, but it's a site that doesn't get in the way of its content and I love it for that.
Sorry if this isn't "interesting, informative, or have the potential to start a good discussion".
Thank you @Deimos for creating such an amazing site! I'm not in a position to donate at this point, but I see it in the future.
Related reading that's quite amusing and gets shared a lot when we talk about this: The Website Obesity Crisis
Honestly the best part of this is that Tildes' webserver is basically in an eternal, untroubled slumber. You can serve a hell of a lot of pages in no time using no bandwidth if it's a couple of kilobytes each. People on the shittiest of internet connections can easily load the site when places like reddit won't load for them at all.
Reddit and some other similar sites often have APIs though, which serve JSON. Third party apps on mobile can be pretty light on data when loading JSON and maybe some little thumbnails, and work acceptably even on 2G. Good apps also render content into user tunable, clean looking, smoothly scrollable layout using efficient platform native code. For example RedReader is a fast open source reddit app.
Its only a matter of time before reddit starts locking down the api to get everyone on to their own app. The reddit api was a legacy feature for when there was no official reddit app.
I think a lot of people don't realize that third-party reddit apps don't show reddit ads at all. If you see ads in a third-party app, they're ones that the app itself is adding, not reddit's. From reddit's perspective, those third-party app users are an untapped resource.
I think it's inevitable at some point that some exec will recognize that, and figure out that if they just shut the API down, they can single-handedly increase multiple business metrics. Let's say that somewhere around 10% of the site's users are on third-party apps (this is probably a little high, but we don't know much more), and reddit figures that even if it makes them angry, about half of them will stay and switch over to the official app, not totally abandon reddit. That means they'll still immediately increase ad viewership and ad revenue by 5%, and that's a pretty tough bump to keep deliberately ignoring.
About the only other alternative is that third-party apps are forced to start displaying reddit's ads, but I don't think users (or app developers) will be very happy about that either.
I wish reddit would at least keep the api for gold users if that happens... they probably won't
They could just blend the ads into the content feed. If they functionally just forced everyone to be subscribed to an advertising subreddit it would put those in your face regardless of what platform you’re viewing on. The app would specifically have to develop some function to filter posts from that pseudo-subreddit out since the API would presumably not allow it.
Ads are legally required to be labelled as ads, so they can't just sneak them in. Whatever data they send to distinguish the ads (even if it's just adding "[Promoted]" to their titles) would also be usable by the app to filter them out. Yes, they'd have to do an update to add a filter, but it would just be an
ifstatement.The only way it works is if the apps don't have a choice about displaying the ads, probably in the form of: "Your app must display all of our ads in the format we define, or we'll shut down your access to the API and/or get you removed from the app store."
Wouldn’t the subreddit being an advert subreddit functionally be a label? I can see a “you must display the ad subreddit” being part of an agreement to use their API. They obviously wouldn’t get 100% compliance, but it would be enough to where it’s worthwhile for them to do it.
Eu requires sponsored content to be marked as such so I don't think they can do that without still letting apps easily filter out ads. I wonder if it would be legal for them not to mark ads as ads in api and say that api is for bots only?
There's sneakier options with a higher conversion rate... for example high latency on any non Reddit owned app API request, or making changes to the API itself which the Reddit app handles natively but other apps break on - bonus points if it's technically still compliant with the published API, but breaks undocumented behaviour people relied on.
Do you think you could explain more about how APIs work, and why they necessarily slows down sites? I only very dimly understand what an API is; I can barely call on MediaWiki's extremely thoroughly documented one to make bot edits to wiki pages. Do all APIs inherently have this performance limitation, or can they be designed in a way that keeps functional options open in a tidy way?
Nitta is saying that API's allow you to write an app that displays content from reddit in a performant way.
On reddit, let's say they load 25 post titles and thumbnails + ads + custom subreddit themes. You could write your own app using their API's that only load the 25 post titles, and it would be way more performant.
Makes me wonder if I'm seeing evidence of that when reddit won't load at all on desktop, yet it works fine in Apollo.
All it really means is a way to get the content in a machine-readable format rather than one intended for humans. An API is essentially guaranteed to be faster than the full website, because it's just the actual data, but it means you need some kind of viewer at the other end to interpret it.
The website version comes with all the layout info included as well, making it slightly heavier in general. It then tends to come with a bunch of extraneous crap above and beyond that, which is what we're all complaining about!
Or rather, that people will write applications that provide a better browsing experience than the website using said APIs, which is quite true. There are ways to access reddit without the bloat, however you do sacrifice some features, and reddit will probably get around to turning those off someday since they want you stuck in their tracking script tar pits.
You know how headphone jacks are all the same shape? There's a standard for how to make one, and assuming your cable meets the standard, and the jack does, they'll fit together. There are two segments for audio signals and one for a common ground. This is the same thing as an API - it's just a consistent way to get to some type of information.
Websites, programming languages, CPUs - anything that needs to work with a multitude of components made by different people - will have an API. For reddit they need to make sure that the data they send to the website is the same data that gets sent to your mobile app (reddit uses its own JSON API for the HTML site).
So an API is just a software interface standard.
Here's an entertaining, and more tongue-in-cheek version of the same argument (NSFW for swearing)
Here's another one
in recent years, I keep mumbling to myself, "websites used to just work, what happened?", whenever I hit one of those bloated, React-y behemoths you can't escape, nowadays. I mean, it's amazing what's possible. A full office suite with multiple users working on it simultanously in-browser? A map of earth with infinite zoom and 3D terrain features? Basically, love them or hate them, but the things google does. But why put all this crap onto a simple text-based website (looking at you, reddit)? Why have images "load on demand" when there's only 3 of them in an article? Why re-invent something as basic as scrolling only for it to feel off and break features browsers had for decades?
You remember those geocities pages from the 90s? Those spinning gifs and weird background images, "works best in internet explorer 3.0" and fixed widths? I think we're having the same, ridiculous trends right now, which we will look back and cringe in 10 years.
I wonder how much is developers' fault as a whole. Seeing JavaScript pop up and hearing people talk about how easy it is to learn and simple to play with and quick to get in to... but at what cost? Like, how many programming languages and libraries and methods and techniques are now in common use because they make the developer's life easier, at the cost of making the user's life less so.
I did a project with some friends for a class, and our goal was a tablet app. I wanted to write it in Swift because iPads have won the tablet war and they're everywhere now. But our advisor told us to do it in JavaScript. Why? Because its "cross-platform". Because we could "write it once and run it on both".... sounds like the same empty promise that Java sold us years ago and never panned out.
So we ended up writing the whole thing in JS. React, Redux, Node, Yarn, Storybook, Axios, ... so many different libraries and dependencies. And in the end? I would never use the app. It looks awful on an iPad, it's horribly slow, and doesn't follow native design principles at all.
Sometimes I think about how Roller Coaster Tycoon was written in x86 Assembly. That game turned out so well, not because of its vast dependencies, or beautiful magic language features, or how "nice it is" to program in. Assembly is a beast of a language. But Sawyer pulled it off, despite how hard that must've been. Art through Limitation. He understood what it really takes to make a good product:
I can't remember what the article was called, but I read some piece about how new programming languages are more likely to be adopted nowadays if they're easy to write simple stuff in. Hello World, etc. Because devs pick it up and only later, deep into the code, realize that it's not gonna work as well as the simple demos said.
Another site I like for this is daringfireball.net. No tracking scripts beyond Google Analytics & Mint (the former is blocked by tools like pi-hole anyway). No thousands of JS bundles, stylesheets, & cookies. Simple, semantic HTML. Clean design.
The best part of all of this? These simple sites are usually wildly more maintainable than the multi-megabyte behemoths that everyone else seems to use.
There is something immense to be said by fast, server side rendered HTML. These websites are just a delight to use, and often times, way simpler (and, in most situations, never worse) than other super crufty, JS-laden, client rendered, DOM-manipulating websites.
I really like building simple server side rendered sites, and it's an absolute ballache building and maintaining the super heavy JS sites, but hey, JS is trendy so those are the jobs that pay.
Client side rendering isn't the problem. I develop a client side rendered SPA and its super snappy even on really old computers. You have to mess up really bad to make a website slow.
I was about to suggest that there may still be work to do for Tildes, what with it using jQuery presumably solely for the plugin to check "dirty" form (that is, whether information has been filled into fields, like the comment text field) – but it turns out, there are few, if any, non-jQuery libraries for such things. Searching
js dirty form githublent me with a dozen jQuery plugins for this purpose (including the one Tildes is using), and some articles about how to do so. Not one vanilla-JS library for this on the front page of a Google search! You'd think someone would've made this already.There are ways to improve loading speed still, swift as it already is, though. @Deimos, is your server capable of serving HTTP/2 requests? It would make serving only a handful of icons possible, as opposed to a whole spritesheet of them. It would also help with icon scalability in the future – if, for example, you'd try and increase the size of a topic on the feed.
I'm mentioning it because the stylesheet for the sprites uses loading time it needn't be using. You could make it load asynchronously, which would reduce the load. This could shave off 300~400 ms off loading time from the stylesheet alone – and ~1.5 s from the spritesheet (assuming you're still gonna load up icons). Then you could turn them into SVGs, optimize those... Make the site even quicker to load.
Other than that: excellent work on optimization. No bandwidth is wasted here – and that's an achievement in the current ecosystem of popular media. Nice work.
jQuery is required primarily because it's a dependency of Intercooler, which handles all the AJAX on the site. It's possible to do a little better, for example Intercooler has experimental support for using Zepto instead of jQuery, but in the end, even totally eliminating jQuery (and maybe even Intercooler too) would result in saving something like a 30kb download on a static file that gets cached and doesn't need to be redownloaded for days or weeks. Worrying about that is a micro-optimization that will have no significant impact (similar to minifying my JS)—someone clicking on a single link topic will download far more data than that anyway.
The site's already served using HTTP/2, you can verify this in browser dev tools' "Network" tab (you may have to right click the column headers and show the "Protocol" one).
The site icon spritesheet does definitely need work though, it's getting large and needs to be fully redownloaded whenever a new icon is added. I think it would be best to have a "common sites" spritesheet that includes ones like YouTube, NYT, etc. that are submitted very often (so they're almost always present on a listings page), and then keep icons for rarely-submitted sites as individual ones that can just be requested when they're actually visible on the page.
I will readily admit: I am the type of a dev who'd spend days getting 3kB out of the site's resources. The reason I'd do that is not bandwidth (which is important for people where connectivity is an issue, like the remote regions in South America, Asia, and Africa), but response time. Making a website load instantly is a goddamn miracle these days – despite every resource available to us in the developed world – and yet, it's also the kind of a thing that makes people fall in love with what you develop.
30kB is not much, but it's not nothing. After downloading, it needs parsing, which takes some CPU time. Call it micro-optimization, and you wouldn't be wrong to do so, but I'd rather whole-ass the thing I'm trying to accomplish – and performance is always one of those. Ideally, Intercooler could be independed from jQuery, since jQuery is just a library of native JS functions composed for comfort of use. It ain't gonna be swift, but Intercooler can be rewritten – and when it is, the load and parsing time for your JS dependencies will be reduced by half.
I was asking about HTTP/2 because of the issue with spritesheets potentially taking more time to load than individual icons, and taking away the opportunity to size the icons afterwards. The former has, apparently, been debunked even under HTTP/2. The latter is still an issue, and it may be resolved by using super tiny SVG icons (the set isn't complete – for example, there are no newspaper icons – but they can be added). Those can even be embedded into stylesheets via base64-encoding, which may improve performance.[citation needed]
I'm not saying this is an urgent matter, or that it hurts Tildes much. You've done a great job keeping Tildes light so far. I just think that, if it's worth doing, it's worth doing right. Since I have some time on my hands right now, I'd be happy to assist. I don't want to talk out of my ass about this; you guys seem to be doing something good here, and if I can make it even better, I might as well.
Can someone explain what's wrong with using JS and CSS, and what the better alternative is? Semi-layman's question, just wondering why JS and the lot cause performance issues.
There is nothing inherently wrong with JS or CSS. However the unfortunate reality is that they are very often used to excess nowadays instead of simply as supplements to HTML as they were originally used for. This section of Tilde's Technical Goals document does a pretty good job of explaining it further:
https://docs.tildes.net/technical-goals#minimal-javascript-dont-flip-the-web-pyramid
Excellent point.
I, for my part, am going to try and define "to excess" for any potential layman reading.
On loading, any page you access gathers all the resources assigned to it – stylesheets, JS libraries, icons, SVGs, images, HTML, server data – and builds itself using this information. Ideally, it's possible to set it up so that it loads the main content quickly, and the rest – as you use the page. (For example, an article loads its text first, and the images load over time as you scroll down to read.) However, it takes a certain skill to do so, because this approach requires you to build some architecture from the code that would allow the page to load in this fashion, and it's not easy.
Some web developers choose to forgo putting all this effort in, despite the immense amount of resources required to build the page, and just load it all, one item after the other. The developer may be unskilled and unaware of the possibility – or they could choose to pay no respect to loading time, as long as the website kinda-sorta works. Either case brings up the infamous 10- or even 20-second loading times for popular international websites, such as newspapers, corporation websites, or news aggregators. You might not stick around that long for something you're not sure about the quality of.
Now, maybe some of the stuff you load is necessary. The stylesheet that makes the site look pretty or even usable – you gotta have that. The logo at the top? That's good to have. The JS code that enables site functionality? Can't go without that.
But a lot of it is often unnecessary, or even useless. Some websites load half a dozen of different analytics libraries in order to track as wide an amount of measurements about user activity as possible. Some load huge images when smaller ones will do. Some use hundreds of stylesheets just to style the main page, which is a ridiculous number of stylesheets per website, let alone per page.
There's also a number of less-than-desirable practices in place in order to "score some users" – an awful, inhumane concept that some websites chase because they wrongfully measure numbers, rather than meaningful engagement or other important, non-numeric metrics, as their value of success. Things like pop-ups suggesting the users subscribe, for example. They require maintainance to keep up, and resources to create/load initially. They're unpleasant, lifeless, undesirable by all but the people who benefit from them.
Then there's things you can do natively in the browser, that the developers use a library or a heavy CSS framework for. Animations and advanced JS processes are just the tip of the iceberg here. Even Tildes has shades of this – though degrees of magnitude less than some of the average examples. (@Deimos, minify your JS.) It takes work to get done, but in the end, the website loads faster, the users are happier, and the metrics are growing. It's almost as if to be loved, you have to let go.
JS and CSS are good. Excessive JS and CSS are bad for everyone. Using more than you need lowers the bar for everyone else. People think they can get away with overweight websites whose functionality is out-of-its-own-scope and eats up a lot of computer resources – CPU, GPU, RAM – to do what's a drop in the barrel for user experience. That's mostly what people mean when they talk about using JS and CSS "to excess".
I'm goimg to speak from my experience as the user of a now-useless-on-the-web-netbook owner as I am not a developer, and break it down by levels.
What you see: the website serves one purpose: provide information. I have had broadband for 13 years, so network speed is not the issue. Even around 2005, the only javascript on a page was to push you to a section, or in the case if very flashy, forward-thinking sites, provide a submenu. Flash or java (or ActiveX if you used IE), a plugin/program that didn't run unless called, and generally did the heavy lifting.
What you need: you need, at most, text and images. I could whip up something in five minutes with my Dummy's Guide to HTML4 (not a developer) that is as informative as the most convoluted marketing website, but it won't look as good. CSS and Javascript (but mostly Javascript, via HTML5 and previously AJAX in AJAX'S later days) offset a lot of rendering responsibility to the client machine (the PC with a browser) rather than the host machine (the server).
It isn't that Javascript sucks, or CSS is bad, but that they began, and tend to be used, where html would work just as fine, and are used excessively, generally at the expense of user experience.
The look part is mostly CSS, which is pretty cheap. You can have a modern looking website with the speed of SSR. This chart is Chrome's devtools breakdown for reloading this tildes page. As you can see, the time spent on CSS (Rendering) is about half of what was spent on JS (Scripting). Inspecting the network tab shows that the total site was about 104KB. CSS was 40KB, JS was 47KB. So, even though there were about the same amount of JS/CSS, the JS took twice as long.
tl;dr: you can have your cake and eat it too because CSS is really inexpensive
It was more in reference to javascript, which, as Ibmentioned, saw heavy use to make pages look cool with animations and the like.