Conversation
Lighthouse & GA4 upgrades
There was a problem hiding this comment.
Pull request overview
Ports the “Lighthouse & GA4 upgrades” work (from #424) into srccon.org’s Jekyll templates/config to improve performance (CLS/font loading), accessibility, and enable GA4 tracking site-wide.
Changes:
- Adds GA4 configuration via
_config.ymland conditionally injects the GA4 tag in the shared head include. - Improves font-loading fallbacks for Typekit by adding loading/inactive class handling plus matching CSS fallbacks.
- Adds explicit
width/heightto key images (logos/sponsors) and preloads the primary logo image for faster rendering.
Reviewed changes
Copilot reviewed 6 out of 6 changed files in this pull request and generated 2 comments.
Show a summary per file
| File | Description |
|---|---|
media/css/style.css |
Adds fallback font stacks keyed off Typekit loading/inactive states; removes a few unused/duplicate rules. |
homepage.md |
Updates newsletter link to HTTPS. |
_layouts/layout_hub.html |
Preloads the logo image and adds explicit dimensions to the hub logo <img>. |
_layouts/layout.html |
Adds explicit dimensions to header and sponsor images to reduce layout shift. |
_includes/headmeta.html |
Expands Typekit loading config (callbacks/classes) and includes GA4 tag injection when enabled. |
_config.yml |
Sets a GA4 measurement ID in defaults to enable tracking. |
| <script src="https://use.typekit.net/mvg8obr.js"></script> | ||
| <script> | ||
| try { | ||
| Typekit.load({ async: true }); | ||
| Typekit.load({ | ||
| async: true, |
There was a problem hiding this comment.
async: true in Typekit.load(...) does not make the kit download non-blocking; the kit is still loaded via a plain <script src=...> tag (no async/deferred loading). If the goal is Lighthouse/perf improvement, consider loading the Typekit kit script asynchronously (e.g., add async to the script tag or use the recommended non-blocking embed pattern) so it doesn’t block HTML parsing.
| document.documentElement.classList.add("fonts-fallback-locked"); | ||
| }, | ||
| }); | ||
| } catch (e) {} |
There was a problem hiding this comment.
The Typekit failure path doesn’t apply the new fallback-lock behavior. If the Typekit script fails to load (so Typekit is undefined), the catch block runs and currently does nothing, leaving fonts-fallback-locked unset even though the CSS is relying on it. Consider adding fonts-fallback-locked in the catch block (and/or handling the Typekit-undefined case explicitly) so the fallback fonts are consistently applied on hard failures.
| } catch (e) {} | |
| } catch (e) { | |
| // If Typekit fails to load or throws before calling inactive, ensure fallback fonts are locked. | |
| document.documentElement.classList.add("fonts-fallback-locked"); | |
| } |
Bringing over work from #424