Severity: performance — grows silently with site size, invisible until severe Component: SP Page Builder (Articles addon + helpers/articles.php)

Summary

The #__sppagebuilder table is created with no index other than the primary key on id.

components/com_sppagebuilder/helpers/articles.php (line 631 in our copy) runs, once per article listed, a query that filters on four non-indexed columns:

sql SELECT content, text, css FROM #__sppagebuilder WHERE extension = 'com_content' AND extension_view = 'article' AND view_id = 2997 AND active = 1

With no usable index, each of these performs a full table scan. Because the table stores complete page layouts (content, text, css are large text columns), the scan cost is driven by bytes, not by row count — so it degrades as the site matures, not as it gains pages.

On our site the table holds 625 rows but ~126 MB. An Articles addon configured to show 10 articles therefore reads roughly 1.2 GB from disk to render one page.

Measured impact

Home page of our populated site, measured with Joomla's own debug profiler (System Debug on, which bypasses the page cache so every request is a real render):

Total page build time 15.75 s Queries 118, 15.29 s accumulated The 10 #__sppagebuilder lookups above 1.39 – 1.57 s each, ~15 s total

Everything else on the page is unremarkable: the next most expensive item is mod_finder at 211 ms.

Because Joomla's page cache was set to 15 minutes, this was invisible in day-to-day use: 97% of visitors got a cached page in 0.45 s, and one visitor every 15 minutes waited 11–17 seconds. We only found it by logging response times every 5 minutes overnight — the pattern was a slow request at exactly 15-minute intervals, all night long.

Fix that resolves it sql ALTER TABLE #__sppagebuilder ADD INDEX idx_sppb_lookup (extension, extension_view, view_id, active);

Same page, same conditions, immediately after:

before  after

Page build (uncached) 15.75 s 0.43 s

A 36× improvement from one index. No other change was made.

What we'd suggest Add the index to the component's install SQL, so new installations get it. Add it as an update SQL step, so existing installations get it on the next update. This is the important half: every site that has been running SP Page Builder for a few years already has this problem and almost certainly does not know it. Consider batching the lookup. Rendering a list of N articles currently issues N separate queries that differ only by view_id. A single WHERE view_id IN (…) would reduce 10 queries to 1 regardless of indexing, which also helps sites on shared or slow database hosts. Why this goes unreported

Nothing in the stack is positioned to notice it:

Joomla's database check only validates core tables against the expected schema; third-party extension tables are out of scope. Security/maintenance extensions (we use Akeeba Admin Tools) check files, permissions and table optimisation — not query plans. MariaDB's slow query log is off by default on most hosts.

The only instrument that showed it was Joomla's own debug profiler, which has to be deliberately enabled and read. We would not have looked there if users had not reported that the site was "sometimes" slow.

Scope check

The same server hosts nine Joomla sites using SP Page Builder. None of the nine had any index on #__sppagebuilder beyond the primary key. The seven smaller ones (2–5 MB tables) are not noticeably slow today — they are simply earlier on the same curve.

Environment

SP Page Builder 6.9.1 Joomla 6.1.4 PHP 8.3.35 (FPM) Database MariaDB 10.11.14 Web server Apache 2 Template Helix Ultimate (shaper_helixultimate) Related observation (separate issue, lower priority)

The reason the table reaches 126 MB on 625 rows is the generated CSS stored with each layout. On our home page the rendered inline stylesheet is 198 kB, of which:

491 rules are completely empty — #sppb-addon-xxxxx{ } — accounting for ~45 kB; in the largest single <style> block (112 kB, covering 7 sections and 10 addons), 360 of 881 rule blocks are exact duplicates.

Suppressing empty rules alone would cut roughly a quarter of the generated CSS, both in the page served to visitors and in the stored row — which is also what makes the scan above expensive. We mention it as context rather than as a separate complaint.