Seems like a good idea to me. Sample LHR went from 528kb -> 540kb.

Idea came from playing with Gemini:

core/audits/audit.js - makeTableDetails returns an empty array for headings when results are empty, but a processed array of heading objects otherwise. This inconsistency means consumers of the table details
must handle two different "shapes" for the headings property depending on whether the table has items. If a UI renderer always expects headings to be populated with the defined column structure (even for an
empty table), this could lead to rendering issues or errors.

More details:

makeTableDetails in core/audits/audit.js has inconsistent headings output. The makeTableDetails function takes headings (an array of heading definition objects) as an argument. If the results array
(table rows) is empty, it returns: { type: 'table', headings: [], items: [], summary } Here, headings is an empty array. If results is not empty, it eventually returns (structure inferred from typical usage and the
need to process keys): { type: 'table', headings: processedHeadingsArray, items: processedItemsArray, ... } Where processedHeadingsArray would be derived from the input headings. This means the headings property in
the returned object has a different nature based on whether there are items. Consumers (like UI rendering components) might expect details.headings to always reflect the defined column structure, even if
details.items is empty. Returning [] for headings when the table is empty means the information about what columns would have been present is lost. This can lead to UI tables rendering without headers for empty
data sets, or requiring special handling by the consumer.