Making our new homepage fast and performant
github.blog
github.blog
This is not helped by some really counter-productive events being logged interspersed with discussions e.g. any time a label is updated, that's a new line in the discussions log. Is that useful? Almost never! I can't remember wondering "wow when was this PR marked as E-Easy?" It could be useful to have a unified history of all events on the PR in a separate tab, which would include things like comment editions properly positioned in the PR timeline (instead of each comment having its own little history) for PR forensics, but the current version is just inconvenient.
Talking about, having a FAYT which can actually search through the diffs without having to first go through the entire page, find which files are not shown and forcing them to load would be super useful.
An other fun performance crater while I'm at it: when you try to create a PR github target the "default" branch. Always. Period. When you work on a project with a "long and storied" history and you're trying to do something on an old branch, or the default branch is not the development head and you're trying to create a PR to that, it will try to diff two essentially unrelated branches, take tens of seconds to create a gigantic (and completely unnecessary) log and diff, timeout half the time, and it's all for nothing, it'd be more useful to immediately give me a dropdown letting me select a target branch.
Agreed with the PRs. I've experienced times where typing in the description box and other actions where extremely lagged on large PRs.
What's interesting that if you ask people why they love GitHub, they'll probably say, "because of its community and its UI — they're great!" and if you ask people who hate GitHub why they hate it, they'll agree that it's about the community and the UI — except, from their perspective?: "They're terrible." It's not hard to figure out what's up with the disparity.
GitHub is a two-dollar bill: better than a one-dollar bill, and worse than a five.
This commenter says reviewable.io is closeish: https://news.ycombinator.com/item?id=19102930
https://marketplace.visualstudio.com/items?itemName=GitHub.v...
pr !open "$(git remote -v | grep origin | grep push | cut -f 2 | cut -d " " -f 1 | sed -e "s|git@\(.*\):\(.*\).git|https://\1/\2|")/pull/new/$(git rev-parse --abbrev-ref HEAD)"https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...
Most people don't go to a website to have an "experience". They just want to find some information as fast and easily as possible.
Well, with the things that people do routinely, they rarely do it for the experience. But that does not mean they do not experience it. That experience should certainly be prioritized while keeping the goal of the users as a top priority.
The only thing I want is some info and to get out. Very few people go to a business website to enjoy the animations.
Edit: No one goes -> very few people go, shout-out to DylanDmitri and Stripe.
I like Stripe's page a lot better than this one though, for reasons I mention in my response to DylanDmitri.
Not my preferred look, which is admittedly pretty spartan, but it works.
Edit: It does animate the code being typed. But that seems less critical to me then the main body. I would still prefer it to be static personally, but it works.
it's wildly confusing, unless you scroll very slowly and wait for (most of the) things to stop animating
Oh I have vivid memories.
Mac Pro Trashcan 2013. If I remember correctly it was the first time Apple turns to using lots of animations for their product page. Before that Apple's product page were fast, beautiful and elegant.
The TrashCan webpage was using lots of animations to show case their cant innovate anymore my ass. Your MacBook Fan would spin up simply by scrolling through the page as if Apple were nagging you its time to upgrade your Mac.
I think they learned their lesson and tune down those animation abit with later products and pay more attention to performance. But since then it has spread across the industry like plague. You dont get fired for using and designing with flashy animation because Apple are doing it.
I also remember that for the longest time ever they had a far too clever trick to show movie-quality videos at a time when browsers didn't really have video. They would have dozens of png pictures that they would stitch and change on the fly using Javascript. And it worked surprisingly well.
Thanks for this. (Yet) another fingerprinting vector I didn't know about.
I would have loved to see the face of the engineer who thought of this hack, tried it, and saw that it worked for the first time. :)
It starts with 952.83 KB / 364 KB transferred and goes to 1.70 MB / 482.03 KB transferred on final load (once you reach the bottom of the page) Github's starts with 3.10 MB / 969.27 KB transferred and goes to 6.64 MB / 4.54 MB transferred
Yeah, Github's homepage has more content, it's true... but what I find really amazing about Stripe's homepage is that those kind of previews of their interface are not images, they are built with actual code!
Stripe has a really awesome dev culture, problem solving to the next level, also on their homepage!
edit: typo
History moves in a spiral.
Something like lazy loading images could be implemented in the browser, but instead we each spend time devising our own lazy loading hacks. Vendors add W3C specs like IntersectionObserver to an ever growing list of web API's that must overwhelm new comers.
I guess it's nice that we have complete control over everything but the web reminds me of Android (more control/complicated). I want Apple (works well enough/simple).
intersectionobserver still has a ton of use cases where it's massively faster than continuously monitoring the scroll event (e.g. infinite scrolling)
Newbies!
You used to be a newbie to. Remember?
Almost never happens.
Animations that jump out at you as you scroll always seem like a great idea, but are a misfeature to be avoided, since they distract from the content, and give across this 'trying too hard' vibe which I personally never liked.
I don't know anything about the politics behind github and the employees. I'm sure they're all wonderful people. This is just a projection from my company. Even if the new flashy design performed 20% worse, it wouldn't be gotten rid of. They would say something like "well, 20% isn't that bad. it just needs time to bed in" or something like that. Fast-forward a year, and we still have the crappy performing good-looking page!
I'm sure Netflix has seen increased metrics across the board but everything they've done and added in the last three years or so has turned me against the brand. As a very happy subscriber since 2002 I stopped in 2019. Anecdotal and maybe just me but I don't think everything is about some 28-day conversion metric.
I think it's more about the guts to do something you believe in and trusting the people you hire than just metrics.
Imagine the ridiculous amount of money that has to have been spent on the spinning globe thing. Enough not to have a random blog post talking about, it but a five-part SERIES!!!
The frontpage eats up almost 90% CPU on firefox on my computer[0] and not as much, but still high in chrome. Maybe that has something to do with graphics acceleration, or my computer isn't good enough, or some other thing where it's my fault.. But it's ironic the situation exists for a site with a five-part series describing how "performant" it is.
Scrolling down the site loads up 4.5 MB of bandwidth transferred, 6.5 MB resources loaded, and 110 requests. Could be worse, but the fact this almost seems 'normal' now is a sad state of affairs.
As an aside, I understand this is GitHub's primary marketing vehicle to really Impress and Wow newcomers to the site -- hoping to blow them away with neon graphics and slick animation. But honestly, is this kind of dribbble.com-esque readymade really impressing anyone these days?! Have years of A/B testing determined that a neon space adventure yields the highest level of new user signups??[1]
The thing is, who are these newcomers? Who ever ends up on GitHub's homepage? What company is gonna take this globe thingy into account when deciding to use GitHub or not?
This looks like such a waste of money/time.
https://github.blog/wp-content/uploads/2021/01/106009495-af8...
Edit: Since it's a little confusing how to find it, I made this: https://i.imgur.com/sQpHFoU.png
EDIT: quote from the current github style guide:
Avatars are images that users can set as their profile picture. On GitHub, they're always going to be rounded squares. They can be custom photos, uploaded by users, or generated as Identicons as a placeholder.
When I had to use them at previous jobs, I had a couple of favorite threads that I liked to follow. One of these was "Hitting Escape key while editing issue description loses contents" [1] which took about five years to address. Another was "Was blame removed from source tree?" [2] where Atlassian decided to reference "blame" as "annotate" without announcing the change, but did it because "blame" is a bad word (there was more on that thread from the devs themselves, but they apparently have deleted their posts)
[1] https://jira.atlassian.com/browse/JRASERVER-36670 [2] https://community.atlassian.com/t5/Sourcetree-questions/Was-...
I'm guessing by cropping more of the image, my attention doesn't focus on them as long. If I want the focus to last longer, I'll still use rectangular avatars since they contain more information. See example below to see how I mix-match things.
oh, network costs with a PR spin on user benefits. got it.
- Starts to explain how to use the most obscure javascript functions
- Explains how to show a real time , websocket animated globe of users of github
Lol
You can scroll from other parts of the page.
From a browser compatibility perspective though it's not much different. We are waiting on lagging support for certain browser features because Apple is gating them behind OSX upgrades.
Further, Apple seems to show little interest in improving. About what you'd expect from somebody high on their own market position(dominant on OSX and exclusive on IOS until recently). So, a lot like IE back in the day IMHO.
- Chrome: 7602 web APIs
- Firefox: 6572 web APIs
- Safari: 6335 web APIs
(Web APIs include everything, including CSS, see API catalog at the top right of the page).
If anything, Firefox is identical to Safari. This is especially evident if you look at the "browser-specific" tag
Safari is adding 150 to 400 new APIs with each release. It's harder to see this because their cadence has historically been tied to new OS releases (so, yearly, and really wish they'd increase the cadence). Meanwhile, in the latest version alone Chrome released 75 new APIs. And they release 20 to 70 new APIs in every version which they release monthly [1].
Yes, Safari may be less prioritized than other teams at Apple, but in no conceivable way, shape, or form are they "the new IE6".
> there are a growing number of areas where Chrome and Firefox have nearly identical behavior and Safari is the odd one out.
...is definitely true for me when developing relatively simple sites. I develop in Firefox and it's been a long time since I've had to change any CSS to make it work in Chrome. Meanwhile Safari has had broken default SVG sizing for years now (unless they fixed it recently), ignores padding on <select> (so you need to set the height) and other things like that.
It's all minor, but it's annoying to deal with. Especially considering you need Apple hardware to test with.
But I can't complain too much, since I also still need to support IE11.
* Consistent UI performance under load. Not the same as "goes faster", just "doesn't slow down".
* More efficient resource/CPU utilization.
* Smarter loading of resources (kind of a sub point of 1)
I think they're trying to say it's "consistently not-slow and efficient with resources". Does "fast" express that well? To grandma, sure. To a technical audience, no.
https://dictionary.cambridge.org/us/dictionary/english/perfo...
`transition: * 0.6s ease` won't work anyway, `*` is a selector, they're looking for a value of `all`. Omitting the transition property all together (i.e. `transition: 1s`) is what people often do but this is bad practice for the reasons they stated.
Also, for the CSS examples I believe they mean to set `.animated:hover` to `opacity: 1;` not 0.
I like the idea of using an SVG mask to make a transparent background on the jpg.
This was raised in previous submissions on HN, and apparently even acknowledged, but I assume they completely dismiss this to the point of not even bothering (as far as I can tell) to test acceleration support in the browser.
I would bet a whole pizza, anchovies included, that you'd be the first one to fire an engineer who wasted his time pixel-perfecting a random PNG on your homepage under the guise of performance, when this is actually an alternative.
The JPG-in-SVG is a beautiful hack to work around Apple's former refusal to support WebP. You can just use WebP if you are okay giving older iOS/macOS users the finger. This isn't web dev being "hacky", it's Apple being shitty.
Hasn't HN always celebrated such hacks?
The fact is, if you know how JPG and PNG work, you'll know that a colorful and busy image like the one linked in the article, with lots of varying alpha colors and values for anti-aliasing, is basically impossible to compress anywhere close to a JPG.
There are more lossy ways to compress PNG which aren't done automatically anywhere to my knowledge, such as reducing the amount of colors to fit a smaller color space.
What you can also do is turn the image into contiguous chunks so that they are in a pattern that is more compressib… wait, we're just reinventing JPG aren't we.
That said, I have no clue if such techniques would result in a smaller image than this approach.
Can someone explain to me why even simple static-content websites are so fucked up nowadays? Where does it come from? Who does it benefit? What drives this madness?
Normal people don't see the web the same way HN does. Normal people like pretty things, and people like creating pretty things. Designers wanted to creat a pretty webapge, and I found said webpage pretty. Not to mention that the website loads pretty quickly, so all those complaints about performance are incredibly hollow. If someone is working with 2g internet they have bigger issues than trying to visit Github's homepage.
Issue and PR pages desperately need pagination.
[0] incorrect word/grammar. [1] also not a word. [2] actually a word but don't use it. [3] not correct.
The google incantation (yielding its definition as a computing jargon term for "functioning as expected") seems to be "performant definition" but "performant" is still a terrible word.
Regrettably, this unfortunate usage of "performant" is common in our field (and on HN) and is already infecting dictionaries.
In this example it seems to be used as computing jargon for "good according to some (unspecified) performance criteria."
Google's (Oxford Languages) dictionary gives a similar definition:
(COMPUTING) adjective: performant: functioning well or as expected. "a highly performant database which is easy to use"
This would seem to be a very poor and unclear substitute for words like "fast" or "efficient" or "reliable" or even "effective."
Sure, talk about your data pipelines or whatever else seems technically engaging, but let's not pretend what you're doing was the result of some stroke of artistic genius in manifesting the spirit of some slideshow presentation your colleagues.
I guess Microsoft knows their own business, but surely most users must arrive at GitHub on the page for a specific repo, right?