Jonny Harris, Author at Spacedmonkey

Enhancing WP_Query Performance in WordPress

Jonny Harris

14/04/2025
WP_Query is a powerful tool for fetching posts in WordPress. However, if you don’t carefully configure your queries, they can quickly become inefficient, particularly on larger sites. Whether you’re working on a high-traffic website, a REST API endpoint, or an Ajax-powered interface, the way you configure WP_Query can make a significant difference in performance.

In this post, we’ll walk through key parameters you can use to improve the speed of your queries, reduce memory consumption, and optimise WordPress’s database interactions.

Key Parameters for Improving WP_Query Performance

1. posts_per_page

The posts_per_page parameter directly controls the number of posts returned by the query. If you only need one post, set posts_per_page to 1 to reduce unnecessary load.
```
$query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 1,
]);Code language: PHP (php)
```
Best practices:
- Use 1 if you only need a single post.
- Keep result sets under 100 posts unless paginating or processing in batches.
- Avoid -1 (to get all posts), as this can quickly consume memory on larger sites.
2. no_found_rows

By default, WordPress calculates the total number of matching posts for a query. This is useful when you’re paginating results, but if you don’t need pagination, you can disable this calculation.
```
$query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 10,
    'no_found_rows'  => true,
]);Code language: PHP (php)
```
Use when: You don’t need pagination, such as on homepage widgets or API responses.

3. ignore_sticky_posts

Sticky posts are displayed at the top of a list of posts, which adds extra complexity to the query. If sticky posts aren’t important for your use case, you can tell WordPress to ignore them.
```
$query = new WP_Query([
    'post_type'           => 'post',
    'posts_per_page'      => 10,
    'ignore_sticky_posts' => true,
]);Code language: PHP (php)
```
Use when: You don’t need sticky posts interfering with your query, such as in custom feeds or filtered post lists.

4. update_post_meta_cache, update_post_term_cache, and update_menu_item_cache

These parameters control whether WordPress preloads associated metadata, taxonomy terms, and menu item data for each post. If you’re not using these features, disabling them can save memory and improve query speed.
```
$query = new WP_Query([
    'post_type'               => 'post',
    'posts_per_page'          => 10,
    'update_post_meta_cache'  => false,
    'update_post_term_cache'  => false,
    'update_menu_item_cache'  => false,
]);Code language: PHP (php)
```
Use when: You’re only displaying basic post data (like IDs or titles) or intend to fetch metadata or terms later.

⚠️ Important: update_menu_item_cache should only be enabled when querying nav_menu_item post types. For other post types, leave it disabled to avoid unnecessary overhead.

5. fields

The fields parameter controls which parts of the WP_Post object are returned. If you only need specific data (e.g., just the post IDs), setting this to ‘ids’ can reduce memory usage and improve performance.
```
$query = new WP_Query([
    'post_type' => 'post',
    'fields'    => 'ids',
]);Code language: PHP (php)
```
Options:
- ‘all’ – Returns full post objects (default).
- ‘ids’ – Returns an array of post IDs.
- ‘id=>parent’ – Returns an associative array of IDs and their parent IDs.
Use ‘ids’ or ‘id=>parent’ when you don’t need the full post object, such as for bulk processing.

6. cache_results (Use with Caution)

This parameter controls whether the query results are cached. Although disabling query caching might seem like a performance boost, it’s generally not recommended, especially since WordPress 6.1 introduced enhanced query caching.
```
$query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 10,
    // cache_results => true (default)
]);Code language: PHP (php)
```
Avoid setting to false unless you’re running batch scripts or WP-CLI commands where query reuse isn’t needed. In normal requests, leaving cache_results enabled is generally the best approach as it reduces repeated database hits.

See: WordPress 6.1 Query Caching Improvements

7. orderby => ‘rand’

