Asset loading, output size and runtime cost
View All Tags
The question: How should the theme handle responsive typography long-term — keep stepping sizes at a breakpoint, add per-device controls to every field, or move to a fluid type system? And what has to be true for a fluid system to not fail accessibility?
The question: With "Minify combined script" enabled, the generated
combined-<hash>.js still had one statement per line — it didn't look minified. Is the
minifier failing, and should it collapse to a single line like everyone expects "minified" to?
The question: an audit flagged "no rate limiting" on the framework's public AJAX endpoints. But every one of them verifies a nonce, sanitizes its input and validates it. Is a nonce not sufficient?
The question: Live Editor kept at most 20 revisions per page, which sounds like a bounded feature. One site was holding 150.6 MB of revision postmeta. Where did the bound go?
The question: memoizing a single function halved the plugin's front-end memory. The remaining +15.2 MB has an identifiable cause and a plausible fix. Why not take it?
The question: Every element's options modal took ~873 ms and ~6.7 MB to open. An existing "lazy multi-picker" optimisation was already in place and clearly not working. What is actually costing that, and can it be deferred without risking saved values?
The question. We just moved the Section shortcode's per-instance styling out of inline style=
and into stylesheets: Min Height (a fixed enum) became predefined .section--minh-{40|60|80|100}
classes, Container Width (a user-extensible named-width library) and the vertical-align flex
became .u{hash}-scoped rules in the per-page page-{id}.css. The background
(color / gradient / image / overlay) is now the only thing the section still prints as an inline
style="background-…". Should it move to page-{id}.css as well — for a fully inline-free markup —
or stay inline?
The question: the Post Types extension already deferred flush_rewrite_rules() to the request
after a save, which is the pattern most no-code CPT plugins get wrong. So why were third-party
permalinks occasionally 404-ing after someone saved the screen?
The question: Phase 0 of the Animation Engine's motion roadmap is "make scrolling feel effortless everywhere, and give every scroll-driven effect one shared clock." That raised two forks. (1) Where should the new inertia smooth-scroll live — a new engine module, or an extension of the theme's existing anchor-link "Smooth Scroll"? (2) How do we unify the scroll-reactive modules so they stay in lockstep — port them all to GSAP's ScrollTrigger, or reuse the engine's own shared animation loop?
The question: the Animated icon kind plays Lottie animations from a URL/upload as raw Lottie
JSON. Should it also accept .lottie (dotLottie) files, and would that help pages that show
many animated icons at once?