Hacktoberfest 2026: le issue che i maintainer hanno segnato per ottobre, aperte e adatte ai principianti. Sfoglia le issue Hacktoberfest

Parse and index each shared stylesheet once per import; make CSS analyses queries over that index

Aperta
  • Qualcosa non va?
#2,897 2 commenti 0 reazioni 0 assegnatari Vedi su GitHub

I maintainer di solito rispondono entro 1 giorno

Nessuno ha ancora preso questa issue.

Valutazione

Difficoltà
5/5
Tempo stimato
Più di una settimana
Idoneità per principianti
12/100
Tipo di issue
Refactoring
Chiarezza
Abbastanza chiara
Stato di attività
Attiva
Stack tecnologico
php, wordpress
Ambito
backend, performance

Direzione di ricerca

Start by counting constructions of AuthorStyleAnalysis and calls to CssRuleAnalyzer::analyze per import, as acceptance step 1 asks, using WordPressCompatCss::prepareSpecificityContext and FormDispatcher::capturePseudoFormFallback as entry points. The work is a shared site style index keyed by stylesheet content hash, with analyses reduced to queries over it. Done means a counter test shows one parse per distinct stylesheet set and byte-identical output on the parity and contract suites.

Scritto dal modello di indicizzazione a partire dal testo della issue.

Descrizione

Problem

Conversion cost grows with pages × shared stylesheet size, not with the content of each page. Site builders ship one large stylesheet set to every page, and each page parses and analyses that set again, several times over.

Evidence from a 49-route site-builder import (all 49 pages share most of their CSS):

  • Compose: about 90% of the time is in WordPressCompatCss::prepareSpecificityContext → AuthorStyleAnalysis::__construct, which is rebuilt for every page from the same combined author CSS.
  • Compile: about 40% is in FormDispatcher::capturePseudoFormFallback → FormLayoutGraphBuilder::build → CssRuleAnalyzer::analyze, and about 15% in rebuilding unsupportedSelectorReferencesElement regexes.
  • At least 12 call sites run (new CssRuleAnalyzer())->analyze($stylesheets, ...) over the same stylesheets with different property sets and selector filters: FormPresentationGraphBuilder (×6), FormLayoutGraphBuilder (×2), FormStepTrackDetector (×2), and others.
  • #2854 and #2856 cut compose from 1315s to 511s and the importer total from 2665s to 2149s by sharing work inside one analysis. The shape stayed the same: each page and each analysis still pays for the whole stylesheet set.
  • SchemaProductEvidence::rows (#2888) has the same shape. It scans every document that contains JSON-LD on every compile() call: about 1.1s for 19 documents (52 MB) per page on this site.

Proposal

One site style index per distinct stylesheet set, keyed by content hash and built once per import.

  • It holds the parsed rules, cascade order, layers, conditions, specificity and selector indexes (by class, id and tag).
  • Each existing analysis becomes a query over that index (a property set plus a selector filter) instead of a re-parse.
  • AuthorStyleAnalysis is built from the index, so per-page work covers only the page's own markup and CSS that is unique to the page.
  • Site-wide document evidence (structured data, for example) is collected once per artifact, not per compile() call.

Acceptance

  1. Measure first, on current trunk. Count CssRuleAnalyzer::analyze and AuthorStyleAnalysis constructions per import, and the number of distinct stylesheet-set hashes, on a multi-page fixture whose pages share one large stylesheet. Post the numbers here.
  2. Parse and index count equals the number of distinct stylesheet sets, independent of page count. A unit test asserts this through a counter.
  3. Compiled output is byte-identical on the existing parity and contract suites.
  4. On a 40+ page shared-stylesheet fixture, compose and compile CPU per page stays flat as page count grows. Report before/after timings.

Part of Automattic/static-site-importer#2111.

AI assistance: drafted by Claude (Anthropic) via Pi from profiling and source reading during a 49-route site-builder import investigation; reviewed by Chris Huber.

Lingua principale
PHP
Stelle
22
Fork
2
Merge medio
7h 50m
PR unite (30g)
686

Preparare l'ambiente

Come iniziare

  1. Leggi tutta la issue e poi la guida ai contributi del progetto.
  2. Commenta sulla issue per dire che te ne occupi tu — evita che due persone facciano lo stesso lavoro.
  3. Fai un fork del repository e lavora su un branch.
  4. Apri una pull request che faccia riferimento al numero della issue.

Altre issue di Automattic/blocks-engine

Tutte le issue di Automattic/blocks-engine

Issue simili

Altre issue su PHP

Ricevi le nuove issue nella tua casella

Un breve riepilogo di issue GitHub adatte ai principianti.