Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Making our new homepage fast and performant

github.blog

Post reply on HN
Print view View original

61–70 of 144 posts

Re: Making our new homepage fast and performant

#61

Post by DylanDmitri »

pier25 wrote: post #34
Jayschwa wrote: post #25

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. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

I find them quite annoying. I'm pretty sure the only people enjoying these kind of animations are the designers themselves. 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.

To be fair, I go look at Stripe's homepage every couple months just because it's pretty.

Re: Making our new homepage fast and performant

#63

Post by boogies »

masklinn wrote: post #23

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…

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

Re: Making our new homepage fast and performant

#64

Post by cratermoon »

tppiotrowski wrote: post #30
baxtr wrote: post #27

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.

Re: Making our new homepage fast and performant

#65

Post by Minor49er »

tppiotrowski wrote: post #33
enriquto wrote: post #11

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 placeho…

This reminds me of a massive flame war when Atlassian switched to circular avatars for projects https://jira.atlassian.com/browse/CONFSERVER-28275

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)

[1] https://jira.atlassian.com/browse/JRASERVER-36670 [2] https://community.atlassian.com/t5/Sourcetree-questions/Was-...

Re: Making our new homepage fast and performant

#66

Post by Palomides »

Jayschwa wrote: post #25

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. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

they say "we animate in certain elements to bring your attention to them" but so many things are moving!

it's wildly confusing, unless you scroll very slowly and wait for (most of the) things to stop animating

Re: Making our new homepage fast and performant

#67

Post by paxys »

Jayschwa wrote: post #25

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. https://developer.mozilla.org/en-US/docs/Web/CSS/@media/pref...

It's one of the few truly bad design paradigms made popular by Apple in recent years. Their site has always been full of it.

Re: Making our new homepage fast and performant

#68

Post by Rapzid »

masklinn wrote: post #23

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…

The only time I was on the GH homepage in the past.. years was when they announced that animated globe.

Agreed with the PRs. I've experienced times where typing in the description box and other actions where extremely lagged on large PRs.

Re: Making our new homepage fast and performant

#69

Post by pentaxy »

It's not a good image for GitHub and authors when they make a dedicated post about performance with "fast and performant" in the headline, even boast a 10pp CPU usage difference, when: 1) it gets close to max CPU usage, and 2) still stutters, even on modern processors; with hardware acceleration disabled.

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.

Post reply on HN