A few months ago, we teased that we had a taskforce working on improving platform performance for all of our users. As we start to wind down the year, we wanted to take a moment to update you on those improvements and share the positive results that we’ve seen throughout 2023 to make the site work even better for all users. These are mighty but often unseen changes you may not have heard about or noticed, so we wanted to show you what our tech team has been hard at work on throughout 2023 – in addition to some of the improvements we’ve already made to wiki editing this year.
Let’s take a look at the results and see what we were able to accomplish to make the site perform better for our audiences.
Performance matters[]
Back in March of this year, we started taking a deep look into the performance of our pages and seeing how we could reduce the amount of content, images, JavaScript, and CSS we were sending to a users’ browser. A number of engineers from across our teams put their heads together and made a number of very quick improvements that had a big impact. Over the course of two weeks we were able to reduce our average page load time across the site by over 2 seconds!
While we knew we were improving the experience for our users by making the site faster, we were pleasantly surprised by just how much it had a positive impact for people. One of the metrics we look at for whether people are finding content on Fandom useful and engaging is pageviews/session. This metric basically looks at for every time someone starts a new session on Fandom, how many pages do they view on average. If people find the experience good and useful, they will often view more pages and spend more time viewing different content, so it’s a good signal that we’ve made the experience better.
When we rolled out all of these performance improvements in March, we saw pageviews/session increase significantly inline with page load time improving:
In particular, when we dug into the data to understand more, we saw there were far fewer single pageview sessions, where people might have loaded a page and found the experience slower and left the site after one pageview. This was a really nice reinforcement that we were making the experience better and how much performance matters.
To achieve these couple of second page load time improvement, the team had implemented a number of fixes and optimizations, some examples of the types of things we improved for those interested in technical details include:
- Removing unnecessary content from the first part of the page load, e.g. we had a large SVG image in the source of the page for displaying various icons, however, the SVG included a large number of icons and images we weren’t using all the time. Removing these significantly reduced the page HTML size and sped up the page load time by almost 1 second on average!
- Reduced the size of some large images included on most pages
- Ensured lazy loading was used for more images than were already being lazy loaded. Lazy loading is when an image on the page that is off screen doesn’t load until you scroll closer to it, so that your browser doesn’t download the image until it is needed
- Changed our compression algorithm (from GZIP to Brotli) for all assets and requests, reducing page, JavaScript, and CSS request sizes significantly
- Removing unused JavaScript and CSS
Taskforce Assemble![]
With the impact we’d seen with being able to improve page performance, we decided to pull together a taskforce dedicated to performance to continue to make optimisations to the platform. While most of the low hanging fruit was addressed already, there were plenty of opportunities to improve Fandom’s page performance even more.
The taskforce got to work across all the features of the platform to try to optimize image loading, remove unused code, and generally make things as speedy as possible. This led to a further ~1 second improvement in page load times across the platform. Some examples of things we improved in the performance taskforce include:
- Significantly reducing the amount of JavaScript we were loading by removing support for older browsers, and so reducing the code that was required to stay compatible with browsers that weren’t being used any more
- Modifying various MediaWiki extensions to avoid loading any code for anonymous users that was only usable/required for logged in users
- Significantly reducing unused JavaScript on mobile web by avoiding loading a lot of unused JavaScript from MediaWiki’s MobileFrontend extension
We also looked at performance on some of our larger communities individually to see if there were some performance issues specific to certain wikis as we noticed some were significantly slower than others. Some of these were due to customisations, e.g. too much custom CSS or JavaScript, slow and large custom fonts, etc. However, some of these were things we could change without impacting any of these customisations. An example of this was on fategrandorder.fandom.com, where we noticed the wiki was using a lot of embedded Youtube videos on some high traffic pages. These pages were requesting a large amount of code when the user visited an article in order to display the video, but these videos were often not near the top of the page so weren’t visible until the user scrolled down. By modifying the EmbedVideo extension to make sure these Youtube videos lazy loaded similar to images when they were below the view of the browser window as well, we were able to achieve a nice improvement on mobile web page load times on that wiki and others that might be using the video embeds in a similar way:
How can you help?[]
When it comes to ensuring good page performance for our users, it’s a partnership with all of you. A couple of the things you can do on your wikis to ensure we’re creating a fast experience for the folks visiting your wikis include:
- Ensure any custom CSS on mobile web in particular is kept small and efficient, minimising the number of @import requests to other CSS pages, and avoiding loading large assets on all pages wherever possible like large custom font files. As part of this, avoid just loading all the custom CSS you have on desktop that might be mostly unused on mobile web.
- Keep custom JavaScript on desktop minimal and avoid loading anything that is only required for logged in users or one specific pages on all pages
- Avoid using CSS backgrounds to display large images or icons in content, and instead use normal wikitext file inclusion where possible so that the image can be easily lazy loaded
What's next?[]
Performance is an important aspect of creating a great experience for the users on our platform, and we’ve made a lot of progress on that in 2023. As we move into 2024, we plan to continue to invest in ensuring we’re making the experience on Fandom better, including with further performance improvements. We’ve also been continuing to improve the tools our developers have available to more quickly identify when a change might have an impact on page performance. I’m looking forward to seeing how our team can continue to improve our site performance for you all in the new year!
Click here to follow the Fandom staff blog.
Click here to sign up for the From the Desk of Community email newsletter.
Join our Official Discord server for registered editors!