Hacktoberfest 2026: the issues maintainers tagged for October, open and beginner-friendly. Browse Hacktoberfest issues

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

Open
  • Is something wrong?
#2,897 2 comments 0 reactions 0 assignees View on GitHub

Maintainers usually reply within 1 day

Nobody has claimed this yet.

Assessment

Difficulty
5/5
Estimated time
Over a week
Newbie friendliness
12/100
Issue type
Refactor
Clarity
Mostly clear
Activity status
Active
Tech stack
php, wordpress
Domain
backend, performance

Research direction

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.

Written by the indexing model from the issue text.

Description

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.

Dominant language
PHP
Stars
21
Forks
2
Avg merge
8h 35m
Merged PRs (30d)
659

Getting set up

First steps

  1. Read the whole issue, then the project's contributing guide.
  2. Comment on the issue to say you are picking it up — it saves two people doing the same work.
  3. Fork the repository and make your change on a branch.
  4. Open a pull request that references the issue number.

More from Automattic/blocks-engine

All issues in Automattic/blocks-engine

Similar issues

More PHP issues

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.