-
Notifications
You must be signed in to change notification settings - Fork 17
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use GitHub Actions to build jlreq? #272
Comments
rather than building (processing respec and placing processed file) in this repository, I suppose we are encouraged to update as WD on /TR/ more frequently... (also I'm not sure whether these processing eats large volume within full load time.) |
How the page load time is optimized by using the GitHub actions? (a novice question) |
This is fine, but ED is still slow (unless we synchronize the two commit by commit). |
I just tried it, and the speed of the two seemed very different. I opened these two pages on the same computer and network (I cleared the HTTP cache before each run): The first one took ~9 seconds and the second one took ~3 seconds. I tried running it many times, and the results were about the same. I haven't investigated what caused such a big gap, though. |
Thank you Fuqiao! It seems the difference is significant. |
(note, one issue which blocks this, spec generator has shorter limit than takes to process current JLreq - which is also a reason why pr-preview is not working.) |
Fwiw, for me the downloads took ~4 and ~3 seconds, respectively. So not a lot of difference. |
This is tracked in w3c/spec-generator#396 We can also try to run ReSpec locally (in the GitHub action environment) instead of relying on spec-generator. |
haven't checked internal processing of w3c/spec-prod, but is this relies on external or local processing?? (yeah, I should secure time for check,,, I know..) |
It seems that spec-prod does local processing, and ARIA depends on spec-generator. See: |
jlreq is a very long document, so it takes a long time to open it. In #218 we optimized the images, and the performance has improved. I think the load time can be further optimized by building the document using GitHub actions, like the ARIA folks did here:
https://github.com/w3c/aria-practices/blob/0e7accec081f995fc969f570ec048094791b0bc0/.github/workflows/deploy.yml
The text was updated successfully, but these errors were encountered: