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

Can You Afford It? Real-World Web Performance Budgets

infrequently.org

Post reply on HN
Print view View original

61–70 of 130 posts

Re: Can You Afford It? Real-World Web Performance Budgets

#61

Post by kevincennis »

virmundi wrote: post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

It’s all about how and where you use it.

Imagine a world without AJAX. This is obviously an opinion, but it would be super annoying if every button I clicked sent a raw POST to the server and refreshed the page.

Do news sites need to be rendered client-side with React + Redux + React Router + all the Babel polyfill garbage? No, I don’t think they do.

But some sites are definitely better in my mind for being SPAs.

The problem is that people pick technology that they like or are familiar with instead of working backwards from the ideal user experience. What we should be doing is picking the minimal set of technology that achieves the UX goals of a project. Instead, you have people loading 200kB of dependencies to render pages with a level of interactivity that could be achieved with 30 lines of vanilla JS. Oh, and then Google, FB, Twitter, and Optimizely tracking scripts.

Re: Can You Afford It? Real-World Web Performance Budgets

#62

Post by albertgoeswoof »

mac01021 wrote: post #57
virmundi wrote: post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

I'm no fan of “modern js-based design”, but I can pay for a lot less server if I can get the client to do all the rendering for me.

I would wager that most people who say this have never actually calculated the cost of server side rendering vs bandwidth costs + users dropping off the site

Re: Can You Afford It? Real-World Web Performance Budgets

#63

Post by liveoneggs »

virmundi wrote: post #5

Do we need all this JS? I’m starting to look back at classic web development where you had a server rendered mvc style app. There was a controller and templates populated on the server. Every page was a full rerender, but it was small html. Proper caching kept the minimal CSS and images on the client for a regular session under 30 minutes. This seems better. I know we switched because front end experts told us that u…

people want (in ecommerce sites, news sites, actual websites, etc): working back buttons, regular scrolling, open-in-new-tab that works, elements that don't move around, obvious and not-hidden navigation, and also tons of gimmicky/flashy crap.

