•  henfredemars   ( @henfredemars@infosec.pub ) 
    link
    fedilink
    English
    91
    edit-2
    6 months ago

    At work we have this timecard management system that’s an enormous pain to use. All the bottom rung employees hate it because it’s anything but intuitive. For example, it has stupid things like weekdays sorted alphabetically and a scroll bar to select the day of the month in a form. It’s like the interfaces were tested exactly one time and never visited again, so long as it works minimally.

    What’s this crappy app have to do with big web pages? That application is awful for us worker bees, but management loves it because it produces nice reports. Management is the real customer for which the product is optimized. Similarly, many web pages are awful because they’re mainly rated on how it looks. Nobody is including how fast it loads in the contract, and at the product demo you bet those resources are cached in the browser.

    Ask yourself: who with the money in hand is actually looking at how fast the page loads on a slow connection or low-end devices?

    TLDR: Looks > performance.

    • it has stupid things like weekdays sorted alphabetically

      Holy shit, that’s stupid. Why would you even do this in the first place?! I can’t comprehend how anyone could come to the conclusion that that’s a good way to sort it.

    • At my current dev role I try to do optimizations to make new system area pages pretty lightweight, but it’s a bit of a struggle as I’m working with devs who have been in the same role for decades. WCAG is not prioritized, and they pull in a ton of JS libraries that usually aren’t even used. A lot of the practices I see in use are from 10 years ago, but slowly tidying up the horror show with each dev product meeting.

      Admittedly could be much worse though, at least our pages aren’t 21MB large.

  • If only they paid web developers more…

    I could not give two fucks about the memory efficiency of a web page I worked on since I barely take enough home to afford groceries.

    Unless they pay me more to care, it’s still your problem internet person.

  •  Ech   ( @ech@lemm.ee ) 
    link
    fedilink
    English
    546 months ago

    I have been just bewildered at the proliferation of excessive scripts and garbage on seemingly every webpage over the last decade. I’m no web-dev, but I’m pretty positive that the vast majority of websites could remove 99-some percent of their javascript bs and their websites would function just fine. So many are pretty much unusable these days. It’s atrocious.

    • I’ve been working at organizing a bunch of stuff I’ve been collecting over the years … data, writing, lists, ideas, whatever … I kept using all sorts of services, apps, websites, cloud services and all sorts of crap to maintain them all but eventually it all becomes too complicated and breaks down.

      I’ve since discovered just using simple text files and services that just use simple text mark down … no special service, nothing proprietary, easily transferable and interoperable.

      I started looking at websites the same way … I don’t care what it looks like, I just want to read the information … you made it too hard for me to read your simple text info? You’re asking me to turn off my ad blockers and turn on Java script? All to read 200 words on your site? I’ll skip it and move on to the next site that will allow me.

      •  legios   ( @legios@aussie.zone ) 
        link
        fedilink
        English
        12
        edit-2
        6 months ago

        I manage a web dev team. We try to optimise as much as possible but then there’s all sorts of tracking that gets tacked on by personalisation teams, opti teams, things like Tik Tok, Facebook, Twitter/X scripts inserted too… It’s pretty shit. And sometimes when things break it makes it super hard to debug too

    • I’m a web dev and yes they could. It’s annoying that web devs get blamed for it though, the reason for all the javascript is mostly business decisions out of our control.

      Mainly the tracking scripts which the marketing department adds against out will. But also it’s a lot cheaper to have a client-rendered web app than a traditional website (with client side rendering you can shut off all your web servers and just keep the api servers, our server side processing went down 90% in the switchover). And it’s more efficient for the company to have one team working in one programming language and one framework that can run the backend and frontend, so the frontend ends being a web app even if it’s not really necessary.

      •  Ech   ( @ech@lemm.ee ) 
        link
        fedilink
        English
        76 months ago

        Fwiw, I don’t blame the devs. That’s just me saying I’m not an expert. I understand it’s a management/corporate decision.

        And thanks for the explanation. That clarifies the changes I’ve been noticing.

  •  LiveLM   ( @LiveLM@lemmy.zip ) 
    link
    fedilink
    English
    25
    edit-2
    6 months ago

    You see, stuff like this is why I never understood the wave of “Android Go” and “Lite/Go” apps a couple of years ago.
    On my old low end phone, the native Twitter app ran infinitely better than the Web based “Twitter Lite”. This applied to almost every “Lite” app compared to their regular versions.
    I feel like whoever started that “Webapps are great for low end” concept never actually tried to run a modern Webapp on a slow phone.

    Edit: My comment is focused mostly on the push of Webapps on low end phones. I’m sure there are great, proper “Lite Apps”, and I quite like the idea of Android Go, I just think the implementation missed the mark and that a lot of companies pushed out a crappy, poorly thought out webview just to cash in the “Lite” trend without caring about the end user.

    • I only ever used the lite version of FB Messenger. Shit was much better than the full version, especially without all the bloated “features” that I didn’t use at best and being annoying/battery drains at worst. Was noticeably snappier on both my old and new phones. Fortunately most of my friends started using Discord and/or Signal with better features (and one less Meta app to have running).

      I think that the idea of having smaller and less demanding versions of lots of apps is a good idea. As so many apps are just not optimized and bloated. Just being coded to rely on higher specs to make up for said lack of effort in cleaning up stuff. The ads on ads on ads being part of the issue as well. Which is only getting worse with the close buttons not loading unless shit has been however many seconds. Seems that the “hit box” for the close buttons is getting smaller and smaller to guaranty the ads are clicked on and then open another app or a browser. Though optimizations and better coding won’t fix dirty underhanded grifts.

      •  LiveLM   ( @LiveLM@lemmy.zip ) 
        link
        fedilink
        English
        46 months ago

        I think that the idea of having smaller and less demanding versions of lots of apps is a good idea.

        I think that too!
        I’m just not sure Webapps are the way to go about this over native, smaller, leaner apps.

  • I ended up using a static site generator for my personal site because I fucking hate JS and frameworks and WebComponents. The front page is 646 KB and it loads in 4 seconds. I’d love for it to be 1 second or less, but the fonts are a factor.

    And I shrunk the shit out of that background too with pngcrush so miss me with that.

    • Haven’t done this type of optimizing in a long time, I had a quick look at the network graph for your front page (F12 dev tools in desktop browser), my understanding is it looks like you are getting blocked from loading additional resources (fonts + background) until your style sheets are fully read --pink line is document loaded i believe.

      It may be worthwhile to experiment with adding some preload links to the html template? or output? like below and assessing if it makes things faster for you.

      ``

      ``

      ``

      ___

    • Honestly, 4 seconds is really slow, especially with static HTML. I built my first companies’ site myself, it includes a video on the front page and jquery, is built by PHP, and on descent Internet connections the front page will load in slightly over a second, other pages dip under that.

      There are loads of tweaks you can make to -any- site, and total amount of bytes really isn’t the only speed factor here.

    •  JasonDJ   ( @JasonDJ@lemmy.zip ) 
      link
      fedilink
      7
      edit-2
      6 months ago

      I love all your replies.

      You wouldn’t get these responses from stackoverflow.

      This isn’t even a programming or development community…it’s a general interest one.

      You didn’t even ask for help.

      • I gotta say I came in here to flex and I learned so much. I am going to roll some of these changes really soon once I find out where to best add them to my Hugo template. I’m going to reply to some of them below to clarify some things:

        It may be worthwhile to experiment with adding some preload links to the html template? or output? like below and assessing if it makes things faster for you.

        This is the most interesting because I didn’t even know this was possible with HTML5, so I want to add this right away.

        I have a pixel 6 and notice some lag in scrolling. Could it be that you don’t use srcsets but instead huge screenshots no matter the device screen?

        The background is a large image in the CSS via background-image, I don’t know how easy it would be to change it to a srcset but I will give it a shot

        The fonts can be loaded from another file that ends in the cache, lowering load time next time.

        At the very least they need to load last because they are the largest burden

    • , but the fonts are a factor.

      I’m not sure if the possibility is there depending on your use case (eg.: you are exporting the fonts) nor if the cost of doing it would be worth the shot, but you can send minified versions variants of fonts, too.

  • I always think it’s unfair to compare things to video games. Video games are so inefficient they had to invent a separate processor with hundreds of cores just to run them. Of course they end up running well.

    If cheap phones had a 128-core JavaScript Processing Unit, websites would probably run fast too.

  •  Zikeji   ( @Zikeji@programming.dev ) 
    link
    fedilink
    English
    176 months ago

    My old project I got to architect the frontend ran lean at around 300KB - part of our target audience had older phones so it was designed with that in mind.

    At my new job 22MB is child’s play. To be fair they might do it better with the next version.

    • Similar to me. Previous job we tried our best to squeeze any ounce of optimisation out of it. Mainly because I was on the SEO team and we had to focus on the core web vitals. Everything was deferred and every image was optimised.

      New job, we don’t even have any metrics.

  • I’d hazard a guess and say it all stems from advancements in tech. There was a need to get the most out of something because of limited resources. Now that everyone’s got some fairly serious hardware (yes, even the cheap shit), there’s rarely that urge to optimize.

    Rather than optimize each new technology as it comes along and gets adopted, it seems as though the mantra is “fuck it, add it to the pile”. And it snowballs. As developers feel the need to optimize less, the lessons get passed down to the next generation, and so on.

    So we’re left with apps/end-user stuff that appear to have been on the opposite of a diet.