Experimental Workload: Responsive Design

[issackjohn]

This pull request introduces a new experimental responsive design workload, featuring a single-page cooking website built with Lit and Tailwind CSS.

The hosted version can be found here. Quick link to dev mode with workload selected. Please look at the README in experimental/responsive-design for more information about the code and how it is organized.

Not included in this PR:

• Support for different languages

[issackjohn]

Adding reviewers for visibility, feel free to take a look :)

[rniwa]

It seems to me that the test doesn't really take the advantage of responsive design since iframe's size is always same. Maybe we should add steps to resize iframe so that responsive design comes into play?

[issackjohn]

It seems to me that the test doesn't really take the advantage of responsive design since iframe's size is always same. Maybe we should add steps to resize iframe so that responsive design comes into play?

Currently, we are resizing the the iframe with id #content-iframe in the ReduceWidthIn5Steps & IncreaseWidthIn5Steps steps. Do you mean that we should be resizing a different iframe?

[rniwa]

It seems to me that the test doesn't really take the advantage of responsive design since iframe's size is always same. Maybe we should add steps to resize iframe so that responsive design comes into play?

Currently, we are resizing the the iframe with id #content-iframe in the ReduceWidthIn5Steps & IncreaseWidthIn5Steps steps. Do you mean that we should be resizing a different iframe

Oh, I see. We're resizing the inner iframe. I guess that works.

[issackjohn]

Gentle ping 😄

[camillobruni]

I still see rather short run times for individual steps (close to 1.6ms in chrome canary) which might introduce a bit too much noise in the long run.

Responsive-Design
Responsive-Design/LoadChatAndExpandRecipe	5.85	±	0.46 (7.9%)	ms
Responsive-Design/ReduceWidthIn5Steps  12.96	±	0.45 (3.5%)	ms
Responsive-Design/ScrollToChatAndSendMessage	1.68	±	0.07 (4.4%)	ms
Responsive-Design/IncreaseWidthIn5Steps	11.37	±	0.28 (2.5%)	

ScrollToChatAndSendMessage and (and especially it's sub-items) will show some aliasing from timer resolution which is ~ 0.1ms on chrome. In general, i'd bump the step durations by 1.5x or 2x even to be on par with other workloads.

[issackjohn]

I still see rather short run times for individual steps (close to 1.6ms in chrome canary) which might introduce a bit too much noise in the long run.

Responsive-Design
Responsive-Design/LoadChatAndExpandRecipe	5.85	±	0.46 (7.9%)	ms
Responsive-Design/ReduceWidthIn5Steps  12.96	±	0.45 (3.5%)	ms
Responsive-Design/ScrollToChatAndSendMessage	1.68	±	0.07 (4.4%)	ms
Responsive-Design/IncreaseWidthIn5Steps	11.37	±	0.28 (2.5%)	

ScrollToChatAndSendMessage and (and especially it's sub-items) will show some aliasing from timer resolution which is ~ 0.1ms on chrome. In general, i'd bump the step durations by 1.5x or 2x even to be on par with other workloads.

To bump up the step durations, I am thinking of

1. Expanding all the recipes as part of LoadChatAndExpandRecipe
2. Collapsing all the recipes as part of ScrollToChatAndSendMessage 2.1 Sending a few more messages in the chat instead of just one.

currently no proposed changes for ReduceWidthIn5Steps & IncreaseWidthIn5Steps

[flashdesignory]

Some visual questions - these might not be relevant to the tests:

Is this spacing as expected?

The collapsed grid looks fine, but once expanded, the item moves to the next row - is that expected? collapsed

expanded

The video tiles don't work - those are just placeholders?

[issackjohn]

Some visual questions - these might not be relevant to the tests:

Is this spacing as expected?

I'll add a fix for that. The webpage was designed to be viewed in 800x600, as that's how it will appear within the benchmark.

The collapsed grid looks fine, but once expanded, the item moves to the next row - is that expected? collapsed

Yes, that is expected. Do we prefer a different behavior?

The video tiles don't work - those are just placeholders?

Yes, they are just placeholders. We intended the video elements to be there but did not plan for them to play any actual videos.

[flashdesignory]

Some visual questions - these might not be relevant to the tests: Is this spacing as expected?

I'll add a fix for that. The webpage was designed to be viewed in 800x600, as that's how it will appear within the benchmark.

• Thanks - I'd vote for supporting larger viewport sizes. This will ensure that the workload looks usable at larger viewports, in case we want to change what's supported in Speedometer later on.

The collapsed grid looks fine, but once expanded, the item moves to the next row - is that expected? collapsed

Yes, that is expected. Do we prefer a different behavior?

I guess it makes sense for the tests, since it shifts elements on the page. That said, it's not something you'd see on the web (hopefully). I'd expected a modal or something like that instead.

The video tiles don't work - those are just placeholders?

Yes, they are just placeholders. We intended the video elements to be there but did not plan for them to play any actual videos.

Thanks for clarifying.

[flashdesignory]

@issackjohn - maybe rebase / merge main, to get the updated test runner in there. That should ensure the checks don't fail.

[camillobruni]

Let's aim for > 5ms for each measured subtest (I'd still aim for roughly 10ms if possible). Does this sound reasonable?

[issackjohn]

@issackjohn - maybe rebase / merge main, to get the updated test runner in there. That should ensure the checks don't fail.

Sounds good.

[issackjohn]

Let's aim for > 5ms for each measured subtest (I'd still aim for roughly 10ms if possible). Does this sound reasonable?

