-
Notifications
You must be signed in to change notification settings - Fork 40
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
[STALLED] Feature/4172 eliminate render blocking resources #4604
base: develop
Are you sure you want to change the base?
Conversation
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@rfultz Looks like lighthouse is still flagging the elections.css in the "Eliminate render blocking" report. Is there a way to defer that?
<link rel="stylesheet" type="text/css" href="{% asset_for_css 'elections.css' %}">
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks good!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cleanURI()
function that we use on the homepage to keep the querystring out of the URL does not seem to work if we defer election-lookup.js
It needs jQuery. Specifically, the .on
method. I tried to start writing a vanilla JS version, but it gets tricky trying to emulate $.on
. Should we replace it with vanilla JS or is there a better way around deferring the needed asset?
FYI- I had to open a new icognito window each time to definitively test removing/replacing defer on the script tag
Also weirdly, election-lookup js
was not flagged for Eliminate render-blocking resources
by lighthouse when removing defer (?)
<script src="{% asset_for_js 'election-lookup.js' %}"></script> | ||
<script defer src="{% asset_for_js 'home.js' %}"></script> | ||
<script defer src="{% asset_for_js 'bythenumbers.js' %}"></script> | ||
<!-- <script defer src="{% asset_for_js 'dataviz-common.js' %}"></script> --> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you want to leave this commented tag in here?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oof. Nope! Good catch!
<script defer src="{% asset_for_js 'home.js' %}"></script> | ||
<script defer src="{% asset_for_js 'bythenumbers.js' %}"></script> | ||
<!-- <script defer src="{% asset_for_js 'dataviz-common.js' %}"></script> --> | ||
<script defer src="{% asset_for_js 'election-lookup.js' %}"></script> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The cleanURI()
function that we use on the homepage to keep the querystring out of the URL does not work if we defer election-lookup.js
It needs jQuery. Specifically, the .on
method. I tried to start writing a vanilla JS version, but it gets tricky trying to emulate $.on
. Should we replace it with vanilla JS or is there a better way around this?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What if we change election-lookup to async?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this to native on another ticket. Should I merge that one into this one?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I did try async and got same problem
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I changed this to native on another ticket. Should I merge that one into this one?
Whatever fixes it is fine with me
Thanks @rfultz . If we ended up deciding that its OK to have querystrings once someone interacts with the map, we would probably want to have it register every parameter they choose Update: I just realized that this ^^^ might still be a problem because the bar charts below the map also add querystrings to the URL which is confusing--part of the reason we scrub the URL in the first place. |
@rfultz this works if we put it back on
Let me know what you think |
Codecov Report
@@ Coverage Diff @@
## develop #4604 +/- ##
===========================================
- Coverage 75.84% 75.83% -0.02%
===========================================
Files 125 125
Lines 7660 7660
Branches 618 618
===========================================
- Hits 5810 5809 -1
- Misses 1850 1851 +1
Continue to review full report at Codecov.
|
); | ||
} | ||
window.onload = function () { | ||
$(function() { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So we'd be using the the native onload
event to trigger a jQuery function ($(function)
) that creates another function (cleanURI
), calls it, and calls four other jQuery commands (on
, val
, val
, and filter.prop
)?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes. Not ideal but since it was the only working solution yet, it's worth logging it to the conversation should we need to fall back on it. And only requires adding two lines of code to the existing. Do the latest changes committed since work? Were you able to confirm that before pushing.?
We're getting some errors here, so we can't merge this yet:
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Some things need to be addressed first: #4604 (comment)
Summary
Required reviewers
Two front-end and/or UX?
Impacted areas of the application
Preloading the homepage hero has no downside.
Now we're delaying script loads for a few templates. The most likely complication is that one of the scripts won't have loaded when it was expected, meaning a component isn't activated or isn't ready to when a user thinks it should have been. This could happen the first time a site visitor requests a script after our last deploy (pages that share scripts will use their cached versions) and when there's a slow connection.
The affected templates are for the homepage, elections, election search, and landing.
The pages
Screenshots
No visual changes
Related PRs
None
How to test
./manage.py runserver
For the homepage, Lighthouse should no longer mention "eliminate render blocking resources"