Using orderby => ‘rand’ is tempting for displaying random posts, but it’s highly inefficient, particularly on large datasets.
```
$query = new WP_Query([
    'post_type'      => 'post',
    'posts_per_page' => 5,
    'orderby'        => 'rand', // ⚠️ Expensive and not cacheable
]);Code language: PHP (php)
```
Why it’s problematic:
- Not cacheable – Since the result changes every time, caching plugins can’t reuse it.
- Slow at scale – ORDER BY RAND() is inefficient on large databases, requiring a random number for every row.
- Increases load – It adds extra stress to your database.
Alternatives:
- Cache random results in a transient.
- Shuffle post IDs in PHP after performing a normal query.
- Use custom meta values to rotate content.
8. suppress_filters => false

The suppress_filters parameter disables all filters on a query, including important ones for caching and other plugin integrations. This can severely impact performance, particularly if you’re using caching plugins or multilingual tools.
```
$query = new WP_Query([
    'post_type'        => 'post',
    'posts_per_page'   => 10,
    'suppress_filters' => true, // ⚠️ Not recommended
]);Code language: PHP (php)
```
Why you should avoid it:
- Breaks caching plugins (e.g., Redis, Memcached) that rely on query filters.
- Disables multilingual plugins like WPML or Polylang, which rely on query hooks.
- Disables other performance enhancements or custom behaviour (e.g., SEO filters, membership-based content filtering).
Instead, use get_posts(), which does not require disabling filters and is generally a safer option for simpler queries.

9. meta_query Without Indexing

Using meta_query to filter posts based on custom fields can be very slow if the meta_key is not indexed. For large datasets, queries on non-indexed meta fields can drastically reduce performance.
```
$query = new WP_Query([
    'post_type'  => 'post',
    'meta_query' => [
        [
            'key'     => 'custom_field_key',
            'value'   => 'some_value',
            'compare' => '='
        ]
    ],
]);Code language: PHP (php)
```
Why it can be problematic:
- No indexes on meta_key or meta_value can cause slow queries, particularly on large datasets.
- Poor performance as WordPress must scan the postmeta table for every query.
What to do:
- Index your meta keys to improve query performance.
- Avoid LIKE queries, which are slower than exact matches.
- Consider custom tables for high-volume metadata.
10. Faster Taxonomy Queries with term_taxonomy_id

If you’re querying posts by taxonomy, you can optimise performance by querying by term_taxonomy_id directly. This avoids unnecessary joins and can significantly speed up the query.
```
$query = new WP_Query([
    'tax_query' => [
        [
            'taxonomy'         => 'category',
            'field'            => 'term_taxonomy_id',
            'terms'            => [23, 47],
            'include_children' => false,
        ],
    ],
]);Code language: PHP (php)
```
Why this improves performance:
- Avoids extra SQL joins and lookups in the terms and term_taxonomy tables.
- Reduces complexity in the SQL query and improves speed, especially with large datasets.
11. Optimising Queries with post__in

When using the post__in parameter to query a specific set of posts by their post IDs, you can improve performance by setting the posts_per_page parameter to match the count of the post IDs array.
```
$post_ids = [1, 2, 3, 4, 5]; // Array of post IDs

$query = new WP_Query([
    'post_type'      => 'post',
    'post__in'       => $post_ids,
    'posts_per_page' => count( $post_ids ), // Match posts_per_page with array length
]);Code language: PHP (php)
```
Why this improves performance:
- Setting posts_per_page to the count of the post ID array ensures the query doesn’t needlessly paginate or fetch extra posts.
- It optimises the query to exactly match the requested set of posts, reducing unnecessary overhead.
12. Use get_post() Instead of WP_Query for Single Posts

If you already have the post ID and only need to retrieve one post, you can bypass WP_Query entirely and use the simpler and more efficient get_post() function.
```
$post = get_post( 123 ); // Retrieve post by IDCode language: PHP (php)
```
Why it’s better:
- get_post() is much faster than WP_Query when you’re only querying one post by its ID.
- It avoids the overhead of running a full query and retrieving unnecessary data, making it ideal for scenarios like displaying a single post or working with a post ID that has already been determined.
Conclusion

