fix(controller): cap answers rendered into the server-side page - #1574
Open
culfin wants to merge 1 commit into
Open
fix(controller): cap answers rendered into the server-side page#1574culfin wants to merge 1 commit into
culfin wants to merge 1 commit into
Conversation
The question template fetches 999 answers and then the comments for all
of them, regardless of how many the page will show. The value is a
literal in the controller, so there is no way to lower it:
internal/controller/template_controller.go
answerReq := &schema.AnswerListReq{
QuestionID: id,
Page: 1,
PageSize: 999,
}
Measured on a question with 999 answers, against 0.2s for an ordinary
question:
HTML ready on the server 2.6s
first answer visible in browser 23.5s
Most of that time is spent parsing 878 KB of HTML and hydrating a
thousand posts.
This replaces the literal with a named constant of 100 and explains what
the number is for. It is a mitigation, not a fix: the template renders
whatever it is given and has no pagination, so any value here is a
trade-off between page weight and how much of a long question a crawler
gets to see.
The real fix is to paginate the template page the way the question list
already does — bind the page from the query and render ui/template/page.html.
Happy to prepare that as a follow-up if maintainers prefer it.
Co-Authored-By: Claude Opus 5 (1M context) <noreply@anthropic.com>
LinkinStars
self-requested a review
August 18, 2026 09:21
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The question template fetches 999 answers, then the comments for all of them, regardless of how many the page will show. The value is a literal in the controller, so there is no way to lower it:
Measured on a question with 999 answers, against 0.2 s for an ordinary one:
Most of that is spent parsing 878 KB of HTML and hydrating a thousand posts.
Proposed Changes
This is a mitigation, not a fix
The template renders whatever it is given and has no pagination, so any value here trades page weight against how much of a long question a crawler gets to see. 100 is a compromise: of 7382 questions in my forum only 30 have more than a hundred answers, so for all the others nothing changes at all.
The real fix is to paginate the template page the way the question list already does — bind the page from the query and render
ui/template/page.html, which exists and is used elsewhere. That is a larger change touching both the controller and the template, so I did not want to submit it unasked. Happy to prepare it as a follow-up if you prefer that route.Related: #1573 does the same for the client-side request.