4 ms·

The answer is Core Web Vitals. I have spent countless hours doing real optimizations on a website with real traffic, without submitting to AMP (which I view as

The answer is Core Web Vitals. I have spent countless hours doing real optimizations on a website with real traffic, without submitting to AMP (which I view as a disgusting move by Google and everyone involved with it.) (Traffic which, by the way, does not reflect the device profiles of what Google considers the "average" user, based on real vs. lab results in Lighthouse -- which is forcing us to work on issues that are not proportionally relevant to our business, though I will concede it's a positive improvement for us overall. But still an unwanted Google influence, like most SEO.. but moreso.) Core Web Vitals should render AMP irrelevant, and thus seeing as both projects are being pushed by Google, it's time Google takes AMP behind the barn. Unfortunately Core Web Vitals takes a pretty hard stance against bleeding edge technology like (Vue/React) server side rendering with client hydration. Anything beyond a todo app starts to see considerable main thread time during hydration which obliterates the Core Web Vitals scores. I predict with continued focus on CWV we will see: much greater focus on startup times for client side apps (including better hydration strategies), and maybe even some server-side only JS front end frameworks -- more aligned with the JAMstack idea (everything old is new again, yay.) As much grief as CWV has caused me, it is the correct solution to the problem of slow websites and its impending inclusion in Google's page rankings should have a positive impact on the overall health of the web. Why people who aren't being paid by Google continue to defend AMP absolutely baffles me.

s17n 6y ago
> I have spent countless hours doing real optimizations > As much grief as CWV has caused me, it is the correct solution to the problem of slow websites Maybe core web vitals will succeed but I'm skeptical. A big part of AMP's success was ease of implementation. Sites with skilled, motivated, and empowered developers are going to be fine regardless of what technology Google tries to push. It's the other sites (ie, most sites) that I worry about.
- detaro 6y ago
  AMP with a few tweaks as "here's a Google recommended ready-to-roll framework for doing fast mobile sites" is mostly fine, and as easy to implement technically. But probably hard to get companies to use if not "strongly motivated".
  - s17n 6y ago
    It's pretty easy to get companies to use if you make a special carousel at the top of the search results page which is reserved for it.
    - detaro 6y ago
      Which exactly is where it stops being "just a web framework", which was the point.
epistasis 6y ago
> Unfortunately Core Web Vitals takes a pretty hard stance against bleeding edge technology like (Vue/React) server side rendering with client hydration. Anything beyond a todo app starts to see considerable main thread time during hydration which obliterates the Core Web Vitals scores. I predict with continued focus on CWV we will see: much greater focus on startup times for client side apps (including better hydration strategies)... To me, this doesn't sound unfortunate, it sounds great! I'm so tired of the drag that these frameworks cause when they are applied in situations which don't help. There are definitely use cases for such heavy and slow frameworks, but they should not be used for standard web pages, and should pay the penalty in search results when a web page with similar information is more responsive.
- lwansbrough 6y ago
  I say unfortunately because in our case the use is legitimate and we're working hard to get everything optimized outside of the main thread time (we've even built our own image service that we can use to dynamically change image resolution and quality based on the device form factor.) But I agree they are overused in general.

s17n 6y ago

> I have spent countless hours doing real optimizations > As much grief as CWV has caused me, it is the correct solution to the problem of slow websites Maybe core web vitals will succeed but I'm skeptical. A big part of AMP's success was ease of implementation. Sites with skilled, motivated, and empowered developers are going to be fine regardless of what technology Google tries to push. It's the other sites (ie, most sites) that I worry about.

detaro 6y ago
AMP with a few tweaks as "here's a Google recommended ready-to-roll framework for doing fast mobile sites" is mostly fine, and as easy to implement technically. But probably hard to get companies to use if not "strongly motivated".
- s17n 6y ago
  It's pretty easy to get companies to use if you make a special carousel at the top of the search results page which is reserved for it.
  - detaro 6y ago
    Which exactly is where it stops being "just a web framework", which was the point.

epistasis 6y ago

> Unfortunately Core Web Vitals takes a pretty hard stance against bleeding edge technology like (Vue/React) server side rendering with client hydration. Anything beyond a todo app starts to see considerable main thread time during hydration which obliterates the Core Web Vitals scores. I predict with continued focus on CWV we will see: much greater focus on startup times for client side apps (including better hydration strategies)... To me, this doesn't sound unfortunate, it sounds great! I'm so tired of the drag that these frameworks cause when they are applied in situations which don't help. There are definitely use cases for such heavy and slow frameworks, but they should not be used for standard web pages, and should pay the penalty in search results when a web page with similar information is more responsive.

lwansbrough 6y ago
I say unfortunately because in our case the use is legitimate and we're working hard to get everything optimized outside of the main thread time (we've even built our own image service that we can use to dynamically change image resolution and quality based on the device form factor.) But I agree they are overused in general.