WordPress comments become slow when the page tries to retrieve, render, and download an entire discussion at once. Large threads increase database work, HTML size, browser layout, avatar requests, and reply-script processing. The most reliable sequence is to paginate the thread, inspect the WP_Comment_Query request, reduce avatar overhead, then defer native comments that are below the fold. If those changes do not remove the delay, measure database time, cache behavior, and hosting response separately.
Antihost offers managed WordPress hosting with free migration, one-click staging and a 14-day free trial.
What makes a WordPress comment section slow?
A comment area is a small application embedded in a post. Before a visitor can read it, WordPress may have to count matching comments, retrieve rows and metadata, build nested replies, render HTML, enqueue reply JavaScript, and generate avatar markup. The browser then parses that markup, lays out the thread, executes scripts, and requests every external image that the page references.
As an Amazon Associate I earn from qualifying purchases.
Do these 3 things before closing this tab:
1Repair Windows errors before they cause bigger problems2Scan for outdated or missing drivers - takes under a minute3Clear out junk files and repair common Windows errorsThe cost is usually modest for a short discussion. It compounds when a post has hundreds or thousands of comments, deep reply nesting, several metadata fields, and an avatar for each visible author. A long thread can pull in dozens of avatars, Gravatar lookups and reply scripts before the visitor has even reached the comments, according to the WordPress.org listing for the Lazy Load for Comments plugin.
Large threads enlarge every layer of the request
- Database: WordPress must select the comments that match the post and status, apply ordering and pagination rules, and often prepare comment metadata.
- Server rendering: The theme turns each result into markup, including reply links, moderation information, author details, and avatar elements.
- HTML transfer: More comments mean a larger initial response, which takes longer to transfer and parse.
- Browser work: The browser lays out every comment and executes the scripts needed for replies before the reader reaches the discussion.
- Image requests: Enabled avatars normally use Gravatars, so each displayed avatar can add a lookup and an image download.
Avatars and reply scripts can be expensive even when the database is fast
WordPress uses Gravatars by default for displayed comment avatars when avatars are enabled in Discussion settings. A page with many unique commenters can therefore generate many image lookups. Reply functionality adds JavaScript and event handling to the initial page, even if the visitor never clicks Reply.
#1 Best Overall
A slow query may be hidden behind a fast-looking page
Page caching can make an already-generated comment page appear quick while an uncached request remains slow. Conversely, a fast database query can still produce a poor experience if the response contains a very large HTML tree or dozens of image requests. Measure the server request, the browser waterfall, and the cache state rather than treating “time to first byte” as the whole problem.
Identify the bottleneck before changing the site
Take a baseline on a representative post: one with a short discussion, one with a long discussion, and one that receives new comments frequently. Test while logged out, with the normal cache cold and warm. Record the document request, comment-related requests, image requests, and the time at which the comment section becomes usable.
Use browser network timing
- Open the post in a private browser window.
- Open Developer Tools and select the Network panel.
- Reload with the network log preserved. Filter for the document, avatar images, comment-related REST requests, and JavaScript files.
- Note the initial document size, the number of avatar requests, the duration of the document request, and whether comments arrive in the first response or in a later request.
- Repeat after each change with the same post, viewport, and cache condition.
This reveals whether the first response is oversized, whether avatars dominate the waterfall, or whether a deferred request is the slow part.
Separate database, object-cache, page-cache, and hosting time
Use a query profiler or the site’s server logs to inspect database duration and the number of comment queries. Check whether an object cache is being hit and whether a full-page cache is serving the post. Compare a cache hit with a cache miss, and compare normal traffic with an uncached administrative or preview request. If the origin server is slow before the browser receives any HTML, front-end changes alone will not solve the delay.
Confirm which comment system is actually running
Native WordPress comments are retrieved through WP_Comment_Query. A replacement system may render its own interface and never call the native comment template. Identify the system before installing a lazy-loading solution: a tool designed for core comments will not automatically control a third-party comment area.
Fix the highest-impact issue first: paginate comments
Pagination limits the number of comments that WordPress retrieves and renders for the first view. It reduces initial HTML, browser layout, avatar requests, and reply-script work without removing older comments from the site.
Enable pagination in Discussion settings
- In the WordPress dashboard, open Settings → Discussion.
- Find the option for breaking comments into pages.
- Enable it and choose a modest number of top-level comments per page.
- Choose whether the newest or oldest comments appear first.
- Save the settings, clear the relevant page cache, and test a post with a long thread.
The best page size depends on the site’s purpose. A support discussion may need the oldest comments first so readers can follow the chronology. A news or community post may prioritize the newest replies. Test both orders against real reading behavior instead of assuming that one is universally faster.
Use the Comments block controls on block themes
The Comments block includes a Comments Pagination block by default. In the Site Editor or post template, select the Comments block and adjust its pagination controls. The pagination block displays navigation to the previous or next comment section; it is not a separate archive of all comments. Verify that the previous, next, and current-page controls have visible labels and keyboard focus states after styling.
Why pagination is usually the safest first change
- Only the selected page is rendered initially.
- Each page can be cached as a stable response for the same post and page number.
- Visitors can navigate without requiring JavaScript to reveal the first comments.
- Search engines and assistive technology receive a conventional, link-based structure.
- The change works with core comments in both classic and block-based templates, provided the theme honors the setting.
WordPress core performance work has specifically focused on discouraging unbounded “all comments per page” interfaces and making fallback comment queries more modest. Avoid replacing pagination with an infinite list unless there is a clear usability reason and a measured plan for its extra requests.
Audit the WP_Comment_Query request
When pagination is enabled but the server remains slow, inspect the arguments and filters that build the comment query. Core documents controls including number, paged, offset, ordering, and no_found_rows. A theme or plugin can override those values, request more records than the template displays, or add expensive metadata work.
Recommended Free Tools
Match retrieval to what the template displays
Set the query to retrieve only the comments needed for the current page. Avoid requesting a large number and then hiding most results with template logic. Use the page number supplied by the pagination control rather than fetching every comment and slicing the array in PHP. Keep ordering deterministic so a new comment cannot cause items to jump unpredictably between pages.
Use offset carefully. It can be useful for a deliberate skip, but a large offset can become expensive on a large table and can interact with pagination calculations. Prefer the query’s page-based controls when the goal is ordinary next-page navigation.
Understand no_found_rows before changing it
A query that needs to display total pages must obtain a count of matching comments. If a template never displays a page count or navigation, a no-found-rows query can avoid that count. If pagination is active, disabling the count without replacing it can leave the interface with incorrect totals or no next-page information. Treat the setting as a contract between the query and the navigation UI, not as a universal speed switch.
Check filters and short-circuit hooks
Custom filters can change the normal query path. The comments_pre_query hook can bypass the database query entirely, for example when a custom cache or backend supplies comment objects. That path must still provide the values the pagination layer expects. In particular, preserve found_comments and max_num_pages when the interface needs accurate navigation.
What’s actually slowing this PC down?
Pick the symptom - the matching free tool is one click away.
Account for metadata work
WordPress core queues comment metadata for lazy loading and can batch the queued metadata into a database or cache call. A plugin that adds several metadata fields to every comment can still enlarge that batch and its serialization cost. Remove fields the template does not use, and check custom filters that call metadata functions once per comment instead of allowing the core queue to batch them.
Illustrative query shape
$query = new WP_Comment_Query( array(
'post_id' => $post_id,
'number' => $per_page,
'paged' => $page,
'orderby' => 'comment_date_gmt',
'order' => 'DESC',
'no_found_rows' => false,
) );The values in this example are a pattern, not a universal configuration. Match number, ordering, and the count requirement to the site’s template. Test the resulting SQL and pagination data with the site’s normal filters enabled.
Reduce avatar and script overhead
Disable avatars when they do not help the discussion
- Open Settings → Discussion.
- Scroll to the avatar settings.
- Clear the option that displays avatars, then save.
- Clear page and object caches and retest the same long-thread post.
This removes avatar markup and the associated image requests, but it also removes a visual identity cue. It is most appropriate for technical support, editorial feedback, or private communities where the author’s name is sufficient.
Consider a local or lighter avatar strategy
If identity matters, test an approach that serves a small local image or a single fallback asset from the site’s own domain. Compare the alternatives on four dimensions:
The Tool Desk
Outbyte PC Repair FREERepair Windows errors before they cause bigger problemsFix Now →Outbyte Driver Updater FREEFix the driver behind crashes, sound loss and screen glitchesFind Drivers →| Approach | Requests and payload | Visual identity | Privacy and maintenance |
|---|---|---|---|
| Gravatars enabled | Potentially one lookup and image download per displayed commenter | Familiar user-supplied profile image when available | Depends on an external avatar service and its requests |
| Avatars disabled | Removes avatar image work from the comment list | Names, initials, or CSS can provide limited identity | Least maintenance; no avatar images to manage |
| Local or lightweight avatars | Can consolidate delivery on the site’s own cache and domain | Identity can be retained with a controlled design | Site owner must manage storage, resizing, fallback behavior, and updates |
The table describes trade-offs, not a guaranteed request count. Measure the selected implementation because theme markup and image handling determine the actual waterfall.
Keep reply functionality proportional to use
Nested replies are useful in active discussions, but every visible reply link and associated script adds markup and behavior. Do not enqueue reply scripts on templates that do not display a reply form. If a plugin or theme adds a script globally, verify whether it can be limited to singular posts with comments enabled. This is a code and template decision; confirm it in the browser after changing it.
Independent reader supportYour contribution helps us test, update, and keep practical guides available for everyone.Lazy-load native comments below the fold
Lazy loading defers rendering work until the visitor scrolls toward the comments or activates a load control. It is different from pagination: pagination chooses how many comments belong to a page, while lazy loading postpones when that page is requested or rendered.
What the official Lazy Load for Comments plugin does
The WordPress.org listing describes scroll-based or button-based loading, retrieval of rendered comments through the WordPress REST API, compatibility with classic and block themes, and per-post caching of rendered comments. It also states that crawlers can receive inline comments for SEO. The listing recorded version 2.1.0, required WordPress 6.0 or higher, was tested up to WordPress 7.1.2, and showed more than 2,000 active installations in 2026.
Free tools Windows power users keep installed
One-click scans. No signup required.
- In the dashboard, open Plugins → Add New.
- Search for Lazy Load for Comments and verify the author and listing details before installing.
- Install and activate it on a staging copy first.
- Choose whether comments load on scroll or through a visible button, if the plugin’s settings expose both choices.
- Test a long native-comment post while logged out, with JavaScript enabled and disabled.
- Check the page source or crawler-facing output to confirm that the site’s required comment content remains discoverable.
The plugin’s scope matters. The listing identifies third-party systems such as Disqus and Jetpack Comments as replacements for the native comment area and outside its scope. If the site uses one of those systems or another replacement, use that system’s own loading controls instead of assuming a native-comment plugin will intercept it.
Pagination versus lazy loading
| Decision factor | Pagination | Lazy loading |
|---|---|---|
| Initial HTML | Contains the selected page of comments and ordinary navigation | Can omit the comment list from the first view and fetch or render it later |
| SEO rendering | Uses conventional linked pages | Requires a crawler-safe output strategy; the listed plugin documents inline comments for crawlers |
| Accessibility | Previous/next links are familiar and work without a special control | Requires a clearly labelled, keyboard-accessible load control and a usable result announcement |
| Cacheability | Each page can be cached as a normal URL response | Rendered comment responses may be cached separately; verify invalidation when new comments arrive |
| Theme compatibility | Supported by Discussion settings and the Comments block when the theme respects them | The listed plugin documents classic and block-theme compatibility, but test the site’s template and customizations |
| Comment source | Works with native WordPress comments | Native-comment scope must be confirmed; replacement systems require their own integration |
Use pagination when a conventional, crawlable and script-independent interface is the priority. Add lazy loading when the first view still does too much work after the page size is sensible, especially on posts where comments sit far below the article. The two approaches can be combined: paginate the discussion and lazy-load the first page only when that page itself is expensive.
When front-end changes do not fix the delay
Profile the query path
Inspect the generated comment query, its joins and filters, and the time spent retrieving metadata. Look for code that runs a separate query for each comment, requests all comments despite a page limit, or disables an intended cache through changing arguments. Confirm whether comments_pre_query is supplying cached results and whether it sets pagination totals correctly.
Check object-cache behavior
Comment objects and metadata may be served from an object cache on one request and rebuilt on another. Compare warm and cold requests. A cache that stores the comment list but not its metadata can leave the page doing substantial work after the main query appears fast. Purge and refill caches after changing query arguments so you do not compare stale and fresh structures.
Quick wins for a faster PC:
Clear out junk files and repair common Windows errorsFree Scan →Scan for outdated or missing drivers - takes under a minuteDriver Scan →Check page-cache variation
Page caches may vary by comment page, login state, cookies, or query string. Make sure the cache key distinguishes page 1 from page 2 and does not accidentally serve a logged-in or moderated response to anonymous visitors. If a lazy-loaded REST response is cached per post, verify that submitting a new comment invalidates the affected response.
Evaluate hosting response independently
If the origin takes a long time to send the first byte even with a small comment page, investigate PHP worker saturation, database capacity, storage latency, and the host’s response time. The comment template cannot compensate for an origin that is already queueing requests. Treat hosting changes as a separate investigation and measure the same URL before and after.
Accessibility, SEO, and cache checks after optimization
- Keyboard use: Pagination links and any “Load comments” button must be reachable and operable without a mouse.
- Focus management: After a deferred load, move focus or announce the newly inserted region in a way that does not disorient keyboard and screen-reader users.
- Progressive enhancement: A visitor with JavaScript disabled should still receive a usable paginated comment experience when the site’s SEO and moderation requirements demand it.
- Permalinks: Confirm that comment-page navigation produces stable, shareable URLs and that browser Back and Forward controls work.
- Moderation: Test pending, spam, and approved comments as an administrator and as a logged-out visitor; caching must not expose moderation-only content.
- New-comment invalidation: Add a test comment and verify that the correct page, count, and cached fragment update.
- Theme styling: Check nested replies, long author names, avatar failures, and empty pages at mobile and desktop widths.
A practical order of operations
- Record browser network timings, document size, query time, and cache state on representative long-thread posts.
- Enable a modest comment page size and choose the order that matches the site’s reading goal.
- Verify the Comments block’s pagination controls or the classic theme’s pagination markup.
- Inspect
WP_Comment_Queryarguments, custom filters, metadata calls, and anycomments_pre_queryimplementation. - Disable Gravatars if they are not essential; otherwise test a locally served, lightweight alternative.
- Defer native comments with a tested lazy-loading implementation when the initial view still carries unnecessary comment work.
- Retest with cold and warm caches, logged-in and logged-out sessions, JavaScript enabled and disabled, and a replacement comment system if the site uses one.
- Only after those checks, investigate database, object-cache, page-cache, and hosting latency as separate causes.
No official source establishes a universal percentage speed gain for these changes. The result depends on thread length, theme markup, avatar count, query filters, cache state, and hosting. Publish a performance claim only after measuring the site’s own before-and-after timings.
Bottom line
Start by limiting how many comments the first request can retrieve and render. Then make the query match that limit, remove unnecessary avatar and metadata work, and defer native comments that are below the fold. Preserve pagination totals whenever a custom cache or short-circuit supplies comments. If the browser still waits, use query profiling and cache-aware server measurements to determine whether the remaining delay is database work, object or page-cache behavior, or the hosting response itself.
