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

How we improved our website's performance

smashingmagazine.com

Post reply on HN
Print view View original

51–60 of 76 posts

Re: How we improved our website's performance

#51

Post by joegahona »

markdown wrote: post #27
seanwilson wrote: post #25

> Around the same time we switched from an (outdated) manually created critical CSS file to an automated system that was generating critical CSS for every template — homepage, article, product page, event, job board, and so on — and inline critical CSS during the build time. Yet we didn’t really realize how much heavier the automatically generated critical CSS was. Is reducing the total amount of CSS per page so you…

The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Have you considered inlining CSS in the head (as you've done), but then serving it again with a linked css file just before . Then, with subsequent page loads (of the current or other pages), you don't have to…

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load.

The vast majority of users will visit one and only one page.

Re: How we improved our website's performance

#53

Post by httpsterio »

joegahona wrote: post #51
markdown wrote: post #27

Earlier quoted context omitted.

The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Have you considered inlining CSS in the head (as you've done), but then serving it again with a linked css file just before . Then, with subsequent page loads (of the current or other pages), you don't have to…

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.

why would you optimize your website for someone who only visits the one page?

Re: How we improved our website's performance

#54

Post by phist_mcgee »

httpsterio wrote: post #53
joegahona wrote: post #51

Earlier quoted context omitted.

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.

why would you optimize your website for someone who only visits the one page?

Because for every second of delay you add, you reduce your potential audience by a large degree. You optimise for first impressions, even though you know that a major proportion will click away anyway.

Re: How we improved our website's performance

#55

Post by phist_mcgee »

systemvoltage wrote: post #48
halfmatthalfcat wrote: post #45

Earlier quoted context omitted.

This is such a tired take. Logic has been moved from the backend to the frontend (again) which has justified the complexity.

> This is such a tired take Quite the opposite. It needs to be hammered into people. Your app isn't Notion or Google Docs. Your app is a form with a login menu and a couple of small logic elements and a date picker.

So what? Just because your application is simple, does not mean you need to use vanilla tools. Do you get mad at a carpenter for using a nail gun because he 'can more easily swing a hammer'? It is the application of tools not the tools themselves that is the problem.

I really can't understand why so many people rag on frontend development as if we (as frontend developers) are just magpies who gather shiny things and don't care about performance or simplicity.

Re: How we improved our website's performance

#56

Post by seanwilson »

httpsterio wrote: post #53
joegahona wrote: post #51

Earlier quoted context omitted.

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.

why would you optimize your website for someone who only visits the one page?

On the extreme end, consider someone on a spotty and slow mobile connection going through Google results to find what they want. They're only going to give you a few seconds before they hit "back" on your site and try another. The round trip for the browser to fetch the CSS file after the HTML file arrives can be enough to cause that delay.

Re: How we improved our website's performance

#57

Post by systemvoltage »

phist_mcgee wrote: post #55
systemvoltage wrote: post #48

Earlier quoted context omitted.

> This is such a tired take Quite the opposite. It needs to be hammered into people. Your app isn't Notion or Google Docs. Your app is a form with a login menu and a couple of small logic elements and a date picker.

So what? Just because your application is simple, does not mean you need to use vanilla tools. Do you get mad at a carpenter for using a nail gun because he 'can more easily swing a hammer'? It is the application of tools not the tools themselves that is the problem. I really can't understand why so many people rag on frontend development as if we (as frontend developers) are just magpies who gather shiny things and…

> I really can't understand why so many people rag on frontend development

May be you should try to listen to them more carefully and make an attempt to understand their woes.

Re: How we improved our website's performance

#58

Post by halfmatthalfcat »

systemvoltage wrote: post #57
phist_mcgee wrote: post #55

Earlier quoted context omitted.

So what? Just because your application is simple, does not mean you need to use vanilla tools. Do you get mad at a carpenter for using a nail gun because he 'can more easily swing a hammer'? It is the application of tools not the tools themselves that is the problem. I really can't understand why so many people rag on frontend development as if we (as frontend developers) are just magpies who gather shiny things and…

> I really can't understand why so many people rag on frontend development May be you should try to listen to them more carefully and make an attempt to understand their woes.

The problem is, most of those complaining have never tried to understand the complexity (and why it exists) because they've never built a highly complex frontend application! They're degrees removed and just throw stones from their glass houses.

Guess what, I'm not picking Spring to make a simple REST api when it takes 5 lines in Expressjs. Why? Spring is complete overkill. So along those lines, should you use React/Redux/Redux-{Thunk,Promise,Observable}/Navigation/etc if you need a simple 2 page site? NO! Jesus christ, you pick the right tool for the right job.

There's a reason though, when you have a highly complex app with insane business rules (that could very well be hidden from the airmchair HN crowd) where you need that complexity. And guess what, if you're highly versed in these "complex" frontend tools (spoiler: they're not complex), then it makes building sites, generally, very easy.

So go ahead, believe what you want and continue to parrot the "the frontend ecosystem is hopeless, needlessly complex and godless" while the rest of us continue developing with these "complex" tools because they make our lives as developers easier.

I'll sleep happy while you wait that one more second for the page to load.

Re: How we improved our website's performance

#59

Post by austhrow743 »

httpsterio wrote: post #53
joegahona wrote: post #51

Earlier quoted context omitted.

> The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. The vast majority of users will visit one and only one page.

why would you optimize your website for someone who only visits the one page?

Because most days you don't add more than one piece of content.

Re: How we improved our website's performance

#60

Post by onion2k »

markdown wrote: post #27
seanwilson wrote: post #25

> Around the same time we switched from an (outdated) manually created critical CSS file to an automated system that was generating critical CSS for every template — homepage, article, product page, event, job board, and so on — and inline critical CSS during the build time. Yet we didn’t really realize how much heavier the automatically generated critical CSS was. Is reducing the total amount of CSS per page so you…

The problem with inlining all CSS is serving all the global styles all over again with every page load. You're gaining a great first impression at the cost of a poorer experience for every subsequent page load. Have you considered inlining CSS in the head (as you've done), but then serving it again with a linked css file just before . Then, with subsequent page loads (of the current or other pages), you don't have to…

You'd need to add 'rel="prefetch"' to the link or the browser will block rendering until the CSS file has been downloaded, parsed, and added to the CSSOM.
Post reply on HN