Amazing hack with the SVG mask and embedded JPEG to compensate for web browsers not supporting WebP images! This trick was used to get an image that has both transparency and lossy compression.
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. :)
This is neat, in a look-what-i-can-do sort of way. And I do appreciate the write-up. However.... (and there's always a but) does this page convert better? And if it doesn't, will they have the guts to rollback?
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 think this question is just as much about data as it is intuitive and feelings. Does a rollback make the front page of HN? Does the newer version leave a lasting impression that can't be measured? I don't think you can truly measure these things without actually measuring sentiment, etc.
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.
Yeah. You can optimize as many metrics as you want, but you never have all the metrics. You can optimize your kid's soccer/chess/piano/judo skills too. Maybe it will allow them to live the life of their dreams. Or maybe you completely crush their happiness. I know it's not the same, but hopefully people will get the idea. If something doesn't look healthy, trust your instinct too and not only the metrics. They don't capture everything.
i hate the new circular avatars. A few weeks ago, github avatars were square and it looked much better. It is also contrary to the published github visual guidelines.
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.
This is a pretty typical Atlassian experience. They push changes and will often ignore negative feedback which results in flames.
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)
I use to feel the same way, but I've been slowly incorporating the circular avatars into my own solution. I don't know why GitHub changed things, but from my own personal experience, I've found circular avatars to be "less distracting".
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.
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.
And then showing a half-screen tall banner on every page load! Why even bother to make the page fast if you are going me to make waste 100x the time scrolling down to the content?
oh, network costs with a PR spin on user benefits. got it.
The "Avoiding animation pollution" section has a few minor typos,
`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.
I think it means fast, but it's used when someone wants a buzzword. I wish people would use fast instead. I feel the same way with learnings (use lessons).
* 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.
"Performs well" presumably. Like "observant" means "observes well". This is more general than "fast" since there are other metrics by which performance can be measured.
I think you'll still be clicking on links taking you to repository pages. I think I've gone to the homepage only whenever people complain about the design (last I heard it had gone enterprisey).
I thought this was gonna be about making the actual GitHub fast and performant, but no it's optimization for the weird landing page that I'm not quite sure why it exists in a world where 1) GitHub makes money from Orgs, not individuals 2) Microsoft owns GitHub and 3) MSFT has a deep enterprise sales pipeline.
You know what pages I'd like to be fast and performant on github? The PR discussion and diff page. When a PR gets really large (thousands of LOCs and hundreds of comments) (yes I know it's bad to do that, that doesn't help me a lot when it happens), despite them hiding everything so you need dozens of clicks in order to be able to actually read and search through it's slow as hell and it's a mess.
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.
I think the ideal scenario for the make-a-PR page would be for it to load in the commit list and diff asynchronously— so you get it quickly in the normal case where it's small, but you can just ignore the spinner and click through when it's large.
Too be fair it looks like those pages are slightly above the average (mean and median) of the six sites on https://forgeperf.org/. Speaking of which it would be nice if ddevault would add each sites homepage there, just as bonus data (obviously not as useful as the stuff already there).
Is there anything novel here? GitHub is nowhere close to a delight as people make it out to be. Settling for GitHub creates as many problems as it solves. This is not a recent development, and there's nothing surprising about any of this (at least it shouldn't be considered surprising at this point).
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.
Fair enough, but is there a viable alternative? Continuing withe the OP's main complaint: Gitlab's PR review is also slow and not even for a 1000 LOCs, feels even slower to me than Github actually.
Of course there is. There's Gitlab and Gitea, at the very least. They aren't very popular, but they don't need to be as long as signing up is easy or as long as they offer federated/social login.
What's the five-dollar bill in this metaphor? I'd like to use it. Currently my employer has told me to use a one-dollar bill. As I continue with your metaphor, I struggle to see what insight it's giving.
Creator of Reviewable here. It's been a while since I used Critique, but if anyone in the know wants to tip us off on features we're missing that would make Reviewable a "five dollar" tool we'd love to add those in!
I have hit the final crater you mentioned so often, I now manually visit the url /myorg/myrepo/compare/old-master...my-new-feature to start the PR instead of clicking "Create PR" or "Compare"
GitLab also does the PR thing, always suggesting the default branch when there are thousands of commits between them instead of the branch that is just a fast forward.
I don't understand the fad in making content flop around the page as one scrolls. At the very least, it would be courteous of them to respect the prefers-reduced-motion media query.
> Most people don't go to a website to have an "experience".
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.
It also doesn't animate text though. The content is all in place, with pretty animations and such in the background.
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.
I believe stripe's designers include @destroytoday, his design of paper 53 impressed me a lot several years ago [1]. Surely it also contains animations, but it's more elegant and smoother.
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.
Everybody talks about speed and how it affects conversion (since people don’t bounce for example) and traffic (since Google uses speed as ranking factor). But whenever I talk to site owners they seem to prefer new features over site speed. Is that only my perception or something bigger than that? Maybe speed is not that important in the end?
You may have answered your own question. Users of the website prefer speed while owners of the website prefer features. Maybe the site owners are not listening to users or believe they are building something that is better than speed and the users will be won over in the end?
Feature Factory, where the primary measure of success is features delivered and nobody ever bothers to find out of those features are used or even wanted.
This JPGs-in-a-SVG thing is grotesque, an example of how web development often seems like a Jenga tower of hacks. Why not find minimally-perceptible pixel changes to the image that allow it to compress better as PNG?
> Why not find minimally-perceptible pixel changes to the image that allow it to compress better as PNG?
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.
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.
There are a few lossy transformations you can make to an image before saving it as a PNG that result in a lossy compressed PNG that's smaller than the image otherwise would be. This idea was used a ton with GIFs, it's less popular with PNGs, though. pngquant is one tool I know of that does this.
That said, I have no clue if such techniques would result in a smaller image than this approach.
It's weird to me how the designers/developers behind this homepage globe basically copied dozens of other startups who already "conceived" (from their own respective vantage points) and implemented this visual storytelling device as some unique expression of their own "brand story". You can find spinning globes with pings and arcs like this on at least 10+ different websites that have been around for 5+ years. You can even license it from places like https://globekit.co. Hell, even Stripe has one on their homepage, and they were late to the game on cashing in on this visualization. At least they're not self-aggrandizing it.
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.
The never ending tug of war: Developers decrease load speed from 3 seconds to 1 second. Company decides they now have 2 extra seconds of load time to include more analytics, larger splash videos, animations, etc. Before long, the site is back to loading in 3 seconds and a richer (more bloated) web experience is born.
And hopefully, some of those extra analytics, animations, and experiences add value. One great thing about high performance on the fundamentals is that it let’s us move to a higher level of abstraction.
It's nice when performance improvements can be abstracted away or optimized in the browser. HTTP2/3 are good examples.
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).
Talking about nice looking homepages that load fast the first one that came to mind is Stripe's.
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!
Wow. It's been a while I hadn't a look at the Stripe homepage. This is raising the bar. How does one go about drawing those nice device mockups with code? I assume it's a combination of svgs and canvas, but probably built using specific software?
I'm using a Mid-2015 MacBook Pro and it's far from performant for me. Assuming it's mostly new users who see the homepage page, do they assume their new users have high-end computers?
143 comments
[ 0.17 ms ] story [ 200 ms ] threadI 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. :)
You can scroll from other parts of the page.
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.
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.
https://jira.atlassian.com/browse/CONFSERVER-28275
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.
https://imgur.com/a/2nlXekJ
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.
oh, network costs with a PR spin on user benefits. got it.
`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.
* 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...
Newbies!
You used to be a newbie to. Remember?
Almost never happens.
I guess Microsoft knows their own business, but surely most users must arrive at GitHub on the page for a specific repo, right?
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
[0]: https://hub.github.com/hub-pull-request.1.html
https://marketplace.visualstudio.com/items?itemName=GitHub.v...
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.
[1] https://destroytoday.com/blog/building-the-pencil-page
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 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.
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.
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)
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
https://www.checkbot.io/article/web-page-screenshots-with-sv...