You are not alone if you’re struggling to improve Core Web Vitals scores and coming up short. Anecdotal evidence suggests that achieving high Core Web Vitals performance is difficult. The reason is because publishers and SEO are trying to fix something that technically is not broken.
Paradigm Shift in How Sites are Developed
We are in the beginning stages of a major paradigm shift in how web pages are created. A faster web host is helpful but it won’t fix Core Web Vitals issues.
Core Web Vitals are calculated downstream at the mobile device that is slurping down your web pages on a mobile phone at 3G or 4G speeds. That is where Core Web Vitals data comes from and a fast web server is of little use at that point if the download is being throttled by a poor Internet connection at the phone.
Improving Core Web Vitals is less about web hosting and more about fixing the code.
Fixing What Isn’t Broken
WP Rocket recently redesigned their website using Gutenberg. That was a brave and almost reckless move considering that Gutenberg didn’t have full site editing capabilities at the time.
They had to customize how WordPress handles CSS and JavaScript in order to improve Google Page Experience Scores.
In other words, in redesigning their website to score well for Core Web Vitals, WP Rocket had to customize WordPress itself, to make it be something it was not designed to be.
Core Web Vitals-Unfriendly
Core Web Vitals standards are not something that WordPress developers have in mind when creating WordPress. That’s why embedding tweets into a post will trigger Cumulative Layout Shift.
WordPress and themes don’t code for Google. They code for the needs of publishers which until May 2020 was not a publisher need.
It’s not just WordPress, either. Most other content management systems don’t have Core Web Vitals best practices built into them.
That doesn’t mean there’s something wrong with WordPress. There is nothing wrong with WordPress because Google says there’s something wrong.
Core Web Vitals is Not a WordPress Problem
Core Web Vitals are a set of metrics independently developed by Google and pushed onto the publisher and SEO community to work with.
WordPress had nothing to do with it. Core Web Vitals appeared in May 2020, apparently without any coordination or consultation with the developer ecosystem.
On the WordPress side, development is moving forward as if Core Web Vitals do not exist. While on the publisher and SEO side it is the users of WordPress who are burdened with the task of “fixing” WordPress, Drupal, phpBB etc.
In a perfect world, the job of creating a system that addresses the needs of the users lies on the developer side. But that’s not happening.
WordPress doesn’t even see Core Web Vitals as a WordPress issue.
When someone started a support thread in the WordPress forums about it they were told to ask in Google’s support forum.
“You should ask on a Google forum, as WordPress has nothing to do with this.”
Publisher and SEO Community Burdened with Compliance
WordPress Publishers are stuck trying to make websites conform to a standard that those websites were never designed to comply with.
This is the reason why so many are struggling with Core Web Vitals. Publishers and SEOs are burdened with trying to fix something that ideally should be fixed at the code level.
Improving Core Web Vitals scores can feel like trying to upgrade the performance of a Honda Civic to the standards of a Chevy Corvette.
The developers did not build a Corvette. They built a Honda Civic.
But Google is demanding that drivers (not the manufacturers) improve the performance to a Corvette level. Does that seem fair to you?
Is it reasonable to ask the users of a software to improve it rather than the developers of the software?
The problem of software compliance with Core Web Vitals exists at the code level, not at the user level.
So why are publishers and the SEO community burdened with fixing something that they are only users of?
Is Google Helpful?
Google provides a lot of tools for diagnosing the problems and offers in depth articles explaining how to fix those coding problems.
But these are coding problems not user problems.
An example of the disconnect between the development community and Google is the the problem of Cumulative Layout Shift, where the web page shifts and rearranges itself as the page elements are downloaded.
A common reason for Cumulative Layout Shift is that images do not have a height and width sizes declared. Google recommends exotic workarounds like using CSS to style the images using aspect ratio boxes.
The average publisher and SEO is probably not going to understand what aspect ratio boxes are and how to calculate the ratios sitewide in a way that doesn’t break the website.
Take a look at this and description of aspect ratio boxes that Google links and see if it makes sense to you:
“Perfect squares and 16:9 stuff is great, but the values used for those are just simple math. An aspect ratio can be anything, and they commonly are completely arbitrary. A video or image can be cropped to any size.
So how do we figure out the padding-top for our 1127.34 × 591.44 SVG above?
One way is using calc(), like this:
padding-top: calc(591.44 / 1127.34 * 100%);”
Goodness gracious!
Here’s another example. Many web templates routinely set image widths via CSS to be automatic (width: auto;) without setting height and width of images in order to make images like a logo scale in size to fit into a template regardless if it’s viewed on a mobile or a desktop device. That’s a common coding practice that causes Cumulative Layout Shift.
These are the reasons why WP Rocket had to dig in and make changes to the CSS and JavaScript sitewide.
For example, WordPress Gutenberg loads up all the CSS that exists, regardless of whether it is needed or not. So WP Rocket’s developer had to hand code a solution for that.
This is how WP Rocket explained what they did as part of their redesign:
“…we deprecated several blocks that were not used. We created a custom enqueue system to have CSS & JS loaded block only when needed. It took us just a few minutes to develop this system.
We also decided not to use the Gutenberg CSS file. Instead, we “migrated” the CSS we actually needed into our own style sheet, into a dedicated CSS file. That did the trick.”
A Rethink of How Sites are Created
It’s important to understand the Core Web Vitals problem. Google is demanding that publishers and SEOs bolt on solutions that the CMS development community do not show an interest in addressing.
Here’s an example of the kinds of compromises we are faced with and how Google is changing how we develop websites.
Let’s talk about fonts.
Render blocking third party resources can negatively impact Largest Contentful Paint. A common bottleneck is downloading fonts from a third party site like Google Fonts.
There are a number of tricks to apply that are combination of using the preload link attribute and maybe some JavaScript, etc. that makes the process of downloading third party fonts Core Web Vitals friendly.
But would it kill your site to leave that fancy font behind?
A simple solution that will help score better is to switch the website font to a sans serif font that Apple, Windows and Android devices already have loaded up in their system.
Switching to an attractive font that is built into the device means that the site no longer has to wait to download a fancy font.
One approach can be something like this:
font-family: Helvetica, Tahoma, sans-serif;
If Android doesn’t have Helvetica or Tahoma already loaded in the browser then the device will display the site using the Roboto font.
Screenshot of Example of Roboto Font
For people accustomed to using fancy fonts, using system fonts might seem extreme. But it’s an example of the kinds of compromises a web publisher may need to make, particularly publishers that are in highly competitive niches.
This kind of decision is a no-brainer for an affiliate site focused on page speed and conversions.
A Moment of Transition
What is happening today is that we are living in a moment of transition. Things are changing from how we did things in the past to how developers are going to do things (out of the box) in the future.
Developers responded to the demand for mobile friendly sites. In time they may begin responding to the demand for sites that score well for Core Web Vitals.
The way CMS systems, templates and plugins are designed have not caught up to the needs of publishers who require consideration of Core Web Vitals.
For the time being, tech SEOs and the developer community is stuck having to “fix” what isn’t broken in order to make it abide to Google’s idea of what the web should look like.
Of course, a page that loads fast and doesn’t shift around is a good thing. But requiring the users of a software to improve the software itself is a burden.
At this point in time the burden of fixing the code falls on the users of the publishing software and not on the developers of that software. Does that feel right?
What may happen is that some may find it useful to fix as much as they can and leave the rest for when WordPress and other CMS software catches up.
