Frontend Profiling CI

[dawoodkhan82]

Description

• when frontend changes are detected, this CI workflow runs the Playwright test on both the current PR and the latest gradio@* release tag branch.
• playwright test runs on tabs demo
• measures DOM Content Loaded, Page Load, LCP, tab navigation time, and JS/CSS transfer sizes
• Specifically measures DOM Content Loaded, Page Load, LCP, and tab navigation across 5 iterations and takes the median value to account for CI latency variation
• results are displayed as a markdown table in the action summary in the Compare Results step
• workflow fails if any timing metric regresses by more than 50% (with a 200ms minimum threshold) or any bundle size metric regresses by more than 25%. (We could adjust these thresholds)

The test will not leave a PR comment, I was testing that on this PR, but it would probably just clutter the PR. So opted to show the performance summary in the job itself.

Closes: #(issue)

AI Disclosure

We encourage the use of AI tooling in creating PRs, but the any non-trivial use of AI needs be disclosed. E.g. if you used Claude to write a first draft, you should mention that. Trivial tab-completion doesn't need to be disclosed. You should self-review all PRs, especially if they were generated with AI.

• I used AI to... [fill here]
• I did not use AI

🎯 PRs Should Target Issues

Before your create a PR, please check to see if there is an existing issue for this change. If not, please create an issue before you create this PR, unless the fix is very small.

Not adhering to this guideline will result in the PR being closed.

Testing and Formatting Your Code

1. PRs will only be merged if tests pass on CI. We recommend at least running the backend tests locally, please set up your Gradio environment locally and run the backed tests: bash scripts/run_backend_tests.sh

2. Please run these bash scripts to automatically format your code: bash scripts/format_backend.sh, and (if you made any changes to non-Python files) bash scripts/format_frontend.sh

[gradio-pr-bot]

🪼 branch checks and previews

•	Name	Status	URL
	Spaces	ready!	Spaces preview
	Website	ready!	Website preview
	Storybook	ready!	Storybook preview
🦄	Changes	detected!	Details

---

Install Gradio from this PR

pip install https://gradio-pypi-previews.s3.amazonaws.com/03a9aaf62c50c2b6185c89bfa97fedc7dcaac6f6/gradio-6.9.0-py3-none-any.whl

Install Gradio Python Client from this PR

pip install "gradio-client @ git+https://github.com/gradio-app/gradio@03a9aaf62c50c2b6185c89bfa97fedc7dcaac6f6#subdirectory=client/python"

Install Gradio JS Client from this PR

npm install https://gradio-npm-previews.s3.amazonaws.com/03a9aaf62c50c2b6185c89bfa97fedc7dcaac6f6/gradio-client-2.1.0.tgz

[gradio-pr-bot]

🦄 no changes detected

This Pull Request does not include changes to any packages.

__No changes detected. __

---

---

‼️ Changeset not approved. Ensure the version bump is appropriate for all packages before approving.

• Maintainers can approve the changeset by checking this checkbox.

Something isn't right?

• Maintainers can change the version label to modify the version bump.
• If the bot has failed to detect any changes, or if this pull request needs to update multiple packages to different versions or requires a more comprehensive changelog entry, maintainers can create the changelog file directly.

[aliabid94]

Overall looks good to me, two thoughts:

• Seems like main gets built every time along with the branch, seems like it would be much more efficient to just have one "established" benchmark that gets updated every time a PR merges into main. Then this action would just compare against the established benchmark.
• I would make this action leave a comment on the PR if the load times deteriorate beyond some threshold. Otherwise it will be easy to ignore

[freddyaboulton]

This is great @dawoodkhan82 ! Left some comments on the implementation. I think the tabs demo is too narrow and the benchmark demo should include:

• Accordions
• A broader set of components (Dropdown, Slider, Image,
  Chatbot, etc.)

This would make the bundle size and load time measurements
more representative of "large apps"