Optimising WP_Query isn’t just about writing fast queries — it’s about writing efficient queries that avoid unnecessary database operations, reduce memory usage, and integrate well with caching mechanisms.

By making thoughtful decisions around parameters like no_found_rows, ignore_sticky_posts, and meta_query, you can dramatically improve performance on your site. Avoiding common pitfalls like orderby => ‘rand’ and suppress_filters => true will also help ensure your queries are both fast and compatible with caching layers and plugin integrations.
Optimising WP_User_Query Performance: Lazy Loading, Query Caching, and Memory Efficiency in WordPress

Jonny Harris

26/03/2025
When working with WordPress sites that have a large number of users—especially in Multisite environments or setups that heavily rely on user meta—you may have noticed significant performance issues when querying users.

The primary reason for this is how WordPress loads user data:

• WP_User_Query retrieves user data from the database.

• Each user is instantiated as a WP_User object, which automatically loads all user meta and capability data into memory.

• If your site has extensive user meta, this leads to high memory usage and slow performance.

Thankfully, WordPress Core has introduced query caching in WP_User_Query, and there are proposals for lazy loading user meta and capability data. These improvements will make user queries significantly faster and more efficient.

The Problem: WP_User_Query Loads Too Much Data

When you use WP_User_Query, WordPress loads not just the basic user fields (like ID, user_email), but also:

• All user meta (even if you don’t need it)

• User capabilities (used for role-based permissions)

Example: Standard WP_User_Query Usage
```
$query = new WP_User_Query([
    'role'   => 'subscriber',
    'number' => 50,
]);

$users = $query->get_results();

foreach ($users as $user) {
    echo $user->user_email;
}
Code language: PHP (php)
```
Problem: Even though we only need user_email, this query loads all user meta and capability data for every user, consuming unnecessary memory.

The Solution: Lazy Loading User Meta and Capabilities

WordPress Core is working on two major improvements to solve this:

