14 posts tagged with "Performance"

The question: Walking the DOM from <body> down to the first page-builder <section> shows a stack of wrappers — #page.site → #content.site-content → main#main.site-main → article.fw-col-12 → .entry-content → the plugin's .fw-page-builder-content → section. For a full-width, all-builder page that's a lot of nesting. The obvious first cut is the outermost one: drop #page and move its .site layout (the flex column, min-height:100vh) onto <body> itself. Should we?

The question: Modern, AI-generated sites are built with Tailwind (flex/grid utilities). Should we just integrate Tailwind into UnysonPlus — swap the plugin's own utility classes for Tailwind's — so the layout model is modern and the Site Converter has an easier job converting Tailwind sources?

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?

The question: The Posts "Card Style" list felt redundant — several styles are just an image mask or a fill on top of a base layout, and we already have Box Presets. How should image treatments be organized, and should they become a reusable Theme Settings preset?

The question: Posts now has 20-plus card designs. The markup only ever outputs the chosen design, but does the CSS? Should every page with a Posts block load all designs' styles, or only the one in use — and if only one, how do we wire that without a list to maintain as designs keep growing?