See the entire conversation

I see some great fast PWAs launching, but it's difficult to know what to do with the other sites that launch with 10s+ of CPU before render…
105 replies and sub-replies as of Apr 02 2017

…demos of slowness are easy to dismiss as "not real", shaming is hard on individuals, quietly fixing each site doesn't scale…
Well, Google already scaled something like that quietly with Operation Rosehub. Could do one for PWAs but rather than github, crawl sites ;)
…but our industry is on the line here. A web of slow unusable apps suggests the web is incapable of being an app platform…
Isn't the problem primarily non-technical? Organizations that need plain hypertext sites but try to have "apps" to be cool?
The solution to the 90's "my nephew built it" crap sites was to professionalize the industry and say no to stakeholders.
not shaming, but being open about the problems of these sites and pointing at fixes that might help all devs is a good option
when we point to a slow site it's seen as shaming by some
if it's just the one site, may be. but if it's terribly slow it might be a sign that they need help. depends on the attitude?
right, but fixing the web site by site doesn't scale
it doesn't. but the more egregious cases? if there's a lot of issues with framework n or bundler m, everyone can learn from it
i'm thinking how game development and graohics have evolved, for instance, and there's no "how's it made" readily available
…the "money people" need to see fast sites and think "I need that", and see slow sites and think "that's a development failure".
Making a direct link between performance and revenue/business metrics helps here, a la engineroom.ft.com/2016/04/04/a-f…
In the case of one of my projects at work, it's a data-heavy app with frequently updated data that loads MBs of JSON on load..
... a huge part of our initial CPU run is serializing data + render, which is difficult to efficiently offload to server-side.
Agreed. The question is why is it so easy to make slow websites? I don't think it's an experience thing.
My theory is that the web has stopped trying to be a dev environment, so devs seek external tools.
This creates a disconnect between the thing they work with (their tools) and the thing the deploy.
some frameworks are slow by default, and the default gets shipped due to time. Sometimes this is as simple as a "dev mode"
The web is slow by default. Blocking scripts, blocking stylesheets. No streaming support in most server frameworks, etc.
I wish there were a fast mode meta tag that banned all slow practices. A "use strict" for HTML.
I guess this is AMP's aim
I answered w/out reading this ...doh
AMP actually is kinda like that. It forces you to into a 'strict' way of coding in xchangd for speed
Library bloat + no bundle splitting are major issues. Seen 60+ node mods on a big React app. We gotta change or the web loses
They should see slow sites/apps and think "that's what happens when money and product people don't value speed"
all these managers fancy themselves as the next Steve Jobs, but totally miss that the iphone lacked in features but won on quality
"but what if we could get companies to give us millions of dollars to automatically add custom emoji after hashtags"
Instead of trying to tell people "no", work to make what's popular faster. Have you looked at React Fiber?
your comment seems ignorant of the articles/talks/features/specs I work on
That came across as harsh, sorry. I do appreciate and admire your work, especially on Service Workers.
Can be strategic. Project with Google backing can influence ecosystem. See: create-react-app killing boilerplate projects.
Reprasing: IMO future of web perf is in embracing and improving abstractions in user space. PWA, SW, ignition all good steps.
I think the "tech people" need to see fast web apps. The "money people" tend to delegate decisions on tech to be used
often it's tech folks that think they need to go native.
most ppl start the biz with:where to acquire users,how many users through various funnels,what is the most effective funnels.
outside the small browser vendors/js community, very few think about web vs native or fast speed.
yeah, that's what I was thinking of when I posted
all these managers fancy themselves as the next Steve Jobs, but totally miss that the iphone lacked in features but won on quality
sure there are crazy ppl, but most founders I have met are very passionate, so genuine wanting to solve a problem.
I haven't met many that value quality over quantity (of features/users)
trying, building an 'app' based on web tech. from the start (wrapped in Electron) looking at all the 'best practices' rn
The performance problem is less to do with lack of tooling/tweaking and more to do with fundamental bad design process.
you saying if you designed for simplicity you wouldnt need heavy libraries etc in the first place?
Yes. Or leveraged browser/HTML behavior over redundant scripting. Lots of possibilities.
I imagine browser vendor task force teams, like Mozilla has the @webcompat team for compat, would help
we already have dev rel writing articles, speaking about good/bad examples and reasons, getting changes into tooling…
…changing/expanding the platform at a spec level… are we missing anything?
the rusty Web, aka that sites can age. Most of these sites are exactly like the Java/Flash app of the past @jennschiffer
yeahhhhh I knowwww I mean @webcompat contacts the teams of devs whose sites are broken
we do that too 😀. Difficult to scale though
add it to @____lighthouse - @patmeenan put that into WebPageTest today
Time to Interactive is the relevant metric and was added a few weeks ago
getting people to care or focus on it is the hard part
if you partner with a company and make a big deal their competitors may be like 👀👀👀
because the only way higher ups would care is if it involves 💸💵💴💶💷💰
the ranking boost sold my boss on HTTPS - advertise that first paint affects it
I'm pretty sure it has a small effect right now, so make a noise!
well, this is what made AMP a success, although I feel 😕 about it
yeah, this is the big problem 😞
We need non-techies to talk about their successes at non-techie conferences etc.
I'd love for it to be in a requestable API, preferably pagespeed or WPT
It's in WPT API as long as you use Chrome and enable timeline capture
Everything in the WPT UI is available in the API (UI uses it itself)
oh I was confused with lighthouse. Thanks
FWIW, lighthouse is also available through the API - lighthouse=1
What are PWAs? TIA!
Could you point to examples of each?
Much thanks. We'll look to positive benchmarks, not negative.
10s+ of *CPU* time? you're saying take out all the network and everything and you have 10s+?
disregard, I missed it. sorry.
help their competitors optimise their sites instead. Then the motivation can be to beat their rivals!
we still have yet to implement bundle splitting. We've a 700kb bundle.js 😭 it's in the backlog.
oof, can any of that be lazy-loaded?
yeah, right now hitting /signup will force a full download of the bundle. Can split that by routes so it'll be 150kb...
should result in the signup page going from 800kb to 200kb. Just need to find bandwidth.
it's been a challenge when everyone is like "loads fast for me" sitting on our 1gbps office internet connection.
yeah, we've even seen sites that were bigger than a screencast of the site. Glad you're fighting the good fight!
new marketing site going live soon. Same design but fixed performance 750ms render. App is a much bigger beast.
Them I'm on my 3G UK sim plan in NY capped at 125kbps like... Nope this is not ok.
and "everyone has 4G nowadays"
then lazy load the rest of the bundle for SPA.
currently focused on removing several large NPM librarys in favour of smaller more specific code to reduce bloat overall.
yeah, I had problems with stuff tree-shaking badly because it was written using module.exports
200k sounds pretty healthy though. Throw in some server rendering and it'll be 👌
SSR is a much harder buy in due to how we wrote the app. Hopefully before the years out though.
in theory, market forces would make the faster sites more successful and the slower ones be forced to change to compete.
unless everyone puts minimal effort into the site and builds an app instead
stats for native app engagement and drop-off are pretty appalling but I see what you mean, we need to compete better with it
more at a higher decision-making level than at the individual site implementation level
ironic observation: sites almost guaranteed to be bloated and slow on mobile - mobile phone company web-sites.
worst offenders I see regularly are ads and CMS backed sites. Not sure how to address that as a frontend dev.
Their users would respond to them with not using it, I think it will change sooner or later. :)
That sounds like a dichotomy, but there also can be non-PWA web-apps that are fast.