Lazy Loading User Meta (Ticket #63021)

Currently, WP_User loads all user meta when instantiated. The proposed fix will defer this process, so metadata is only loaded when accessed.

This would reduce memory usage and improve query performance, especially for sites with extensive user meta.

Lazy Loading Capability Data (Ticket #58001)

Similar to user meta, capability data (stored in wp_usermeta) is often loaded even when it’s not needed. A proposed fix would make capabilities load only when requested, reducing unnecessary database queries.

WP_User_Query Query Caching (Introduced in WordPress 6.3)

Another major improvement is query caching in WP_User_Query, introduced in WordPress 6.3.

How Query Caching Works

• When a WP_User_Query is executed, the results are cached.

• Subsequent queries with the same parameters retrieve data from the cache instead of running a new database query.

• This significantly reduces database load and improves performance, especially for high-traffic sites.

Example: Default Query Caching
```
$args = [
    'role'   => 'subscriber',
    'number' => 50,
];

$query = new WP_User_Query($args); // Query results are cached
Code language: PHP (php)
```
Disabling Query Caching

If you need fresh data for a specific query, you can disable caching using cache_results => false:
```
$args = [
    'number'        => 50,
    'cache_results' => false, // Force a fresh query
];

$query = new WP_User_Query($args);
Code language: PHP (php)
```
Benefits of Query Caching

✅ Reduces Database Queries – Frequent user queries no longer hit the database.

✅ Improves Page Load Speed – Cached queries are retrieved instantly.

✅ Enhances WordPress Scalability – Essential for high-user and Multisite environments.

Should You Use Direct Queries Instead?

Instead of WP_User_Query, some developers use direct database queries for performance. Is this a good idea?

Recommended Approach: Use WP_User_Query with the fields Parameter

Rather than fetching full user objects, limit the fields retrieved:
```
$query = new WP_User_Query([
    'role'   => 'subscriber',
    'number' => 50,
    'fields' => ['ID', 'user_email'], // Only fetch needed fields
]);

$users = $query->get_results();
Code language: PHP (php)
```
✅ Avoids loading unnecessary user meta and capabilities

✅ Still benefits from WordPress query caching

When to Use Direct Queries ($wpdb->get_results())

A direct query may be useful if:

• You need only a few fields and don’t want WP_User overhead.

• You need an aggregated result (e.g., counting users).

• You’re running a custom, high-performance query.

Example: Fetching user IDs and emails directly:
```
global $wpdb;
$users = $wpdb->get_results("SELECT ID, user_email FROM {$wpdb->users} WHERE user_status = 0");

foreach ($users as $user) {
    echo $user->user_email;
}
Code language: PHP (php)
```
❌ Bypasses WordPress caching and hooks

✅ Fastest method when WordPress overhead isn’t needed

Best Practice:

• Use WP_User_Query with fields when possible.

• Use $wpdb->get_results() only when you need full control over queries.

Summary: How to Optimise WP_User_Query Performance

✅ Use Query Caching (Enabled by Default in WP 6.3)

• WordPress now caches WP_User_Query results automatically.

• This reduces database load and speeds up user queries.

✅ Limit Fields in WP_User_Query

• Use ‘fields’ => [‘ID’, ‘user_email’] to avoid unnecessary data.

✅ Lazy Loading for User Meta and Capabilities (Coming Soon!)

• WordPress Core is working on making user meta and capabilities load only when accessed.

✅ Use Direct Queries Only When Necessary

• If you don’t need WordPress hooks/caching, $wpdb->get_results() is an option.

Final Thoughts

These improvements—query caching and lazy loading—will make WordPress more efficient, especially for large user-heavy sites and Multisite installations.

By applying these best practices, you can:

✅ Reduce memory usage

✅ Improve page speed

✅ Lower database queries

Want to test these improvements? Keep an eye on the WordPress Core development tickets for when lazy loading gets merged!
Embracing the WordPress Community: A Year of Growth and Gratitude

Jonny Harris

20/12/2023
As the sun sets on 2023, I find myself reflecting on a year filled with growth, learning, and immense gratitude. This past year has been a journey like no other, all thanks to the incredible WordPress community that has supported me every step of the way. I’ve delved into the heart of WordPress, contributed to its core, and immersed myself in a world where passion and collaboration intersect. Today, I want to share my love for the WordPress community and express my excitement for the promising year that lies ahead.

A Year of Support and Learning

The WordPress community is a vibrant and diverse ecosystem, made up of passionate individuals who share a common love for open-source development, content creation, and innovation. Over the past twelve months, this community has become my second family, guiding me through challenges, celebrating victories, and fostering an environment of continuous learning.

From troubleshooting code to brainstorming creative solutions, the WordPress community has been my go-to resource for support. Whether on forums, social media, or at WordCamps, the willingness of fellow enthusiasts to lend a helping hand has been both inspiring and humbling. It’s this spirit of collaboration that makes the WordPress community truly exceptional.

A Dedication to Favorites

In the photograph above, you’ll find a visual representation of my journey and the things I hold dear. This Christmas decoration was made my wife. At the center of this dedication is the adorable Wapuu, the unofficial mascot and symbol of WordCamps. Wapuu represents not just a cute character but a sense of belonging and camaraderie within the community.

A Proud Contributor to WordPress Core

One of the highlights of my year has been contributing to the WordPress core. Working on the backbone of this powerful platform has been both challenging and immensely rewarding. It’s a privilege to be part of a global effort that shapes the future of WordPress, and I take pride in knowing that my contributions have played a small role in its evolution.

The sense of accomplishment that comes with seeing your code integrated into the core is indescribable. It’s a testament to the collaborative nature of the WordPress project, where individual efforts come together to create something truly remarkable.

Anticipating a Bigger 2024

As we stand on the brink of a new year, there’s an undeniable sense of excitement and anticipation within the WordPress community. 2023 has seen significant milestones, with updates, improvements, and a collective commitment to pushing boundaries. Looking ahead, 2024 promises to be even bigger – a year of innovation, community engagement, and continued growth.

More reading
Reviving the WordPress OAuth1 Plugin

Jonny Harris

18/12/2023
The WordPress landscape is ever-evolving, and as technology advances, plugins that once thrived can fall by the wayside. One such plugin, the WordPress OAuth1 plugin, has been in need of attention, having last seen an update in March 2017. In this blog post, I’m excited to announce the release of the latest version, 0.4.3, breathing new life into this essential tool for secure authentication.

Maintenance Releases: Versions 0.4.0 to 0.4.3

The latest release comprises maintenance updates focused on addressing long-standing issues, improving compatibility, and aligning with contemporary coding standards. Here are the key enhancements:

Updated Coding Standards:
- Transition to WordPress Core Coding Standard 3.0.1.
- Adherence to WordPress VIP GO coding standards.
Improved Composer Setup:
- Streamlined and enhanced composer setup for a smoother developer experience.
Support for PHP 8.0+:
- The plugin now fully supports PHP 8.0 and later versions.
PATCH Method Support:
- A comprehensive list of allowed HTTP methods now includes PATCH.
Compatibility Improvements:
- Updates ensuring seamless integration with newer WordPress versions.
New CLI Command:
- Introducing a CLI command for deleting OAuth1 Applications, enhancing control and management.
Commitment to Future Maintenance:

While there are no new releases currently planned, going forward, I plan to maintain the plugin and ensure bugs are patched. Regular updates will be provided to keep this authentication tool reliable and secure, meeting the evolving needs of WordPress users.

Plugin Updates:

The WordPress OAuth1 plugin has been updated on both the WordPress Plugin Repository and GitHub. You can download the latest version (0.4.3) from the following links:
- WordPress Plugin Repository
- GitHub Repository
Leaving XWP, but Not WordPress: A Brief Respite

Jonny Harris

09/10/2023

After four incredible years at XWP, the time has come for me to take a step back from the WordPress open source community. It’s a decision that I didn’t take lightly, but one I believe is necessary for my personal and professional growth. Before I embark on this brief hiatus, I want to take a moment to reflect on the amazing journey I’ve had and reassure you that I’ll be back.

When I first joined XWP, I was passionate about WordPress and its open-source ethos. Little did I know that this company would provide me with the opportunity to work on exciting projects, collaborate with brilliant minds, and contribute to a platform that powers a significant portion of the web. Over these four years, I’ve grown both as a developer and as a member of a community that is second to none.

During this time, I had the privilege of collaborating with giants in the tech world. Working with Google on Web Stories was an experience that expanded my horizons and allowed me to contribute to cutting-edge web technologies. The creativity and innovation that went into the Web Stories project were truly inspiring, and I’m grateful for the opportunity to have been a part of it.

Additionally, my involvement with Unsplash added a unique dimension to my journey. Unsplash’s mission to make high-quality visuals accessible to all resonated with me deeply, and I’m proud to have played a role in their integration with WordPress. It’s a testament to the power of open source that allows us to create seamless connections between diverse platforms and communities.

Now, you might be wondering why I’m stepping away for a while. Rest assured, this isn’t a farewell; it’s a pause to recharge and explore new horizons. Sometimes, we all need to step back from what we love to gain fresh perspectives and come back even stronger. During this break, I plan to dive into different projects, expand my skillset, and find new inspiration that I can bring back to the WordPress community.

I want to express my deepest gratitude to everyone at XWP, my fellow contributors, and the entire WordPress community for the support, guidance, and camaraderie I’ve experienced over these four years. It’s been an amazing ride, and I’m excited to see how the community continues to evolve.

Rest assured, I’ll be back. WordPress has become an integral part of my journey, and I can’t stay away for long. I’ll return with renewed energy and fresh ideas to contribute to the platform we all hold dear.

Thank you for being a part of this incredible journey with me. Until we meet again in the WordPress world, stay inspired, keep coding, and never stop pushing the boundaries of what’s possible with open source technology.

See you soon!
Improve front end performance with just one line of PHP

Jonny Harris

29/06/2023
While working on WordPress core, I discovered a pretty amazing function: wp_maybe_inline_styles. This function hooks into the style enqueueing process in WordPress. Instead of outputting a <link> tag with an href attribute to a url of a CSS file, which when rendered in the browser requires a blocking HTTP request to get the CSS file and slows down front-end performance, this function inlines the styles. It reads the file into memory and outputs it as an inline <style> tag in the header/footer of your site. This means no external requests, allowing the browser to render your page much faster.

This functionality was added to support block styles. Many block stylesheets can be extremely small. Some core block stylesheets consist of only a few lines even after minification. If you are already using register_block_type_from_metadata to render your blocks, then you are already opted into this functionality. However, this functionality can be used for any stylesheet you use in WordPress, but you have to opt-in. To opt-in, it is as simple as this:
```
wp_style_add_data( $style_handle, 'path', $path );
Code language: PHP (php)
```
The $style_handle need to be handle used for the style and $path is the full path to the CSS file.

It only gets a little bit more complex if you have right-to-left stylesheets as well. But adding support for this is as simple as adding the following lines:
```
$rtl_file = str_replace( "{$suffix}.css", "-rtl{$suffix}.css", $path );

if ( is_rtl() && file_exists( $rtl_file ) ) {
	wp_style_add_data( $style_handle, 'path', $rtl_file );
}Code language: PHP (php)
```
This is so simple that I added it to my own sites with a commit like this. I have also added it to Jetpack blocks with my pull request here.

One thing to note is that there is a limit to the size of the CSS that can be output. The code has a limit of 20,000 bytes of CSS. This is to prevent extremely large CSS files, like a 10KB file, from being output inline. This functionality is really designed for smaller CSS files. However, if you know what you are doing, there is a filter to adjust the size limit using a filter called styles_inline_size_limit.

Why using this functionality? It is possible to do this yourself using file_get_contents and inline styles. Like the following code snippet.
```
wp_register_style( $style_handle, false );
wp_add_inline_style( $style_handle, file_get_contents( $path ) );Code language: PHP (php)
```
But loading the contents of a CSS file into PHP on every page request is really bad for PHP performance and server response time. What wp_maybe_inline_styles does is only load the CSS into memory if the stylesheet is used on the page. This means page loads like REST API or admin screens will not load the CSS into memory.

Just for a bit of fun, I turned this functionality off for block styles. Here is the before and after on Lighthouse.

With inline styles.

Without inline styles.
Making WordPress Core faster

Jonny Harris

02/05/2023

I had the chance to talk to Remkus De Vries on his podcast to talk about WordPress performance. This was recorded a while ago ( which is why I am wearing a christmas jumper ). Remkus is really doing great things and if you are not already following on twitter ( @remkusdevries ) or subscribe to his newsletter.
New role

Jonny Harris

06/02/2023

Today, I am happy to annouce that I will working full time on the WordPress core performance project. I will be sponsored by XWP to work full time on work on WordPress core performance project and will be working closing with the Google and 10up teams.

Working on open source full time, has been a dream of mine for years. With this full time commitment, it means I can take on bigger core performance tasks and really try to move the neddle in terms of performance. My first day and is 1st of March. I will keep you updated via this blogs and social media.

I would like to thank everyone that reached out to support and help me with interview offers. I was blown away by the response I got from the last blog post. The WordPress community is the best and there is a reason why I love it soo much.
REST API Performance with Jonny Harris

Jonny Harris

03/02/2023

I am on this month’s Headless WP Podcast. We talk about performance, scaling and the REST API. Really interesting conversion.

Listen to the podcast
Improve WP_Query performance if using external object cache

Jonny Harris

17/01/2023
Are you using an external object cache, like Memcache or Redis? Is so, there is a little one line piece of code that can improve the performance of WP_Query and performance in general on your site.
```
add_filter( 'split_the_query', 'wp_using_ext_object_cache' );

Code language: JavaScript (javascript)
```
Why does this improve performance? See these lines in WordPress core. The filter split_the_query determinants if the database query in WP_Query should get posts by ID or load the whole post object. If the post is loaded by ID, it loads the whole post object by checking the cache and is not in the cache, calling _prime_post_caches. In the case of site using an external object cache, the query should always just load the IDs, as the post object will 99.999% of the time, be in object cache already. This filter forces posts to be loaded from object cache and makes the database query simplier ( by only loading the ID). This filter is place for backwards compatibility reasons so it safe to use if you know what you are doing, but I don’t see many people using it. The above line can be put anywhere in your code, but I would recommend adding to to a mu-plugin.
Looking for a new role

Jonny Harris

20/12/2022

I am sad to announce that XWP has not renewed my contract as of the end of January. This news came as a shock to me and many of my fellow XWP team members that received the news last week. I am currently in the process of looking for my next role in the WordPress space. If you are interested in working with me, do not hesitate to reach out on my contact form, via twitter or linkedin. I am looking for contract roles, freelance or consultancy work. I am proficient in PHP, Javascript ( react / typescript ) and Gutenberg. Looking for a role where I used my skills in WordPress at scale, multisite, the REST API and gutenberg, to work on large scale WordPress projects.

What this also means is that XWP is no longer sponsoring me to work on WordPress core. Without XWP’s support here, I will no longer be able to commit the 15 hours a week I currently work on WordPress core and other related open source projects. This will sadly mean that work on the WordPress performance project will slow ( or stop ), while I work on securing new sponsors. If you are interested in sponsoring me or help me to get sponsored, then reach out or consider sponsoring me on Github.

I will be attending WordCamp Asia in February 2023. For anyone interested in talking, that might be a great place to meet face to face.

I would like to take the opportunity to thank XWP. It has been my home for 3 and half years. The community at XWP has been amazing to be part of and I have valued every second I worked there. I hope to keep strong ties with the XWP and the XWP community for many years to come.
Live stream: WordPress Performance Team: year 1

Jonny Harris

18/12/2022

I am going to be involved in a live stream, where we talk about the first year of contributing to the WordPress performance project. Check it out.

🔗: https://twitter.com/i/spaces/1yNGaNlkBORJj?s=20
📆: Monday Dec 19
⏰: 2p EST
5 Reasons WordPress 6.1 is a Release Like No Other

Jonny Harris

10/11/2022

5 Reasons WordPress 6.1 is a Release Like No Other
Noteworthy Contributor in WordPress 6.1

Jonny Harris

02/11/2022

I am super proud to have noted as a noteworthy contributor. It is such an honour to be featured in this list with such great people.

This was a really big release for me, getting many very long standing ticket merged into core, like adding caching to WP_Query. I worked really hard on performance, even finding last minute performance issues at 1am in the morning.

Was up until 1am last night tracking down a very serious performance issue in WordPress 6.1 RC2. Finally found it with the help of @blackfireio. I was up at 8am, answering questions about it and helping out. Oh boy am I tired today. Send cookies and caffeinated drinks.
— Jonny Harris (@thespacedmonkey) October 20, 2022

The performance improves to WordPress are notable. See these comparisons.

WordPress 5.9 – 2022 theme

WordPress 6.0 – 2022 Theme

WordPress 6.1 – 2022 Theme

If you are interested in some of the work, that I did as part of the WordPress 6.1 release, you can see the dev notes I wrote on the make WordPress Blog. If you are interested in sponsoring my work, this can be done on gitbub sponsor page.

Improvements to WP_Query performance in 6.1

Multisite improvements in WordPress 6.1

Performance improvements to the REST API
Improvements to WP_Query performance in 6.1

Jonny Harris

10/10/2022

Improvements to WP_Query performance in 6.1
Proposal: Add a dominant color background to images.

Jonny Harris

25/07/2022

Proposal: Add a dominant color background to images.