Reading/Web/Notes/2016-Q3 Performance Planning

From mediawiki.org
< Reading‎ | Web

Here lie the notes for the reading web performance meeting from the 25th of January, 2016.

Intro[edit]

Jon: Start doing something with lazy loading images already. Long-term goal to enable this across the whole mobile +desktop projects (starting with mobile).

Jon: we had brainstorm, lazyloading seems easily achievable. various ideas, during this meeting lets flesh out the details.

Jon: questions about how we going to measure impact.

Joaquin: What does Peter think?

Peter: Timo should have been here to talk about measuring the impact. I'll setup some links later today to share the impact change? First render, speed index won't change. The resource download will change though.

Jon: I also noticed same things.

Peter: downgraded images didn't matter so much. dashboards and graphs being set up right now.Joaquin: I think not downloading images will make some difference, but maybe not that big of a difference. 

Jon: Are we talking about controlled tests, right? Let's keep that in mind.

Sam: Not downloading images may have a better impact regarding the amount of work the device has to do while streaming data from the socket, parsing, and rendering (for low-end devices)

Performance work related to images. Focus areas:

  •     Lazy loading images
  •     Varying image quality

    Based on previous notes in: https://etherpad.wikimedia.org/p/ReadingWebQ3PlanningClone

    And brainstorming https://i.imgur.com/m2tOz5d.jpg

Lazy loading images[edit]

Jon: We want to lazy load images in mobile beta. Prove the benefit. Push to stable, then make a case for doing the same in desktop.

Related phab tasks:

Some chatter about the questions and what to focus on. Decided to start with the cookie and measuring questions to have Peter involved in the conversation because he has to leave early.

Questions[edit]

Do we want to use NetSpeed cookie?[edit]

Chatter about the feature that marks clients per connection with a connection speed cookie.

jon: concerns about differentiating metrics. can be useful.

joa: can we measure with other cookies and see the data on grafana dashboards?

peter: it is doable

sam: rather not use the netspeed cookie for something that is not network related

peter: we have to measure them separately

Conclusion: not gonna use it for lazy images, will find another way of measuring correctly.

How to measure / show impact?[edit]

  1. From the browser perspective
    1. Are webpagetest and the dashboards enough?
    2. Can we see there bucketed mobile beta users w/ and w/o lazy loading for comparing impact?
  2. Server loading times (will be affected by transforming HTML)

jon: (regarding server loading times) how are we going to measure this, peter? is there a way or can we get one?

peter: we have some data from real users but today there is one big bucket, all pages and all clients. It is hard to see for specific pages, more useful metrics. We need to see better to measure what happens and know how good it is. There are some problems and some work to do to get the measuring in place.

joa: we should do this in controlled environments first, not beta production

jon: problems historically, skeptical about how analysis helps (content variations, difference of devices, ...)

baha: why don't we just make these changes now

sam: not our wiki. We need to test and show the value

peter: most important thing is when putting something into production we can see the changes

Conclusion: work in progress, keep perf team in mind for this. Define how we're going to measure together.

Peter leaves to other meetings at this point.

Implementation questions[edit]

Time is short, we decide to have a read on the options and vote what we think should happen. And then review the votes and explain/discuss.

What to do for HTML only clients?[edit]

  • a) Normal image tags inside <noscript> image markup (with RL support for unsupported browsers) 👾++
    •   Joa: Do not change behaviour from what they currently get.
  • b) Downsampled image quality tags +
    •   Jon: If you have html-only there are probably reasons to have smaller images served up.
    •   Jeff: in Zero there are browsers with low js support being treated as no-js (I think).
  • c) Replace images with links (with width/height dimensions to avoid reflows) +
    •   Baha: devices are probably not powerful for getting all images and may be useless to get degraded images.
    •   Jeff: I'd have split my vote between this one and A.
  • d) Replace images with inlined placeholder image (with width/height dimensions to avoid reflows)

joaquin: i think a) is the one that makes more sense, keep those clients working normally as they are now.

sam: make the smallest possible change that makes something useful.

Conclusion: there seems to be almost agreement on option a). At least initially not touching those clients leaves room for future changes when considering them specifically.

What to show for JS enabled clients with images not yet loaded?[edit]

  • 1. Show nothing
  • 2. Show img markup without src and with a title filled up ( https://i.imgur.com/8hLsSif.png )
    • 2.1. Style image to maintain layout and avoid jank when loading image
    • 2.2. What to fill the title with:
      • a. Fill title with alt text if available
      • b. Otherwise fill title with file name
  • 3. Show lower quality image markup +
  • 4. Show smaller image upscaled markup ++
  • 5. Show loading placeholder (may be done along with any of ^) +👾

Jon: May be dependent on other questions, design probably needed

joa: Number 5 would avoid a ton of requests for images initially (that would happen in 3 or 4). Suspicious that this could bring the best improvements.

jeff: (related 5 vs 3&4) users are used to loading steps but if they see blurry images they may think they are just that bad.

Conclusion: Seems to be between 4 & 5. To be discussed with engineers and design.

ACTION: Jon to talk to Nirzar about it [Jon]

ACTION: Sam to create a card as subtask of epic detailing proposal

ACTION: Joaquin to archive conversation

Which images should we lazy load?[edit]

  1. All +
    • Baha: let images not comete with the more important resources.
  2. Images after lead section 👾+++
  3. Images bigger than 50x50 (little icon images loaded by default, not thumbnails)
  4. Images smaller than 50x50 (little icon images not loaded by default) (Isn't this same as #1?)

Conclusion: There seems to be consensus that 2 would be the way to go.

When do we load images?[edit]

  1. On scroll, when image is in viewport or close (using a threshold) +👾++
  2. On tap/click +
    • Baha: As a user I probably will read the article slowly and load images if I'm interested.
    • Joa: could be a setting! i'd agree with having a setting that'd would toggle tap/scroll.
  3. Other?

Conclusion: On scroll is the most voted option, but 2 seems like a nice-to-have for a setting.

Any technical unknowns we should validate before hand?[edit]

NOT DISCUSSED

  1. Impact of image transformation on server response times
  2. Possible transformation caching on MobileFormatter
  3. Desktop upstreaming roadmap

Varying image quality[edit]

NOT DISCUSSED

Retrieved from "https://www.mediawiki.org/w/index.php?title=Reading/Web/Notes/2016-Q3_Performance_Planning&oldid=3045256"