people want (in desktop replacement spa's where they spend hours and hours): app-appropriate usages of keyboard nav; background tasks with status windows, working back buttons that don't stop the music stream; links that work like links & app-clickables that work like buttons; refresh buttons that refresh (via a page reload) their current full state, but working.

Re: Can You Afford It? Real-World Web Performance Budgets

#64

Post by JepZ »

Actually, I think it is more important to be aware of the issues and handle them than to set strict size limits. For example, a few years ago I lead a redesign project for a mobile web shop and the designer told me he was not allowed to include icons as our CIO had set the limit of the page size to 100k (including all images).

By the end of the project the page size was about 200k, but when the sales were ~20% higher (multi million $ shop) nobody asked about the size limit anymore.

So yeah, page size/load time is important, but please keep reflecting what you are doing. The best load times are no good, if (as a result) the UX is poor.

Re: Can You Afford It? Real-World Web Performance Budgets

#65

Post by Retric »

andrewstuart2 wrote: post #26
Retric wrote: post #21

Earlier quoted context omitted.

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.

Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.

Frameworks are simpler to implement and maintain, that does not make them better for users.

Re: Can You Afford It? Real-World Web Performance Budgets

#66

Post by Retric »

ozim wrote: post #47
Retric wrote: post #21

Earlier quoted context omitted.

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.

"I did autocomplete using a few carefully crafted lines of code" Now take 10 developers to reuse that autocomplete in the same project in 10 different places. I bet those carefully crafted lines become 100 little monsters, one without eye other with 3 legs. Not that they have to be stupid, it is just they think differently.

Users don't care about development. Sure, for us frameworks are great, for them the trade offs look far worse.

Re: Can You Afford It? Real-World Web Performance Budgets

#67

Post by TeMPOraL »

ehnto wrote: post #46
aaron-lebo wrote: post #31

Earlier quoted context omitted.

How do you notify a user of errors in input without a complete page refresh if you do not use Javascript (ignoring the most basic HTML stuff)? Without at least some scripting capability, you're talking about making the experience worse for the user to the benefit (ease of the request/response model) of the developer. Don't throw the baby out with the bathwater. It is the responsibility of devs to use technology well.…

You just let the page refresh. It's really not that much different. I am not saying don't use JS for UX improvements mind you. But your comment suggests that any other approach makes no sense. If you have a massive form that has 12 fields then it would be a huge help, but just a couple of text fields? Why replicate the backend validation in client side JS when it's already there on the backend? Then you would have to…

This. You can't trust client-side validation anyway, so you need to have some server-side. So why not just let the page refresh, and then add a tiny bit of JavaScript that'll send off the form via AJAX to validation?

Suddenly, the site becomes solid, lightweight, and supports everyone. That's what I think people used to call "progressive enhancement".

Re: Can You Afford It? Real-World Web Performance Budgets

#68

Post by TeMPOraL »

digi_owl wrote: post #42
feelin_googley wrote: post #28

Earlier quoted context omitted.

"Do we need all this JS?" I know at least one user who is asking this same question. He does not believe it is needed. Is it possible that "what users want" and what developers want may be two different things? Could developers have wants that are unique to developers? Purely anecdotal but I do not know any fellow users who "want javascript". I know many who do not want a number of common annoyances though. And I kno…

> Could developers have wants that are unique to developers? There seems to be a sizable portion of this, and far from limited to the web world. That said, some of it may also come from the managerial level. This thanks to cargo culting akin to the offshoring fever a decade or two back. meaning that management is pushing for something to be done in a certain way because they read about some big name corp doing the sa…

I'd say it's half fashion and half business incentives. JS frameworks are fashionable, every kid learns JS and Node now, and this leads to what I see as a big part of programmer population suffering from acute "only-got-hammer-everything-is-nails" syndrome. But business incentives play a big part too. It's easier to make a shitty SPA than a well-engineered site, but all the shittiness gets externalized on the users, so companies don't care - they get to be little quicker to market, but they don't have to pay for the worldwide waste of electricity and bandwidth they cause.

(Not to mention user frustration. Mainstream webdev doesn't give a damn about that either.)

Re: Can You Afford It? Real-World Web Performance Budgets

#69

Post by TeMPOraL »

andrewstuart2 wrote: post #26
Retric wrote: post #21

Earlier quoted context omitted.

You can do all of that with very lightweight JavaScript though. 10+ years ago I did autocomplete using a few carefully crafted lines of code and the page still renders just fine. The problem is JS frameworks make development easier but have high real world costs that are often ignored.

Your second sentence describes engineering trade-offs. The simplest engineering solution to a canyon is to walk around it. The most practical or productive solution over the long run is a different question entirely from the simplest or easiest to implement.

Yup, those are engineering trade-offs. Making your life a little easier by causing users a disproportionate amount of resource waste, frustration and security issues is just shitty engineering. Even though the business types may like it, because externalities are good for profit.

Re: Can You Afford It? Real-World Web Performance Budgets

#70

Post by samsonradu »

davidgh wrote: post #56
iamthepieman wrote: post #27

Earlier quoted context omitted.

I agree with you for content sites or primarily consumption driven apps but I haven't written one of those in 8 years. I'm currently working on an application that we are having to purposefully keep features out of, not because they are slowing the page down, or increasing TTI, but because we risk offending our business partners by building a one for one replacement of their multi-thousand dollar per seat desktop sof…

This. Set aside the performance of the initial load for a moment. When I interact with the SPAs we’ve built in recent years, I am still shocked how snappy they are as I perform actions throughout the site. Every “pageview” requires the download of a tiny REST API response and comparably tiny HTML fragment. As a user - that experience is a pure delight compared to a full blown page re-load, re-download and re-render w…

> As a user it infuriates me when I fill out a long form, hit submit and find out I forgot to select the proper “Mr. Mrs. Ms” title and my password, credit card number and PIN have all be blown away.

I'm quite sure this is a sign of poor development, regardless of the form being validated on the server or the client. There is no reason for the server not to send back a fully pre-populated form.

Post reply on HN