5 ms·

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant w

Speaking as the TL of Lighthouse and PageSpeed, I can comfortably say that adding complexity is antithetical to our goal. Quality UX and a reliably performant web is what we want for all users. Ideally, folks would use a thinner stack with _less_ JS, as that's rewarded across all the metrics. But in recent years, many teams build a "site" by building a SPA. As they're entrenched in that dubious decision, the only path to making it performant is adding SSR complexity. ¯\_(ツ)_/¯ Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? And to nitpick: Core Web Vitals debuted with 3 metrics, one of them being FID. The focus on runtime/JS performance has been there from the start. Regardless, I hard agree on your last paragraph.

solardev 4y ago
The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS. How are you supposed to "less JS" your way out of that?
- wpietri 4y ago
  If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?
  - deleted 4y ago
    [deleted]
  - sroussey 4y ago
    Agreed. If you must login, for example, then that part of the site is not indexed, so googles metrics are not relevant. Indeed, I’ve seen higher NPS scores when it’s slower… the user feels like they are paying for more.
- OJFord 4y ago
  The vast majority of SPAs are not 'Maps, Earth, etc.'. I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS. (Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)
  - solardev 4y ago
    Yeah, you're totally right in that complex web "apps" are different to a simple informational page. But do the metrics take that into account? It's just a raw performance score, no, not performance-per-complexity or performance-per-feature etc.? How do you compare "fast" between "my journal entry today" and "Photoshop on the web" using one set of metrics...?
    - sarchertech 4y ago
      You probably don’t care about the SEO ranking of the app just the landing/marketing pages.
- mch82 4y ago
  Applications like you’re describing should consider less DOM and more Canvas API. The apps aren’t documents. They’re more like video games. DOM manipulation and rendering usually degrades performance more than the JavaScript. One essay on this topic… https://medium.com/young-coder/the-future-web-will-canvas-rendering-replace-the-dom-847be872884c https://medium.com/young-coder/the-future-web-will-canvas-re...
  - solardev 4y ago
    They can and should work side by side, along with SVG, WebGL, maybe WASM and workers and such. They are all web technologies. But Javascript is still the thing that controls all of them, their state, URL routing, interaction events, etc. I spent much of the last few years working on such hybrid apps (DOM mixed with graphics techs, with clientside UI and state combined with server-side with and persistence, etc.). The DOM has never meaningfully slowed down for me, even with CPU throttling or testing on old laptops. Canvas has, especially in some builds of Firefox. Certainly for rendering graphics canvas or WebGL are better choices, but it's not a performance magic bullet for all apps. More often than not, the performance bottlenecks are just some bug of ours (a poorly implemented search algorithm) or an unoptimized query somewhere. No modern web app needs to be just one thing or another. Even if you're operating almost entirely in canvas (like a map) there's still a ton of Javascript (open layers, leaflet, mapbox-gl-js, etc.) that you need, along with being able to use the DOM where it makes sense (reusing buttons, alerts, etc.) Canvas is also really hard to make responsive. CSS evolved alongside the devices and has first class units for all that. Canvas doesn't have those easy abstractions and having to virtualize your UI without CSS-like helpers (much less things like flexbox or Bootstrap) makes it hard to make standard UIs too. HTML still has its uses for now, though arguably React and other abstractions make it much less important.
  - solardev 4y ago
    And sorry, one more thought: Canvas work can itself be abstracted with frameworks like OpenLayers or PixiJs or Unity. It's a testament to how powerful browsers have become that you can run full MMORPGs or other games in the browser. But that all depends on being able to download a huge Javascript bundle at load time, but then the rest of the experience is usually pretty smooth. Games and maps are just an extreme version of that, but other examples where clientside DOM apps with heavy JS can still be faster (compared to old school server-side HTML) and easier to work with (compared to canvas) are email, e-commerce, ebooks, dashboards, chat, forums, video tubes, search and filtering, galleries, documentation, project management, etc.
FalconSensei 4y ago
> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? + PMs wanting to run dozens of AB tests at once in every single page
yawaramin 4y ago
It's ironic of Google to try to drive web performance when websites are full of Google Analytics scripts. Like the fox guarding the henhouse ;-)
yazaddaruvala 4y ago
> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? In theory improved DX leads to improved UX. In practice, subpar/lazy tooling needs to be worked around to get better DX. I’ve added a lot of JS weight to migrate legacy apps to React always improving time to interactive and responsive error handling/messaging. Vanilla JS and even Jquery just don’t have the DX that allows them to scale in a corporate context (specifically because of under experienced engineers and poor “due dates”). IMO it’s a lack of initiative from browser developers to move the web forward faster (obvious given the funding comes roughly exclusively from the developers of iOS and Android). I understand the inertia of legacy browsers, but it should not take decades to eliminate the need for these DX polyfills (eg like Jquery took to become redundant, and how long it’s taking React/Vue/Svelte style components).

solardev 4y ago

