Title: Hallway Hangout: Performance End of Year Review 2023 Author: Emily Clarke Published: November 30, 2023 Last modified: December 8, 2023 --- [ ](https://profiles.wordpress.org/clarkeemily/) [Emily Clarke](https://profiles.wordpress.org/clarkeemily/) 11:45 am _on_ November 30, 2023 Tags: [core-performance ( 152 )](https://make.wordpress.org/core/tag/core-performance/), [hallwayhangout ( 15 )](https://make.wordpress.org/core/tag/hallwayhangout/), [performance ( 419 )](https://make.wordpress.org/core/tag/performance/) # Hallway Hangout: Performance End of Year Review 2023 Following up on the prior performance related [hallway hangout for WordPress 6.3](https://make.wordpress.org/core/2023/06/29/hallway-hangout-performance-improvements-for-wordpress-6-3/), and [hallway hangout for WordPress 6.4](https://make.wordpress.org/core/2023/09/18/hallway-hangout-performance-improvements-for-wordpress-6-4/), [@flixos90](https://profiles.wordpress.org/flixos90/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) and [@clarkeemily](https://profiles.wordpress.org/clarkeemily/) co-hosted an end of year hallway hangout to review the WordPress performance enhancements from 2023, and a look ahead to 2024! **The Hallway Hangout took place at [2023-12-07 16:00](https://www.timeanddate.com/worldclock/fixedtime.html?iso=20231207T1600) and the Zoom link was shared in the [#core-performance](https://wordpress.slack.com/archives/C02KGN5K076) SlackSlack Slack is a Collaborative Group Chat Platform [https://slack.com/](https://slack.com/). The WordPress community has its own Slack Channel at [https://make.wordpress.org/chat/](https://make.wordpress.org/chat/) channel before starting.** At a high level, we went through the following agenda: * Quick intros (what each person does/focuses on) * Review of WordPress performance improvements throughout 2023 * Retrospective sharing field data for the cumulative performance impact of the team’s work in 2023 * Discussion around interpretation of metrics * A look ahead to 2024 plans As a reminder, hallway hangouts are meant to be casual and collaborative so folks came prepared with a kind, curious mind along with any questions or items they wanted to discuss around this important area of the project, especially since the agenda was intentionally loose to allow for it. Noting this specifically for folks who expressed interest previously or who are involved directly in this work cc [@hellofromtonya](https://profiles.wordpress.org/hellofromtonya/) [@aristath](https://profiles.wordpress.org/aristath/) [@oandregal](https://profiles.wordpress.org/oandregal/) [@annezazu](https://profiles.wordpress.org/annezazu/) [@tweetythierry](https://profiles.wordpress.org/tweetythierry/) [@desrosj](https://profiles.wordpress.org/desrosj/) [@youknowriad](https://profiles.wordpress.org/youknowriad/) [@dmsnell](https://profiles.wordpress.org/dmsnell/) [@pbearne](https://profiles.wordpress.org/pbearne/) [@swissspidy](https://profiles.wordpress.org/swissspidy/) [@westonruter](https://profiles.wordpress.org/westonruter/) [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) [@mukesh27](https://profiles.wordpress.org/mukesh27/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@johnbillion](https://profiles.wordpress.org/johnbillion/) [@10upsimon](https://profiles.wordpress.org/10upsimon/) [@thekt12](https://profiles.wordpress.org/thekt12/) [@linsoftware](https://profiles.wordpress.org/linsoftware/) [@pereirinha](https://profiles.wordpress.org/pereirinha/) ### **Recording** ### **Attendees:** [@pbearne](https://profiles.wordpress.org/pbearne/) [@joemcgill](https://profiles.wordpress.org/joemcgill/) [@clarkeemily](https://profiles.wordpress.org/clarkeemily/) [@flixos90](https://profiles.wordpress.org/flixos90/) [@thekt12](https://profiles.wordpress.org/thekt12/) [@swissspidy](https://profiles.wordpress.org/swissspidy/) [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) [@westonruter](https://profiles.wordpress.org/westonruter/) ### **Notes** [@flixos90](https://profiles.wordpress.org/flixos90/) presented the [WordPress Performance 2023 CWV Impact Retrospective](https://docs.google.com/presentation/d/1iN2PL3yLvztEt3FYzI5eO7bLjUJL_5t-xsdGHNj7QLA/edit?usp=sharing) slide deck, thank you very much for pulling this together Felix. [[ _Please click the image above to view the slide deck_ ### **INP Discussion** [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) [@flixos90](https://profiles.wordpress.org/flixos90/) [@pbearne](https://profiles.wordpress.org/pbearne/) were discussing whether INP mobile scores are due to lower powered mobile devices. The team discussed whether there may be an answer we can find. Mobile passing rate is more of a problem with INP (high chance it’s because of low powered devices). It could be networknetwork( versus site, blog) conditions as well, but lower powered devices likely to be the cause. [@pbearne](https://profiles.wordpress.org/pbearne/) did raise: what would be the fix, low res images? How could we support under-powered devices? [@flixos90](https://profiles.wordpress.org/flixos90/) commented that for INP specifically it’s about JavaScriptJavaScript JavaScript or JS is an object-oriented computer programming language commonly used to create interactive effects within web browsers. WordPress makes extensive use of JS for a better user experience. While PHP is executed on the server, JS executes within a user’s browser. [https://www.javascript.com](https://www.javascript.com/). The amount, and how it’s executed, i.e. using a worker thread comes to mind that can improve INP. WordPress doesn’t have support for worker thread. This could be a good opportunity. More about the actual JSJS JavaScript, a web scripting language typically executed in the browser. Often used for advanced user interfaces and behaviors. code, reduction of JS code and optimizing JS code.  It was suggested that the PluginPlugin A plugin is a piece of software containing a group of functions that can be added to a WordPress website. They can extend functionality or add new features to your WordPress websites. WordPress plugins are written in the PHP programming language and integrate seamlessly with WordPress. These can be free in the WordPress.org Plugin Directory [https://wordpress.org/plugins/](https://wordpress.org/plugins/) or can be cost-based plugin from a third-party. Checker tool could help with? Are there any optimization tools to help here? General consensus is that folks are just not sure. [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) mentioned that it’s not just static analysis, these INP issues don’t tend to come up, it’s more in the field when there’s a lot of JS interacting on the page simultaneously. Complicated layouts also contribute to low INP, DOM layouts — but unsure if this is our problem. Maybe likely to be in the front end, themes. Also in the combination of things, animations, app providers, tracking etc, these things add up and compete for resources on a low powered device. [@westonruter](https://profiles.wordpress.org/westonruter/) shared How to diagnose slow INP in the lab:[ https://web.dev/articles/manually-diagnose-slow-interactions-in-the-lab](https://web.dev/articles/manually-diagnose-slow-interactions-in-the-lab). [@flixos90](https://profiles.wordpress.org/flixos90/) highlighted the Interactivity APIAPI An API or Application Programming Interface is a software intermediary that allows programs to interact with each other and share data in limited, clearly defined ways. (very new and not publicly available) this is the first WP coreCore Core is the set of software required to run WordPress. The Core Development Team builds WordPress. own JS API that is just starting to be rolled out. This would allow plugins to use an API allowed by core, htmlHTML HyperText Markup Language. The semantic scripting language primarily used for outputting content in web browsers. directives, could we improve INP through the interactivity API — great potential opportunity for the future. Static analysis in the plugin checker, could look to pointing plugin checker to interactivity API. Prevalence of cookie consent policies, are these contributing to low INP scores? The team feel this is potentially low hanging fruit as 90% of sites need one now. [@joemcgill](https://profiles.wordpress.org/joemcgill/) mentioned the tricky part here is the big services that provide cookie consent provide their own JS code to drop in the page, integrations would be more challenging. [@pbearne](https://profiles.wordpress.org/pbearne/) mentioned a simple basic one that works would be great. Could it be done in a way where you don’t get penalized in the stats. The team agree this is worth looking into. [@pbearne](https://profiles.wordpress.org/pbearne/) asked if this could this be the case of analyzing the top 20 cookie consent plugins and see if they can be made into a canonical plugin and build from the ground up? However the potentially, tricky thing is building something into core will require extensibility similar to how the privacy policy feature was built, driven by legal requirements that are different in all places. If the extensibility is made too flexible, it may cause more INP problems. ### **Cost Analysis** [@pbearne](https://profiles.wordpress.org/pbearne/) highlighted that there’s no tie back to numbers, costs etc in the presentation from [@flixos90](https://profiles.wordpress.org/flixos90/)— cost of search engines crawling the save in value, cost saving of hosting companies etc — wondered if there’s a way we can obtain any dollar values against what these performance improvements actually mean. [@flixos90](https://profiles.wordpress.org/flixos90/) advised that we can try to draw general conclusions but mostly to get real numbers is do individual case studies, maybe there are hosting providers that are happy to share how much LCP improved and what this means for revenue / cost, specific case studies would be the way forward here, it would be difficult to establish this more widely. Maybe there’s a call we can put out to ask any hosting providers if they’re willing to do a case study ### **TTFB Improvements** [@joemcgill](https://profiles.wordpress.org/joemcgill/) went on to discuss the second to last slide, idea that we can get more benefit from focusing on FE LCP improvements, the underlying TTFB improvements — this was Joe’s initial gut instinct, websites that care about performance fix TTFB by not hitting WP application at all, using aggressive page caching etc. However, mindful at the fact that WP 6.3 we had 2 big opportunities that had a big impact on client slide: removal of emoji loading script and image loading improvements (the addition of fetchpriority and the lazy loading improvements). Whilst focusing on FE LCP improvements are easier, do we have opportunities of similar scale that would make sense, or are we just driving server side? [@flixos90](https://profiles.wordpress.org/flixos90/) added that the difference is that most of client side improvements that we have done are larger efforts, whereas improving server side cut off milliseconds that add up over time. There may be a point where we have no idea what to improve on the client side, but there are a few things mentioned on image sizes attribute is one of them, optimizing how large images are loaded, continuing to optimize fetchpriority and lazy loading are applied, will drive up the passing rate more. Felix added, the main indicator is when we look at mobile, this is where the big difference is happening, when you look at LCP and TTFB together, but LCP in 6.3 was a lot more (probably came from client side improvements predominantly). Desktop TTFB was more visible than mobile. We always benchmark on a desktop machine, so mobile devices are lower powered. Maybe it’s just because for mobile specifically TTFB improvements have a lower role, and it’s more about the device configuration. [@joemcgill](https://profiles.wordpress.org/joemcgill/) went on to ask whether we’re just looking at the % that are getting good scores, rather than the value of TTFB or change in TTFB metric. Could we have made the same amount of improvement as desktop, but not a big enough value to go over the threshold of the passing rate. Felix mentioned he has looked at these numbers as he has assumed the same thing. When you look at aggregated data, there weren’t major improvements in similar ways. Overall scale is still not visible.  ### **2024 Suggestions** [@pbearne](https://profiles.wordpress.org/pbearne/) suggested images, do the amounts of images in the media library impact going through file numbers, orphan image sizes left around — should we have a tool to help clean this up? Some images are left behind from changing themes etc, does this bloat the number of images in the file system? If it does, would a simple tool help remove images that are not current. Here, [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) suggested that some regenerate thumbnails plugins, URLs still point to old images if they’re removed. Thinks everyone has things in folders, if people have them in one giant directory it would impact. File loading may not be an image, but one place to look at was maybe the attachments in posts database, when doing lookups etc, maybe there are places we can eliminate here — but suspect this is a small improvement. The remaining images are mostly about storage space wasted and incurring costs. For performance on end users, doubt this has a notable impact. [@pbearne](https://profiles.wordpress.org/pbearne/) also added that the interactivity API would be a great place to investigate. [@flixos90](https://profiles.wordpress.org/flixos90/) added we should think for next year what can we do to improve interactivity, facilitate WP sites having more responsive interactions. The new metrics means this is more significant. Load time performance, but split this more to cover interactivity. The team discussed any other intentional research what leads to lower INP passing rate, hypotheses have been created but could do with having confidence in knowing where the problems lie. More research is definitely needed. [@flixos90](https://profiles.wordpress.org/flixos90/) continued, what do the TTFB numbers mean for us? This year we have been focused on improving TTFB in core, but thinking about mobile representation, are there other ways we should try to move forward TTFB — what about enhancing APIs to provide more guardrails to plugins, there are a lot of other components to this, could argue that small changes don’t cover lower powered — something core can do better to facilitate caching for more people. Can we unlock caching for sites that have hosts that don’t provide this feature etc. [@joemcgill](https://profiles.wordpress.org/joemcgill/) added that we had talked about trying to use the SQLite Database as an object cache for sites that don’t have a better option — could we think on this again? [@flixos90](https://profiles.wordpress.org/flixos90/) liked this idea, worth exploring— this would be for object caching, could we use it for page caching? Persistent object cache avoids using database requests, not that significant for overall performance. Full page caching would be more beneficial to focus on. Avoiding hitting application altogether could be better. Was looking at full page caching in the CWV dashboard, surprised that the popular caching plugins their TTFB scores are not beating the general WP TTFB numbers, seems counter intuitive. Could we dive into this more?  Were these plugins specific to having the full page caching, could not be turned on. [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) added that we can get a geographical bias, if the plugin is popular in a region with slower internet, it’s not their problem its the users. [@adamsilverstein](https://profiles.wordpress.org/adamsilverstein/) highlighted that you can breakdown on the settings page of the CWV report by geographical region. Could query this in HTTPHTTP HTTP is an acronym for Hyper Text Transfer Protocol. HTTP is the underlying protocol used by the World Wide Web and this protocol defines how messages are formatted and transmitted, and what actions Web servers and browsers should take in response to various commands. Archive to see if there are patterns. Other considerations are all WP plugins that offer full page caching offer this at the application level, not as good as having the layer at the hosting level. ### **Concluding Statements** [@pbearne](https://profiles.wordpress.org/pbearne/) raised that as a plugin developer, having good tests or validations that I’m doing it right, i.e. plugin checker, improving this and helping you recognise where improvements should be made, is something that can improve overall performance. More work in this field would benefit overall, especially if we can do themes as well. [@joemcgill](https://profiles.wordpress.org/joemcgill/) concluded that the team are thankful to Felix for pulling these numbers together, easy to not be able to see the big picture. But really great to see the impact the performance team has made is great to see! Props to [@joemcgill](https://profiles.wordpress.org/joemcgill/) for proof-reading and to [@flixos90](https://profiles.wordpress.org/flixos90/) for the excellent presentation. [#core-performance](https://make.wordpress.org/core/tag/core-performance/), [#hallwayhangout](https://make.wordpress.org/core/tag/hallwayhangout/), [#performance](https://make.wordpress.org/core/tag/performance/) ### Share this: * [ Threads ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=threads) * [ Mastodon ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=mastodon) * [ Bluesky ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=bluesky) * [ X ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=x) * [ Facebook ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=facebook) * [ LinkedIn ](https://make.wordpress.org/core/2023/11/30/hallway-hangout-performance-end-of-year-review-2023/?share=linkedin) 1. ![](https://secure.gravatar.com/avatar/4f50dc56c80eceb636a7ef7d036a019a7d4189e8b3f87d9c899e848248ef36d8? s=32&d=mm&r=g) 2. [annezazu](https://profiles.wordpress.org/annezazu/) 8:43 pm _on_ November 30, 2023 3. Love to see this! Excited to join in. Comments are closed. # Post navigation [← Dev Chat agenda, November 29, 2023](https://make.wordpress.org/core/2023/11/28/dev-chat-agenda-november-29-2023/) [Summary, Dev Chat, November 29, 2023 →](https://make.wordpress.org/core/2023/11/30/summary-dev-chat-november-29-2023/)