Sounds reasonable to me, I'll add some more actions.

[camillobruni]

Just double checked on Chrome, Firefox, Safari and the noise levels are in-sync with the rest of the workloads. The minimum step times look good now I would say.

[issackjohn]

Thanks! Looking forward to addressing anymore feedback from folks.

[netlify[bot]]

✅ Deploy Preview for webkit-speedometer-preview ready!

Name	Link
🔨 Latest commit	c7327fe1d2aa23545e8a55c9d64b6e45dab73f80
🔍 Latest deploy log	https://app.netlify.com/projects/webkit-speedometer-preview/deploys/68ace84dfddca10008f2de0d
😎 Deploy Preview	https://deploy-preview-453--webkit-speedometer-preview.netlify.app
📱 Preview on mobile	Toggle QR Code... Use your smartphone camera to open QR code link.

---

To edit notification comments on pull requests, go to your Netlify project configuration.

[issackjohn]

Then I have a few more minor comments here and there. I haven't looked very closely at the tailwind code because I'm not familiar with it. Also I wonder if we could include matchMedia somewhere.

Sounds good. I can look into incorporating matchMedia as a follow-up and see where it might make sense to add.

[camillobruni]

I see some lazy recalc-style happening outside the measured scope in chrome. (around 3ms) I'm not sure how we'd fully control this. From Devtools it clearly looks like work that was scheduled in the async phase. I've tried to see whether this happens in Firefox as well, but couldn't spot this immediately. Might be worthwhile checking on Safari as well.

[issackjohn]

I see some lazy recalc-style happening outside the measured scope in chrome. (around 3ms) I'm not sure how we'd fully control this. From Devtools it clearly looks like work that was scheduled in the async phase. I've tried to see whether this happens in Firefox as well, but couldn't spot this immediately. Might be worthwhile checking on Safari as well.

Now capturing in measured time on edge/chrome

• ReduceWidthIn5Steps and IncreaseWidthIn5Steps when using getBoundingRectAndElementFromPoint
• LoadChatAndExpandRecipes when using getBoundingClientRect.

Working on properly capturing the other steps when using getBoundingClientRect.

[issackjohn]

I see some lazy recalc-style happening outside the measured scope in chrome. (around 3ms) I'm not sure how we'd fully control this. From Devtools it clearly looks like work that was scheduled in the async phase. I've tried to see whether this happens in Firefox as well, but couldn't spot this immediately. Might be worthwhile checking on Safari as well.

Now capturing in measured time on edge/chrome

• ReduceWidthIn5Steps and IncreaseWidthIn5Steps when using getBoundingRectAndElementFromPoint
• LoadChatAndExpandRecipes when using getBoundingClientRect.

Working on properly capturing the other steps when using getBoundingClientRect.

All steps should now be properly captured.

I've observed that some work occasionally occurs outside the measured time following the ScrollToChatAndSendMessages step. From my understanding, this shouldn't be an issue. However, do we believe this activity should be included in the measured time? If we decide it's worth tracking, do you have any ideas of how we could capture that work?

[issackjohn]

@bgrins, @camillobruni, @rniwa, Could I get someone to take a look at the matchMedia implementation? Most of it is in experimental/responsive-design/src/lib/components/recipe-grid.js and used to switch the recipe cards to a compact version.

I'm still working on correctly capturing the other work caused by things like ResizeObserver within the measured time.

[issackjohn]

Gentle Ping. :)

[issackjohn]

Created https://github.com/WebKit/Speedometer/issues/525 for safari CI run end2end Test failure.

[issackjohn]

Gentle ping :)