The whole idea of a "site" full of "pages" doesn't really suit a lot of modern use cases. What do you do when your "app" isn't really a "site" to begin with? Like most of the apps in Google Workspace, or Maps, Earth, etc. It's not their URL structure that gives them value, but the buttload of realtime clientside interactivity enabled by JS. How are you supposed to "less JS" your way out of that?

wpietri 4y ago
If something isn't expressible as a site full of pages, why are you worrying about Google's metrics for sites and pages?
- deleted 4y ago
  [deleted]
- sroussey 4y ago
  Agreed. If you must login, for example, then that part of the site is not indexed, so googles metrics are not relevant. Indeed, I’ve seen higher NPS scores when it’s slower… the user feels like they are paying for more.
OJFord 4y ago
The vast majority of SPAs are not 'Maps, Earth, etc.'. I thought the 'if the level of interactivity basically amounts to a form' of top-level comment sums it up nicely. Many are SPAs for the sake of it, similarly to packaging a website as an 'app' but not doing anything native, offline, or that really warrants it being its own app at all other than getting homescreen space on iOS. (Totally off-topic: I can't believe Apple still doesn't let you organise that however you want. It's sort of a small thing, but also so in your face, by far the most immediate turn-off to me of iOS.)
- solardev 4y ago
  Yeah, you're totally right in that complex web "apps" are different to a simple informational page. But do the metrics take that into account? It's just a raw performance score, no, not performance-per-complexity or performance-per-feature etc.? How do you compare "fast" between "my journal entry today" and "Photoshop on the web" using one set of metrics...?
  - sarchertech 4y ago
    You probably don’t care about the SEO ranking of the app just the landing/marketing pages.
mch82 4y ago
Applications like you’re describing should consider less DOM and more Canvas API. The apps aren’t documents. They’re more like video games. DOM manipulation and rendering usually degrades performance more than the JavaScript. One essay on this topic… https://medium.com/young-coder/the-future-web-will-canvas-rendering-replace-the-dom-847be872884c https://medium.com/young-coder/the-future-web-will-canvas-re...
- solardev 4y ago
  They can and should work side by side, along with SVG, WebGL, maybe WASM and workers and such. They are all web technologies. But Javascript is still the thing that controls all of them, their state, URL routing, interaction events, etc. I spent much of the last few years working on such hybrid apps (DOM mixed with graphics techs, with clientside UI and state combined with server-side with and persistence, etc.). The DOM has never meaningfully slowed down for me, even with CPU throttling or testing on old laptops. Canvas has, especially in some builds of Firefox. Certainly for rendering graphics canvas or WebGL are better choices, but it's not a performance magic bullet for all apps. More often than not, the performance bottlenecks are just some bug of ours (a poorly implemented search algorithm) or an unoptimized query somewhere. No modern web app needs to be just one thing or another. Even if you're operating almost entirely in canvas (like a map) there's still a ton of Javascript (open layers, leaflet, mapbox-gl-js, etc.) that you need, along with being able to use the DOM where it makes sense (reusing buttons, alerts, etc.) Canvas is also really hard to make responsive. CSS evolved alongside the devices and has first class units for all that. Canvas doesn't have those easy abstractions and having to virtualize your UI without CSS-like helpers (much less things like flexbox or Bootstrap) makes it hard to make standard UIs too. HTML still has its uses for now, though arguably React and other abstractions make it much less important.
- solardev 4y ago
  And sorry, one more thought: Canvas work can itself be abstracted with frameworks like OpenLayers or PixiJs or Unity. It's a testament to how powerful browsers have become that you can run full MMORPGs or other games in the browser. But that all depends on being able to download a huge Javascript bundle at load time, but then the rest of the experience is usually pretty smooth. Games and maps are just an extreme version of that, but other examples where clientside DOM apps with heavy JS can still be faster (compared to old school server-side HTML) and easier to work with (compared to canvas) are email, e-commerce, ebooks, dashboards, chat, forums, video tubes, search and filtering, galleries, documentation, project management, etc.

FalconSensei 4y ago

> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? + PMs wanting to run dozens of AB tests at once in every single page

yawaramin 4y ago

It's ironic of Google to try to drive web performance when websites are full of Google Analytics scripts. Like the fox guarding the henhouse ;-)

yazaddaruvala 4y ago

> Perhaps its the apparent conflict between UX and DX that leads to tooling complexity? In theory improved DX leads to improved UX. In practice, subpar/lazy tooling needs to be worked around to get better DX. I’ve added a lot of JS weight to migrate legacy apps to React always improving time to interactive and responsive error handling/messaging. Vanilla JS and even Jquery just don’t have the DX that allows them to scale in a corporate context (specifically because of under experienced engineers and poor “due dates”). IMO it’s a lack of initiative from browser developers to move the web forward faster (obvious given the funding comes roughly exclusively from the developers of iOS and Android). I understand the inertia of legacy browsers, but it should not take decades to eliminate the need for these DX polyfills (eg like Jquery took to become redundant, and how long it’s taking React/Vue/Svelte style components).