Change Details

Google is actively focusing on performance penalties on "slow events" for search results. We have a slow event every time a section is expanded and lazy loaded images loaded. It's not exactly clear when this will become enforced but the penalties are already present in Google betas. Best guess - April. The performance team and reading web met to discuss solutions. My preferred solution unfortunately requires the most effort on our part - solution 1. We should discuss as a team about the trade offs and make a decision. ## Solutions We have several options to solve this. #### 1) We reimplement lazy loading images using a MutationObserver or tap to show image pattern This is the arguably the best and most complete solution. In an ideal solution we would use the MutationObserver and use a "click to tap" pattern on browsers which do not support MutationObserver (e.g. KaiOS). It however would likely be the most complex solution in terms of effort on our part. Winners: smart phone users, feature phone users, designers Losers: product, devs More info: T225946#5916039 #### 2) Use native image loading on Chrome only Since Chrome is likely the browser SEO penalties will apply in we could use this fact to our advantage. This would lead to a loss of control in the experience on Chrome and would hopefully be the lowest cost solution. On the short term this would break images displaying in printed PDFs (to be confirmed) and it's possible that we may lose some control over when lazy images are loaded and the transitions for when they display. If we take this option we'd need to weigh up the trade offs here. Winners: Product (done quicker!), Chrome users Losers: product (breaks print!), devs, designers #### 3) Use native lazy loading everywhere This is the most simple solution. It should be simple to implement and it would remove code maintenance. However browser support for native lazy loading is low so browsers other than Chrome and Firefox would now load bandwidth - most notably iOS would no longer load images lazily meaning additional data usage for many of our users. Winners: Product, Chrome+Firefox users Losers: devs, designers, iOS users ## Developer notes Meeting notes can be found here: https://etherpad.wikimedia.org/p/Desktop_Refresh_Performance

Google is actively focusing on performance penalties on "slow events" for search results. We have a slow event every time a section is expanded and lazy loaded images loaded. It's not exactly clear when this will become enforced but the penalties are already present in Google betas. Best guess - April. The performance team and reading web met to discuss solutions. My preferred solution unfortunately requires the most effort on our part - solution 1. We should discuss as a team about the trade offs and make a decision. ## Solutions We have several options to solve this. #### 1) We reimplement lazy loading images using a MutationObserver or tap to show image pattern This is the arguably the best and most complete solution. In an ideal solution we would use the MutationObserver and use a "tap to show" pattern on browsers which do not support MutationObserver (e.g. KaiOS). It however would likely be the most complex solution in terms of effort on our part. Winners: smart phone users, feature phone users, designers Losers: product, devs More info: T225946#5916039 #### 2) Use native image loading on Chrome only Since Chrome is likely the browser SEO penalties will apply in we could use this fact to our advantage. This would lead to a loss of control in the experience on Chrome and would hopefully be the lowest cost solution. On the short term this would break images displaying in printed PDFs (to be confirmed) and it's possible that we may lose some control over when lazy images are loaded and the transitions for when they display. If we take this option we'd need to weigh up the trade offs here. Winners: Product (done quicker!), Chrome users Losers: product (breaks print!), devs, designers #### 3) Use native lazy loading everywhere This is the most simple solution. It should be simple to implement and it would remove code maintenance. However browser support for native lazy loading is low so browsers other than Chrome and Firefox would now load bandwidth - most notably iOS would no longer load images lazily meaning additional data usage for many of our users. Winners: Product, Chrome+Firefox users Losers: devs, designers, iOS users ## Developer notes Meeting notes can be found here: https://etherpad.wikimedia.org/p/Desktop_Refresh_Performance

Google is actively focusing on performance penalties on "slow events" for search results. We have a slow event every time a section is expanded and lazy loaded images loaded. It's not exactly clear when this will become enforced but the penalties are already present in Google betas. Best guess - April. The performance team and reading web met to discuss solutions. My preferred solution unfortunately requires the most effort on our part - solution 1. We should discuss as a team about the trade offs and make a decision. ## Solutions We have several options to solve this. #### 1) We reimplement lazy loading images using a MutationObserver or tap to show image pattern This is the arguably the best and most complete solution. In an ideal solution we would use the MutationObserver and use a "click"tap to tap"show" pattern on browsers which do not support MutationObserver (e.g. KaiOS). It however would likely be the most complex solution in terms of effort on our part. Winners: smart phone users, feature phone users, designers Losers: product, devs More info: T225946#5916039 #### 2) Use native image loading on Chrome only Since Chrome is likely the browser SEO penalties will apply in we could use this fact to our advantage. This would lead to a loss of control in the experience on Chrome and would hopefully be the lowest cost solution. On the short term this would break images displaying in printed PDFs (to be confirmed) and it's possible that we may lose some control over when lazy images are loaded and the transitions for when they display. If we take this option we'd need to weigh up the trade offs here. Winners: Product (done quicker!), Chrome users Losers: product (breaks print!), devs, designers #### 3) Use native lazy loading everywhere This is the most simple solution. It should be simple to implement and it would remove code maintenance. However browser support for native lazy loading is low so browsers other than Chrome and Firefox would now load bandwidth - most notably iOS would no longer load images lazily meaning additional data usage for many of our users. Winners: Product, Chrome+Firefox users Losers: devs, designers, iOS users ## Developer notes Meeting notes can be found here: https://etherpad.wikimedia.org/p/Desktop_Refresh_Performance