Here is my server side rendering strategy: I divide the users into two groups, based on whether their browsers support the APIs natively which my app is using, or not. The former group will get server rendered pages with JS, which progressively enhance the UX. The latter will get server rendered pages only. No polyfills required. Everything which can render HTML is supported no matter what. Eventually those browsers which not implemented the newest APIs yet, will catch up, and then its users will get the JS enhanced version automatically.
Wait… are you recommending that we user agent sniff and then cloak? I’m so confused… you work for Google and you’re recommending that we violate Google’s own guidelines?
Ryan Ricketts I'm not an SEO expert nor do I work on search so my take on this should not be considered authoratative. My personal recommendation is to focus on tools not rules - I always attempt to fetch as Google to evaluate if my pages can be sufficiently interpreted before considering any other options. Ideally no one should be cloaking. It's going to be far cleaner to not to. If for any reason you find fetch as Google unable to render sufficiently, options like looking at missing polyfills, Rendertron or whether SSR makes any sense here are options already documented elsewhere that non-Google folks have been considering.
Why not using server-side rendering under a Progressive Enhancement approach? I mean, if the point of using that is to display content before the agent is available to use JavaScript, it makes sense to me that content should be also interactable at that point. The user should be able to use the site the old way until JavaScript is ready to take control. And no UA-sniffing! :)
Andrew Willard Silva Rendertron isn't a silver bullet but for certain types of pages it can be worth evaluating. There have been some good talks about it over the last year you can find on the channel.
just look politically, Google itself on the other side, is drawing the picture of how people look at developers tool, by making such a fantastic videos. agreed?
Biztos jó lehet,de van egy nagy baj.Csak olyan szinten beszélem inkább értem a Angolt. Hogy ez nekem magas.Meg lehet hogy kiszállok ebből az internet dologból.Annyira rám szálltak Ezt tiltanak le másnap mást tiltanak le.A mobil telefonomon kutakodnak A tábla gépen nem tudok csinálni semmit.Szóval le lépek az internetről.Ezért nem érdemes nekem fejlesztésekbe gondolkodnom Mert én nem szeretem az ilyet hogy állandóan velem és a eszközeimmel foglalkoznak.Nem tudom hogy mikor de hamarosan lelépek.
Super chill video
Here is my server side rendering strategy: I divide the users into two groups, based on whether their browsers support the APIs natively which my app is using, or not. The former group will get server rendered pages with JS, which progressively enhance the UX. The latter will get server rendered pages only. No polyfills required. Everything which can render HTML is supported no matter what. Eventually those browsers which not implemented the newest APIs yet, will catch up, and then its users will get the JS enhanced version automatically.
great talk(and great t-shirt)!
陳明進 quite a dry remark...
Wait… are you recommending that we user agent sniff and then cloak? I’m so confused… you work for Google and you’re recommending that we violate Google’s own guidelines?
Ryan Ricketts I'm not an SEO expert nor do I work on search so my take on this should not be considered authoratative. My personal recommendation is to focus on tools not rules - I always attempt to fetch as Google to evaluate if my pages can be sufficiently interpreted before considering any other options. Ideally no one should be cloaking. It's going to be far cleaner to not to. If for any reason you find fetch as Google unable to render sufficiently, options like looking at missing polyfills, Rendertron or whether SSR makes any sense here are options already documented elsewhere that non-Google folks have been considering.
Outro was lit
Why not using server-side rendering under a Progressive Enhancement approach? I mean, if the point of using that is to display content before the agent is available to use JavaScript, it makes sense to me that content should be also interactable at that point. The user should be able to use the site the old way until JavaScript is ready to take control. And no UA-sniffing! :)
Hot 🥵 topic. And that was 2 years ago
Is rendertron a good solution?
Andrew Willard Silva Rendertron isn't a silver bullet but for certain types of pages it can be worth evaluating. There have been some good talks about it over the last year you can find on the channel.
just look politically, Google itself on the other side, is drawing the picture of how people look at developers tool, by making such a fantastic videos. agreed?
Sweet Corgi mug. And narwhals rule!!! 😆😎🤗👍
Biztos jó lehet,de van egy nagy baj.Csak olyan szinten beszélem inkább értem a Angolt. Hogy ez nekem magas.Meg lehet hogy kiszállok ebből az internet dologból.Annyira rám szálltak Ezt tiltanak le másnap mást tiltanak le.A mobil telefonomon kutakodnak A tábla gépen nem tudok csinálni semmit.Szóval le lépek az internetről.Ezért nem érdemes nekem fejlesztésekbe gondolkodnom Mert én nem szeretem az ilyet hogy állandóan velem és a eszközeimmel foglalkoznak.Nem tudom hogy mikor de hamarosan lelépek.