Some website owners see the Core Web Vital report failing in the Google Search Console (GSC) even after using RabbitLoader. This guide will discuss multiple factors affecting Core Web Vitals that are beyond the scope of RabbitLoader service.
The Core Web Vitals report shows how your pages perform and groups all the unique URLs of a website by status a status such as Poor, Need improvement, and Good, based on the field data, also called real-world usage data.
Here are the performance ranges for each status:
Good | Need improvement | Poor | |
---|---|---|---|
LCP | <=2.5s | <=4s | >4s |
FID | <=100ms | <=300ms | >300ms |
INP | <=200ms | <=500ms | >500ms |
CLS | <=0.1 | <=0.25 | >0.25 |
This section specifically focuses on the reasons that may affect the CWV report, which are beyond the score of RabbitLoader and may need attention from website owners.
Many hosting packages just indicate the storage size in terms of Gigabytes (GB) or Terabytes (TB). However, the type of the store is not disclosed. Our users should ensure the storage type is SSD (Solid State Drive) and not the magnetic HDD (Hard Disk Drive). The storage affects how fast data can be read from the disk when a visitor asks for a page. HDD and other slower storages can increase the Time to First Byte (TTFB). TTFB is the delay between when a visitor requests a webpage from the hosting server, and when the server starts returning the first-ever byte.
RabbitLoader stores the cached copy of the web pages on the disk. If disk performance is good, all reads and writes will be faster reducing the server response time for the main document.
For non-technical practical purposes, we can assume DOM size is how big your page has all the HTML. The longer the HTML, the more time will be required to process it and apply styling, etc. Unfortunately, RabbitLoader can not make the page short and trim the contents. This is something the owner of the website should take care of.
In some cases, large DOM size is caused by the “drag and drop” page builder applications. Though these page builds are easy to use, often they create multiple wrappers for the page elements due to the limitation of the approach.
Lighthouse shows the warning and error status of a page based on how many nodes or HTML elements are there. These nodes are not the visible items on the page, but the markup used to render those elements-
If any of the image referenced on the website does not exist, can delay the page rendering. Usually, the missing image lookup takes a significant time before the server decides to return a 404-Not Found response code.
Google updates the CrUX dataset based on a rolling average of 28 days. CrUX or the Chrome User Experience Report is collected from real devices and powers the Core Web Vitals metrics of the website. So, any change done on the website may take up to 28 days to reflect on the Core Web Vitals.
While our users can delegate the dashboard and all controls for a website to other users, there could be a need to move the already registered website to a different account.
The website can be moved and re-registration is possible from the RabbitLoader console by following the below steps-
This step is applicable to WordPress users.
If you are using the WordPress plugin, go to the RabbitLoader plugin page -> Settings tab. Click the Disconnect button. This step can be ignored if the plugin is already disconnected or uninstalled.
Log in to the Console with the first email where the website is registered. Navigate to Action->Delete menu.
Continue with the confirmation and complete the next steps.
Once the website is deleted, please log out from the console. Logging out is important.
Now login to the console again with the second email, this is the target account where you want to keep your website finally.
Go to the WordPress plugin page again and connect the plugin again. The website will now be moved to the new account.
Divi theme has many inbuild performance optimization options. While they are very helpful, due to how WordPress is designed, some of these features may conflict with RabbitLoader.
Divi theme users are suggested to disable the below options.
Navigate to Divi Theme options -> General -> Performance and disable all options on this page.
Save the settings.
Navigate to Builder -> Advance tab and disable the Static CSS generation option.
Press the Save Changes button.
There are some features of the WPBakery page builder that may not give the same experience when using RabbitLoader with it. Here are some known settings –
Please choose the ‘none’ option in the CSS Animation option for Row and all other widgets.
Click on the Edit icon shown for the element or row when editing a page, you should see a similar popup as shown below. Here, under the CSS animation, select ‘none’ from the dropdown.
RabbitLoader is fully compatible with the Ajax Search Pro WordPress plugin. Users need to adjust some settings to make their use effective with our website optimization plugin.
Under the Compatibility and Other settings, please go to the CSS & JS loading tab and set these values-
All-In-One Security (AIOS) Security scanners alert you to file changes in your WordPress system, so you can see if a change is legitimate or suspicious, and investigate as appropriate. Since RabbitLoader creates files to cache contents, the alert by the AIOS plugin may not be helpful.
Login to the WordPress admin panel. On the left menu, go to WP Security, then on the submenu, click on the Scanner option. Now under the “File Change Detection settings”, find the text box for “Files/Directories to ignore”. In this textbox, type “rabbitloader” without quotes and all in small letters.
Save the settings and it’s done.
This video will guide you to exclude RabbitLoader directories from the alert report.
Many themes come with “preloader” animation which shows loading-like graphics and prevents content display till all resources on the page have loaded.
Showing a preloader animation is good for a normal website where asset loading is set to default and not prioritized in any order. It makes sense to show a loading animation to visitors till all assets such as CSS/JS/Images are loaded and the webpage becomes interactive.
However, if a website is optimized with Rabbit Loader, the asset loading is prioritized and a few non-essential resources which are used way below towards the end of the webpage can be loaded later. This creates a problem with the “preloader” feature as the preloader animation keeps waiting for everything to be loaded and blocks the view of the entire page.
For this reason, we recommend turning off the preloader animation when using RabbitLoader.
Please refer to the theme’s documentation or settings on how to disable the preloader. We will keep adding examples for some popular themes and plugins here.
CSS is used to style a webpage. It is commonly used to add fonts, colors, spacing, etc to a page. When a website uses a theme, which is pretty common for CMS like WordPress, these styling definition is written into multiple CSS files based on how and where they are going to be used. Similarly, the plugins for these CMS also adds up more CSS file to render their widgets or other contents on the webpage.
Everything comes with a cost, the more CSS files you add, the browser is going to take more time to download, parse, and render them before the visitor can see any content on the screen. This delay in rendering the content on the screen is what know as “First Contentful Paint” or FCP matrix of Google’s Core Web Vitals.
While more CSS files add up those many network round trips to the server, to simplify our understanding hereafter, we will talk just in terms of the size of the total CSS. Let’s say, no matter how many CSS files a website is using, the total size of those files is 1 Megabyte. And without bringing much complexity to the telecommunication network, let’s assume it’s going to take around 4 seconds to load these CSS definitions on a standard 3G network.
Now, this 4 seconds of duration is a blocker for the entire page, because unless everything has been downloaded, and parsed, the browser is not going to render anything on the screen. This 4 seconds is a huge time and sufficient enough to bounce the visitor.
In the above example, you see the total CSS used on the entire page is 1 MB. But should we load really everything, even those stylesheet definitions that are going to be used towards the footer area? No, right. We can first load only those styles which are sufficient to render the content on the visible area of the screen, engage the user by allowing them to start reading the page from the top, and continue loading the remaining styles in the background. This approach is what we also call, critical and non-critical CSS loading.
The styles used above the fold, aka visible area of the screen, are critical CSS because it’s the bare minimum load required to engage the user. And the styles used below the fold can be called non-critical because they can be loaded a few seconds later, or just before the user is about to scroll the page.
When you enable CSS deferring, RabbitLoader automatically takes care of the critical and non-critical CSS in a unique way for every single web page of the website. This ensures the minimum render-blocking time due to CSS loading and parsing.
This option is available on the Console->Settings->Page Rules. If you are new to the page rule, please take a look here. Click on the modify button for the page rule you want to modify. If you want this new setting to be effective for the entire website, choose the ‘*’ rule.
Turn on the checkbox for CSS optimization.
When CSS optimization is turned on, the non-critical CSS is deferred. This improves the page load time and improves Core Web Vital health.
For any reason, if you would like RabbitLoader to never defer some CSS files, you can put those file names in the “Skip lazy load” box separated by space. If there are multiple files with the same name, you can also include the path of the file. For example, /folder1/style.css and /folder2/style.css
RabbitLoader performs a few checks before you can connect the plugin to the cloud account. In case of conflicts are detected, they need to be fixed before continuing.
We have collected some common errors you may see, and have suggested steps to fix them.
You may encounter a warning to disable the “WP Super Cache” plugin, but the plugin is not installed on the website. There are two possibilities-
# define('WPCACHEHOME', '/home/public_html/wp-content/plugins/wp-super-cache/' ); //Added by WP-Cache Manager
Some themes are based on Fusion builder and require overlapping optimization to be turned off. Please follow the steps if you are using any of these themes.
In the left panel of the WordPress admin panel, the second menu should be Avada. Go to Avada -> Options. In the submenu appearing on the left, click on Performance. Please disable all performance options from here, such as Image and Iframe Lazy Loading, deferring jQuery, making the styles non-render-blocking, critical CSS, etc. RabbitLoader already takes care of them.
Note: There are two settings pages that have to up updated. The first one is Avada->Options->Performance and the second one is Avada->Performance->Optimizations
Some performance settings can be kept on such as SVG Media upload, WordPress Big Image Size Threshold, etc. Make sure these are off/disabled-
Some screenshots for reference.
Please also note that RabbitLoader does not support the separate Desktop and Mobile header/footer. As an alternative, try to keep the design responsive that does not depend on the user agent.