User blog:FishTank/Evolving Wiki Performance

As promised, we are beginning to share our analysis of how wiki-specific elements impact Google's Core Web Vitals metrics as part of our Evolving with the Web work. This blog will serve as a high-level summary of our initial findings. If you would prefer to read my very in-depth analysis, head over to this help page.

The Metrics
To recap, Core Web Vitals is Google’s new project which measures 3 different aspects of how a website loads once you navigate to it. The purpose of this project is to ensure that websites which provide an immediately good user experience in terms of loading in and letting you engage are rewarded with better search result placements. This is in addition to Google’s normal algorithm crawling for quality content matching your search terms.

The 3 different metrics are:


 * Largest Contentful Paint (LCP): How quickly the biggest content area of the page is visible to the reader.
 * First Input Delay (FID): How quickly links or other interactive elements can be used.
 * Cumulative Layout Shift (CLS): How much the initial visible screen elements move whilst loading before they can be interacted with.

Practically, this means they want the page to load quickly, not move around much while it loads, and let you interact quickly. Makes sense, right?

What we can do
We are working on making things load faster and shift less so that LCP, FID, and CLS scores improve across the board for every page. That work will raise the baseline for the platform, but these scores are made for every crawled page on your wikis, which means that the content itself will also affect how they score.

What you can do
Here are some quick hits from our analysis of formatting impact on these metrics. For the full picture, feel free to check out the help page.

Short pages and stubs
Reconsider your wiki’s policy regarding stub pages. Stub pages, when left incomplete for more than a few days, lower Google's view of a wikis credibility. For Core Web Vitals purposes: the short page content is smaller than the frame and header around it, which causes bad CLS scores when Google thinks the content has been shifted too much in comparison.

Tabbed pages
Reconsider your wiki’s approach to tabbed pages. If your tab structure relies on a desktop-focused template system or excessive JavaScript, it can impact the way the mobile-first crawling reads the page and affect your Core Web Vitals scores.

Shortening pages
Let’s start off by saying there’s nothing wrong with long wiki pages. Some of the longest pages on our platform are among the most authoritative content on the web (looking at you, Wookieepedia and your Ahsoka page). Long pages help feed Google a complete picture.

If you are trying to shorten a long page, however, we recommend that you refrain from using tabbers, as it will impact your FID and CLS scores. If tabbers are necessary, there are some good ways to do this for maximized usability and I cover that in the help page.

What’s next?
This is the first part of our analysis on how wiki formatting impacts Core Web Vitals metrics. In Part II, I’ll be going over things like templates and complex layouts, including nested layouts, Lua, Portable Infoboxes, and complex tables.

If you have questions, feel free to ask them in the comments here, on the comments section of the help page, or in Discord’s #best-practices channel.

de:Benutzer Blog:SpacePucky/Performanz von Wikis fr:Blog utilisateur:Celdrøn/Faire évoluer les performances des wikis it:Blog_utente:Daeron_del_Doriath/Evolvere_le_Performance_delle_Wiki pl:Blog_użytkownika:Rail/Poprawianie_wydajności_wiki pt:Blog_de_usuário:Eduaddad/Evolução_do_desempenho_da_wiki zh:User_blog:列维劳德/发展wiki性能