While looking into the author link, I also timed my live site (Elements 3.0.18, CMS v2, 137 posts, most of them 2,000–6,000 words). The first byte arrives quickly, but every page with a Collection or Item takes 3–9 seconds to finish loading. Pages without CMS components finish in about 0.06 s:
Page Finished loading
About (no CMS) 0.06 s
Collection, 8 per page (blog index) 3.1–7.8 s
Collection, 8 per page (archive) 3.0–3.8 s
Collection, 8 per page (topic pages) 3.1–3.9 s
Single Item (article) 3.2–8.9 s
What I checked first
Caching: the docs don’t offer caching for Collections or Items. Only RSS, the sitemap and the search index are cached.
Repeated errors: the troubleshooting guide suggests checking for errors retried on every request. No posts fail to parse, and every post appears in the lists, so nothing is logged on each request.
What seems to cause it (CMS pack, componentAssets/api/cms/)
Collection::discover() globs every file in the folder and calls Item::fromFile() on each.
Item::fromFile() → Parser::parse() converts the entire Markdown body to HTML with CommonMark, plus author/tag lookups. That happens for every file on every request, before filtering, sorting and paginating down to the 8 items shown.
There’s no cache, so the cost grows with every post published.
I know the v2 core was rewritten to be faster, and on a small blog that probably holds. But this cost scales with the size of the site, so larger blogs feel it.
Evidence
I replaced the Collection on my 15 topic pages with a custom component that reads only the front matter and applies the same filter, sort and pagination rules. Nothing else on those pages changed, and the output is identical on all 61 list pages. Those pages went from 3.1–3.9 s to about 0.05 s. My blog index, archive and articles still use the stock components and still take 3+ seconds.
Suggestions
Filter, sort and paginate on front matter first, and convert only the bodies of the items actually rendered. A Collection that shows only excerpt would then never need a body.
Or cache parsed items keyed on each file’s modification time, as the search index already does with Search::isCacheStale().
For the Item page, avoid scanning the whole folder unless prev/next or related items actually need it.
Thanks,
Edward