fix: technical debts left by the Sites, Authors and SEO slices, plus backend support for the new Sites and Authors pagination

docs/performance.md

@@ -0,0 +1,21 @@
+# Performance notes
+
+## The `?seo=` article filter
+
+`GET /v1/article/` assesses the SEO status of articles in memory, because the status depends on the body, the site template and the authors. Every request assesses every visible article once, to fill `counts.suggestions`, and `?seo=` reuses that assessment to filter before paging. The cost therefore grows with the number of articles, not with the page size.
+
+Measured by `TestSeoFilterPerformance` in `test/seo_filter_performance_test.go` (skipped with `-short`): 5,000 articles of about 5 KB each in one site, on a SQLite file in a temporary directory, every article with suggestions, `?seo=suggestions&size=25`, slowest of 3 runs:
+
+| Version | Time |
+| --- | --- |
+| `counts.suggestions` added, assessment done twice | about 430 ms |
+| assessment shared between the counts and the filter | about 270 ms |
+
+The target is 300 ms for 5,000 articles. The test also measures the default list (`GET /v1/article/` with no `?seo=`), which pays the same assessment for `counts.suggestions`. Latest run on the development machine, slowest of 3 runs:
+
+| Request | Time |
+| --- | --- |
+| `?seo=suggestions&size=25` | 315 to 338 ms |
+| default page, no `?seo=` | 307 to 329 ms |
+
+Both are slightly above the 300 ms target on this machine (they were about 270 ms in the earlier measurement), so the target is logged by the test but not enforced; no cache or index was added. Re-run the test with `go test -tags nofrontend ./test/... -run TestSeoFilterPerformance -v -count=1` after a change to the assessment rules or the article repository. The time depends on the machine; the test only fails above 500 ms.