Yoast, a leading provider of SEO software for WordPress, has released version 27.8 of its flagship Yoast SEO plugin, introducing a suite of performance optimizations designed to drastically reduce loading times across its functionalities. The updates are particularly impactful for large websites with extensive numbers of posts and users, addressing long-standing challenges associated with scalability in complex WordPress environments. These enhancements underscore Yoast’s continuous commitment to delivering well-tuned software with minimal server overhead and rapid loading speeds, a critical factor for millions of websites worldwide.
Background: The Imperative of Performance in the WordPress Ecosystem
In the vast and varied landscape of WordPress, where setups range from small personal blogs to massive enterprise-level platforms, plugin performance is paramount. Yoast SEO, installed on millions of websites, faces the unique challenge of operating efficiently across this spectrum. The core philosophy driving Yoast’s development has always been to optimize software for speed and resource efficiency. This is not merely a convenience but a necessity for modern web performance, directly impacting user experience, search engine rankings, and server costs. Slow-loading websites can lead to higher bounce rates, lower conversion rates, and diminished SEO performance, making continuous optimization a non-negotiable aspect of plugin development.
Historically, Yoast has demonstrated a proactive approach to performance, evident in past initiatives such as significant improvements to its database system. These efforts reflect an ongoing process of identifying and addressing performance bottlenecks, ensuring that the plugin remains a robust and reliable tool for SEO practitioners. The 27.8 release is the latest outcome of such a targeted review, focusing on features that presented the most significant headroom for optimization when operating at scale. Developers meticulously reworked these components to be leaner and faster, implementing a range of best practices from modifying database queries to reducing unnecessary operations in the WordPress administration interface.
Targeted Optimizations: A Deep Dive into Yoast SEO 27.8 Improvements
The 27.8 release introduces several key optimizations, each designed to tackle specific performance issues that become pronounced on larger sites. These technical improvements collectively contribute to a smoother user and developer experience within the Yoast SEO plugin.
Significantly Reduced Loading Times for the Root Sitemap on Sites with Many Users
One of the most impactful changes in Yoast SEO 27.8 addresses the loading times of the root sitemap, particularly on websites with a large user base. Sitemaps are fundamental for SEO, providing search engines with a roadmap of a website’s content. For Yoast SEO to accurately calculate the "Last Modified" value of the author sitemap, a critical piece of information for search engine crawlers, it traditionally queried the usermeta table for all users eligible for inclusion.
The previous method for determining eligible users involved checking user capabilities, specifically using the 'capability' => ['edit_posts'] argument within the get_users() call. This approach, while functionally correct, generated an extremely heavy database query. The resulting SQL query often included multiple LIKE '%...%' clauses for various user roles (e.g., administrator, editor, author, contributor), combined with multiple JOIN operations. A typical clause looked like:
AND ((((mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"edit\_posts"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"administrator"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"editor"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"author"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"contributor"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"wpseo\_manager"%')
OR (mt1.meta_key = 'wp_capabilities'
AND mt1.meta_value LIKE '%"wpseo\_editor"%'))))The critical flaw in this approach was the use of LIKE '%...%'. MySQL’s B-tree indexes cannot be utilized when a wildcard (%) precedes the search string. This forces the database to perform a full table scan, reading every matching wp_capabilities row and executing seven substring scans on the serialized PHP meta_value per row. For sites with millions of users, this operation could take an exorbitant amount of time, sometimes hundreds of seconds, effectively stalling the rendering of the root sitemap.
The Yoast team addressed this by modifying the calculation to identify users with published posts, leveraging the 'has_published_posts' => true argument. This seemingly minor change drastically alters the resulting database query, allowing it to utilize indexes efficiently. The impact of this optimization is profound: in internal tests on a site with approximately two million users, the time required for the query to complete — and thus for the root sitemap to render — plummeted from over 300 seconds to a mere 25 milliseconds. This represents an improvement of over 12,000 times, translating directly into significantly faster sitemap generation and improved crawlability for large websites. Crucially, since the 'has_published_posts' => true argument was already incorporated in a later stage of sitemap generation, this change maintains the feature’s accuracy without negative functional impact.
Reduced Loading Times for the Author Sitemap on Sites with Many Users
Complementing the root sitemap optimization, Yoast SEO 27.8 also improves the performance of author sitemaps. While calculating eligible users for these sitemaps, the plugin previously included a meta query to check if each user’s user_level was greater than 0. This practice was a remnant of an older WordPress framework, as the user_level system was officially deprecated by WordPress core in version 3.0, released in 2010.
Although this deprecated check didn’t cause errors in the sitemap feature, it unnecessarily introduced an INNER JOIN into the database query. On sites with exceptionally large user and usermeta tables, this extra join, with no functional purpose, degraded performance. The specific clause looked like:
INNER JOIN wp_usermeta AS mt1 ON wp_users.ID = mt1.user_id
...
AND ( mt1.meta_key = 'wp_user_level' AND mt1.meta_value != '0' )By removing this outdated and superfluous JOIN, Yoast developers streamlined the query, enhancing the efficiency of author sitemap generation. Given the long-standing deprecation of the user_level framework, the decision to drop support for it was made deliberately, with minimal disruption expected. This optimization further contributes to faster sitemap loading, especially beneficial for content-heavy sites with many contributing authors.
Preventing Unnecessary Expensive Database Queries in Admin Pages
The WordPress administration area is where site owners and content creators spend significant time. Any slowdowns in this environment can severely impact productivity. Yoast SEO previously ran a daily database query in the backend to notify administrators about pending actions required for optimal site data indexing within its internal storage. On large sites, this query could take several seconds, periodically slowing down the rendering of admin pages.
The function Limited_Indexing_Action_Interface::get_limited_unindexed_count() was responsible for executing complex queries such as:
SELECT Count(P.id)
FROM wp_posts AS P
WHERE P.post_type IN ( 'post', 'page' )
AND P.post_status NOT IN ( 'auto-draft' )
AND P.id NOT IN (SELECT I.object_id
FROM wp_yoast_indexable AS I
WHERE I.object_type = 'post'
AND I.version = 2)These queries, designed to identify unindexed content, were running daily, and on very busy sites with multiple concurrent users, potentially every 15 minutes. Yoast developers re-engineered the logic responsible for this notification. The heavy query is now executed only once, at the initial detection that such a notification is necessary. The results are then cached, leveraging existing cache invalidation mechanisms that were previously underutilized. This change drastically reduces the frequency of these resource-intensive queries from daily or even more often, to a single execution in most site lifecycles, leading to a much snappier and more responsive admin experience.
Optimizing Expensive Database Queries in Admin Pages
Beyond preventing unnecessary query executions, Yoast SEO 27.8 also refined the query itself for identifying unindexed content. This improvement directly benefits the SEO optimization tool, making it significantly faster on sites with a large number of posts.
The original query structure used AND P.ID NOT IN (SELECT I.object_id FROM wp_yoast_indexable AS I WHERE I.object_type = 'post'). While functional, the NOT IN (subquery) clause can be inefficient, as it often forces MySQL to build the entire list of object_ids from the subquery before filtering the main query.
The optimized query now uses AND NOT EXISTS (SELECT 1 FROM wp_yoast_indexable AS I WHERE I.object_id = P.ID AND I.object_type = 'post'). The NOT EXISTS clause is generally more performant because it can "short-circuit" as soon as a matching row is found in the subquery for each row in the main query. This means it doesn’t need to build a full list of IDs, leading to considerably faster execution times on sites with thousands or even millions of posts. This subtle yet powerful change accelerates the backend tools that rely on this data, improving the overall efficiency of SEO management.
Reducing Roundtrips to the Database
Database roundtrips are inherently expensive operations, incurring latency and resource consumption with each interaction between the application and the database server. A common anti-pattern, often referred to as the "N+1 query problem," involves executing multiple sequential SELECT queries where a single batched query could suffice.
Yoast’s performance review identified instances where data for multiple posts was retrieved through sequential SELECT queries. For example, a code snippet might have looked like this:
$indexables = [];
foreach ( $post_ids as $post_id )
$indexables[] = $this->repository->find_by_id_and_type( (int) $post_id, 'post' );
This approach would perform one SELECT query for each post ID, resulting in ‘N’ queries for ‘N’ posts. The development team refactored such instances to consolidate these operations into a single batched SELECT query:
$indexables = $this->repository->find_by_multiple_ids_and_type(
array_map( 'intval', $post_ids ),
'post',
);This change transforms 1,000 individual SELECT queries (each yielding a maximum of one row) into a single SELECT query that yields up to 1,000 rows. While ensuring that the number of posts requested in a single batch does not exceed MySQL’s usage limits, this optimization dramatically reduces database load. For a chunk of 1,000 posts, this translates to saving 999 roundtrips for operations such as parts of the SEO optimization process or the output of the schema aggregation feature. Such efficiency gains are critical for maintaining responsiveness on large content archives.
Improving Post Editor Performance by Preventing Unnecessary Re-renders
Modern web applications, especially those built with frameworks like React (which powers the WordPress Block Editor), rely on efficient rendering cycles. In the WordPress editor, Yoast’s sidebar panels update whenever the data they retrieve from the Redux store appears to have changed. However, "appears to have changed" is often determined by JavaScript’s strict equality comparison (===), which checks for reference equality, not value equality.
This meant that if a selector returned an object literal like items: ['foo'] which was functionally identical to the previous state but was a freshly created object in memory, React would perceive it as a new object and trigger an unnecessary re-render of the panel. When combined with a busy editor dispatching state updates on every keystroke, this led to Yoast panels re-rendering constantly without any actual change in their displayed content.
With the 27.8 release, Yoast developers identified and patched multiple instances where such functionally unchanged data was triggering these superfluous re-renders. By ensuring that selectors return stable references when the underlying data has not truly changed, the post editor integration of Yoast SEO is now significantly more robust and performant. This optimization results in a smoother, more responsive editing experience, reducing perceived lag and improving the overall usability for content creators.
Implications and Future Outlook
The release of Yoast SEO 27.8 represents a significant milestone in the plugin’s ongoing evolution. By targeting critical performance bottlenecks, particularly on large-scale WordPress installations, Yoast has not only improved the efficiency of its software but also reinforced its commitment to the broader WordPress ecosystem. Faster sitemap generation means better crawlability and potentially faster indexing for search engines. A more responsive admin area enhances productivity for site administrators and content managers. And a smoother post editor experience directly benefits the creative process.
These optimizations are crucial as websites continue to grow in complexity and scale. They demonstrate a deep understanding of WordPress’s underlying architecture and the nuances of database interaction, a testament to the expertise of Yoast’s development team, including senior developer Leonidas Milosis, who is deeply involved in performance and sustainability in software development.
Looking ahead, the continuous pursuit of performance excellence remains a core tenet for Yoast. The company’s proactive approach to identifying and resolving performance challenges ensures that Yoast SEO continues to be a leading, reliable, and efficient tool for optimizing websites for search engines, regardless of their size or complexity. This commitment benefits not only direct users of the plugin but also contributes to the overall health and speed of the WordPress platform.
