Google Core Web Vitals for WordPress: How to Test and Improve Them

Table of Contents

Heard about this new Google Core Web Vitals project but not sure how it connects to your WordPress site? Or maybe you have no idea what the Core Web Vitals project is and why it matters for WordPress?

Either way, this post is going to cover everything you need to know about Core Web Vitals and WordPress. We’ll tell you what they are, how to test them, and how to improve your site’s scores to create a better user experience and maybe even boost your search rankings in 2021 and beyond.

What Are Google Core Web Vitals?

Core Web Vitals are a new initiative from Google designed to measure and improve user experience on the web. Instead of focusing on generic metrics like how long it takes your entire website to load, Core Web Vitals focus on how your WordPress site’s performance connects to delivering a high-quality user experience.

Users care about how fast they can start interacting with a page. That’s precisely what the Core Web Vitals metrics aim to measure.

Currently, there are three Core Web Vitals: Largest Contentful Paint (loading performance), Cumulative Layout Shift (visual stability), and First Input Delay (interactivity).

According to Google, these metrics are the most important ones for providing a great user experience.

If you think that these names are confusing, and if you tend to mix one metric with another, don’t worry! We’ll explain each metric in the easiest way. We want you to understand what each Core Web Vital means and its impact on user experience.

It’s the first step for improving the scores and your overall SEO and WordPress performance.

Explaining Largest Contentful Paint (LCP)

Largest Contentful Paint (LCP) measures how long it takes for the most meaningful content on your site to load – that’s usually your site’s hero section or featured image.

According to Google, how long it takes for a page’s main content to load affects how quickly users perceive your site to load.

Practical example: you land on a page and don’t see the top image fully displayed right away. You would be annoyed, right? You would even think about leaving the page right away. Here’s why the Largest Contentful Paint metric is closely related to user experience — more than the overall site’s loading time.

The LCP “element” is different for each site, and it’s also different between the mobile and desktop versions of your site. Sometimes the LCP element could be an image, while other times, it could just be text. You’ll get a clear example in the section on how to test and measure Core Web Vitals.

If you’re wondering what a good LCP time is, here are Google’s thresholds:

Good – Less than or equal to 2.5 seconds
Needs Improvement – Less than or equal to 4.0 seconds
Poor – More than 4.0 seconds.

On a side note: LCP is very similar to First Contentful Paint (FCP), another metric included in PageSpeed Insights.

The key difference is that LCP measures when the “main” content loads. FCP is focused on just when the “first” content loads — which could be a splash screen or loading indicator, that’s a less relevant user-experience element.

Explaining Cumulative Layout Shift (CLS)

The Cumulative Layout Shift (CLS) measures how much your site’s content “shifts” or “moves around” as it loads.

Practical example: you’re about to click on a link or CTA, and you can’t do it because your content has just gone down after being loaded. You have a terrible user experience, and that’s a layout shift. The same goes when you accidentally click the wrong button because the late-loading content caused a button to shift.

Or, have you ever been on a news website where the content in the article keeps shifting around as the site loads ads, and you are unable to keep reading? That’s a layout shift, too.

You can see from yourself how the cumulative layout shift is super annoying for users and how they will have a poor experience.

Here’s how Google defines the CLS scores:

Good – Less than or equal to 0.1 seconds
Needs Improvement – Less than or equal to 0.25 seconds
Poor – More than 0.25 seconds.

Explaining First Input Delay (FID)

First Input Delay (FID) measures the time between when a user interacts with something on your page (e.g., clicking a button or a link) and when their browser can begin processing that event.

Practical example: if you click on a button to expand an accordion section, how long does it take for your site to respond to that and show the content?

First Input Delay is probably the most complicated metric to understand and optimize for, also because it’s heavily affected by JavaScript.

Let’s say that you land on a site from mobile and click on a link, but you don’t get an immediate response. It could be because your phone is busy processing a large JavaScript file from that site.

Here’s how Google defines FID scores:

Good – Less than or equal to 100 ms
Needs Improvement – Less than or equal to 300 ms
Poor – More than 300 ms.

Do Core Web Vitals Affect SEO as a Ranking Factor?

In June 2021, Google will start using Core Web Vitals as a ranking factor – therefore, these metrics could affect your SEO performance.

Core Web Vitals will be part of the new Page experience signals, together with HTTPS-security, safe-browsing, mobile-friendliness, and intrusive interstitial guidelines.

Core Web Vitals will affect both mobile and desktop organic results, as well as whether or not your site appears in Top Stories. Previously, your site needed to use AMP to appear in Top Stories. That will no longer be the case when Google rolls out the change, but your site will need to meet specific minimum Core Web Vitals scores to appear in Top Stories.

What’s more, it seems like all Core Web Vitals metrics need to be met to improve organic ranking. And the Core Web Vitals score for noindexed pages may matter, too.

In short: if you care about your SEO performance, improving your Core Web Vital scores is now mandatory.

How to Test & Measure Core Web Vitals on WordPress

You can test and measure the Core Web Vitals with all of Google’s tools for web developers, from PageSpeed Insights to the Chrome DevTools, the CrUX Report, and much more.

As you can see in the image below, Google’s tools measure all the three metrics — except for Chrome DevTools and Lighthouse.

These two tools use the Total Blocking Time as a proxy for the First Input Delay. That’s because FID can only be measured with real user data (Field Data), whereas Lighthouse only provides Lab Data.

Google’s tools to measure Core Web Vitals

If you prefer using another performance tool, you should know that both GTmetrix and WebPageTest have started to use the Lighthouse performance score.

Keep in mind that both tools only provide you with the Largest Contentful Paint and the Cumulative Layout Shift scores.

The reason is always the same: the First Input Delay can only be measured with real user interaction, and these tools rely on the Lighthouse Lab Data.

Let’s now go over two of the most popular tools: PageSpeed Insights and Search Console. The first one helps you detect individual page issues; the other allows you to diagnose sitewide problems.

How to Test and Measure the Core Web Vitals with PageSpeed Insights

The easiest way to test your site’s pages against Core Web Vitals is via Google PageSpeed Insights.

Google’s tool provides data on all three metrics and gives specific recommendations to improve their performance.

The Diagnostics section will become your best ally to get a better score!

Just plug in your site’s URL, and you’ll see Core Web Vitals metrics in both the Field Data (based on the CrUX report) and the Lab Data (based on Lighthouse 6.0).

The Core Web Vitals metrics are marked with a blue ribbon – as long as you get it, you meet the threshold required by Google.

PageSpeed score for the WP Rocket homepage

You should keep in mind some notes:

The Core Web Vitals scores can slightly differ between the Field and Lab Data. In the screenshot above, LCP is 1.8 s according to the Field Data and 2.2 s in the Lab Data. That’s normal, and it depends on how data is collected.
Not having any Field Data when running your test is not an issue. It’s because there’s not enough real user data available. It doesn’t impact your Core Web Vitals because PageSpeed Insights considers the Lab Data for the page speed score.If you’re wondering what happens with the First Input Delay, not included in the Lab Data, you’ll get your answer in a few lines!
Always check both the mobile and desktop results. Your Core Web Vitals metrics will differ between the two. Keep in mind that the mobile score is the most relevant and the most challenging.

Let’s now look at how you can use PageSpeed Insights to identify the Core Web Vitals elements that need improvement.

Discovering the Largest Contentful Paint Element with PageSpeed Insights

As we explained, the LCP score measures how long it takes for the most meaningful element to become visible to your visitors.

To discover your site’s Largest Contentful Paint element, scroll down to the Diagnostics section and expand the Largest Contentful Paint element tab.

There, Google will display the HTML for the element that it’s using to measure LCP.

For example, on the desktop version of the WordPress.org homepage, the LCP element is an image:

The LCP element from the desktop – PageSpeed Insights

However, on the mobile version of the site, the LCP element is the subheading text:

The LCP element from the mobile – PageSpeed Insights

Discovering the Cumulative Layout Shift Elements with PageSpeed Insights

Quick recap: the Cumulative Layout Shift deals with how your site loads and whether or not your content “moves around” as new content is loaded.

To find the individual elements on your site that are “shifting” and affecting your score, go to the Avoid large layout shifts section in the Diagnostics area:

The CLS elements - PageSpeed Insights — The CLS elements – PageSpeed Insights

Discovering First Input Delay and Total Blocking Time with PageSpeed Insights

First Input Delay is about user interaction, remember? Meaning, how long it takes for the page to respond after interacting with an element such as a link or a button.

That’s why FID is based on actual user data, and you won’t find its score in the Lab Data. As we explained, you’ll only see FID times in the Field Data section — and only if the CrUX report has collected enough data.

In the Field Data, Total Blocking Time (TBT) will replace First Input Delay.

Total Blocking Time replaces First Input Delay in the Lab Data.

As long as you improve your Total Blocking Time, you’ll likely improve the FID score.

If you have a bad TBT score, you should go to the Minimize third-party usage section in the Diagnostics section.

Here, you’ll see what you can minimize in terms of third-party usage. It’s one of the main performance issues you need to solve – unless it’s already solved and included under the “Passed audits” sections, as you can see below:

Minimize third-party usage recommendation – PageSpeed Insights

How to Read the Core Web Vitals Report on Search Console

If you want to diagnose issues with your site as a whole, you should use the Core Web Vitals report in Google Search Console.

The report is based on an aggregate of real users’ data from CrUX. For this reason, the data included in the report could take a while before reporting issues. That’s why the Lab Data from Lighthouse is always valuable.

That said, the Core Web Vitals report is great to identify the groups of pages that require attention – both for desktop and mobile.

The Core Web Vitals report in Search Console – Overview

Once you open the report, you’ll find a Details tab that groups the URL performance by several criteria:

Status (Poor or Need improvement)
Metric type (e.g., CLS issue: more than 0.25 (desktop))
URL group (the list of URLs with similar performance).

Once you have fixed the URLs that needed an improvement, you’ll also be able to click on the Validation column and move forward with the “Validate Fix” option. Keep in mind that the validation process takes up to two weeks — be patient!

The Core Web Vitals report in Search Console – Details tab

How to Measure Core Web Vitals with Chrome Extensions

If you’re looking for a useful Chrome Extension, you could choose Web Vitals.

It gives you the Core Web Vital scores for any page you’re browsing:

You may also want to try CORE Serp Vitals, which shows you the Core Web Vitals results directly on the SERP. Remember that you need to enter a Chrome UX Report API key to let the extension work.

How to Improve Core Web Vitals on WordPress

Now for the critical question — if you aren’t currently meeting Google’s recommendations for the three Core Web Vitals metrics, how can you optimize your WordPress site to improve your Core Web Vitals scores?

The strategies are different for each metric. Most optimizations involve implementing WordPress performance best practices, though with a few points of emphasis — and that’s why choosing the best WordPress caching plugin will help you with no effort from your side.

Watch the video to understand how to optimize your Core Web Vitals, and keep reading to learn more about it.

How to Improve Largest Contentful Paint on WordPress

Optimizing for Largest Contentful Paint is the most straightforward metric as it’s pretty much entirely WordPress performance best practices:

Set up page caching. Page caching speeds up how quickly your server can respond and reduces the server response times (TTFB). Did you know that WP Rocket enables this automatically?
Optimize browser caching. You should set the right option for the static files that your browser keeps in its cache. By doing so, you’ll address the “Serve static assets with an efficient cache policy” PageSpeed Insights recommendation. Guess what? WP Rocket enables the optimal expiration length automatically.
Optimize your images. A lot of times, your LCP element will be an image. Optimizing your images will speed up your site and address PageSpeed recommendations such as “Properly size images”, “Defer offscreen images”, “Serve images in next-gen formats”, and “Efficiently encode images”. You can use Imagify to optimize WordPress images automatically.
Optimize your code. Loading unnecessary CSS or JavaScript files before your main content will slow down the loading time. You can fix this by eliminating render-blocking resources on your WordPress site. You should also minify CSS and Javascript files and remove unused CSS. Optimizing your code will help you address the “Avoid chaining critical requests” PageSpeed recommendation. Once again, you’ll get most of the job done by setting these optimizations up in the File Optimization tab in WP Rocket.
Use server-level compression. Using Gzip or Brotli compression will reduce your site’s file size, which speeds up LCP and addresses the “Enable text compression” recommendation. WP Rocket automatically enables Gzip compression.
Use preconnect for important resources. Preconnect lets you establish important third-party connections early and addresses the “Preload key requests” and “Preconnect to required origins” recommendations. You can learn more in our tutorial.
Use a content delivery network (CDN) for global audiences. If you have a global audience, a CDN can speed up your LCP time for visitors around the world. It’s another effective way to reduce the Time to First Byte (TTFB). You can use our RocketCDN service.

The easiest way to implement most of these best practices is to use WP Rocket. WP Rocket will automatically apply page caching and server-level compression as soon as you activate it. It also includes other features to help you optimize your site’s code and performance, all of which improve your LCP time.

Source :
https://wp-rocket.me/google-core-web-vitals-wordpress/

UniFi – Console and Gateway Recovery Mode

The Recovery Mode User Interface (UI) is a special interface for UniFi OS Consoles (UDMP, UNVR, etc.) and gateways used to recover from various failure modes (indicated on the LCM screen of that device). From the Recovery Mode, you can perform the following actions:

Reset to Factory Defaults: Completely reset the device. Note this will also wipe out any stored backup files.
Reboot: Restart the device and re-load the existing configuration.
Power-off: Initiate a software shutdown on the device, after which you can safely remove the power cable.
Check Filesystems: Check the integrity of the file system.
Firmware Update: Upload a previously downloaded firmware image (.bin) file in order to upgrade the firmware.

You should only resort to using recovery mode if you are prompted by the LCM screen found on your device.

Performing a Device Recovery

Download the most recent firmware for your device. You can find information on our latest releases here.
Completely power-off the UniFi device and unplug it from its power source.
Press and hold the reset button and then power on the device by connecting it to the power source once again.
Keep the reset button pressed for about 5 seconds. After some time the display (in supported models) will indicate that the gateway is in Recovery Mode.
Connect an Ethernet cable from your computer to the first LAN port (port 1) on the UniFi gateway.

Note: Port 1 is always the first one. Either the top port, or the top left corner one, depending on the layout of your device’s ports.
Configure a static IP address on your computer in the 192.168.1.0/24 range (for example 192.168.1.11). Windows ClientmacOS clientNote: If a wireless adapter is enabled and connected to another network it could conflict with the connection to the UniFi device. Disable the wireless adapter if necessary.
Open a compatible web browser navigate to http://192.168.1.30 to access the Recovery Mode UI.

Note: The Recovery Mode UI is accessible via HTTP only and not HTTPS. It is possible that your browser will automatically try to redirect your session to HTTPS. Make sure to navigate to the http://192.168.1.30 address and use a different browser if necessary.
Select Firmware Update > Choose and browse your computer for the previously download firmware (.bin) image file.
Wait for the upgrade process to complete and reboot the device afterwards.

Source :
https://help.ui.com/hc/en-us/articles/360043360253-UniFi-Console-and-Gateway-Recovery-Mode

UniFi – Login with SSH (Advanced)

We do not recommend using SSH unless instructed by one of our Support Engineers as part of advanced troubleshooting. Inexperienced users risk making changes that may degrade network performance, or even worse, completely break your deployment. Proceed with caution.

Requirements

1. You are connected to the same local network as the device/console you plan to connect with via SSH. This may consist of using a laptop connected to the same WiFi network, or hardwired directly to the device.

2. SSH is enabled. UniFi Network devices and UniFi OS Consoles have independent SSH settings.

UniFi OS Consoles – Following setup, SSH is automatically disabled. It must be enabled in your UniFi OS System Settings.
UniFi Network Devices – Following setup, SSH is automatically enabled. The credentials consist of a random string of characters.

3. The device you are using has a command line interface (CLI) capable of establishing a Secure Shell (SSH) connection. Linux and macOS devices can use their native terminal. Windows OS requires PowerShell or PuTTY.

Establishing an SSH Connection

The format of the command used to establish an SSH connection is as follows:

ssh <username>@<ip-address>

The <username> for UniFi OS Consoles (UDM Pro / UNVR / Cloud Key) and UniFi Gateways (UXG Pro) is always ‘root’. For example, a Dream Machine Pro (gateway) with an IP address of 192.168.1.1 can be accessed as follows:

ssh root@192.168.1.1

Note: The UXG will use <username> = ‘root’, but the <password> will be the shared password set in your UniFi Network Application.

Default Credentials

Prior to setup/adoption, devices have a set of default credentials.

UniFi OS Consoles – root / ubnt
UniFi Gateways – root / ubnt
UniFi Devices – ubnt / ubnt

Source :
https://help.ui.com/hc/en-us/articles/204909374-UniFi-Login-with-SSH-Advanced-

UniFi – Advanced Updating Techniques

We recommend that most users enable automatic updates. Doing so allows you to specify when your UniFi deployment automatically checks for and installs updates.

UniFi OS Console and application update preferences can be configured in your UniFi OS Settings. Please note, though, that self-hosted UniFi Network applications do not offer automatic updating.

UniFi Network device update preferences are set in your Network application’s System Settings. Devices managed by other UniFi applications are automatically updated within their respective applications.

Manually Update UniFi Devices via Web Application

Updating via the Device Property Panel

Use Case: You want to try Early Access firmware releases for specific devices, or you want to return to an official release after trying an EA release.

1. Copy the firmware release link from community.ui.com/releases.

2. Paste the link in the address bar found in the Settings tab of the device’s properties panel.

Updating via Your Network Cache

Use Case: You prefer to download and store updates in your Network application so they can be used by other devices, as opposed to downloading multiple, device-specific files from the internet. This is an ideal solution for reducing bandwidth within high-volume networks that host a large number of similar UniFi devices. It is also suitable for the advanced users who disable internet access on their UniFi device’s management network.

Device updates can be cached in your Network application’s System Settings. Once an update is cached, you can open to your UniFi Devices page and click Update Available.

Note: The Cache link will appear when you hover your cursor over an update.

Updating via SSH

Note: SSH updating is not a typical or recommended method. It is only prescribed to work around specific scenarios, such as when:

Prior traditional update attempts have failed. A successful SSH update will help verify if initial failures resulted from incorrect network configuration. For more details, see Troubleshooting Device Updates.
Your UniFi Network device is not being discovered or cannot be adopted because it has been preloaded with outdated firmware.
Your UniFI OS Console cannot be set up because it has been preloaded with an outdated version of UniFi OS.

UAP/USW (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:upgrade paste_download_link_here Exupgrade https://dl.ui.com/unifi/firmware/UAL6/5.60.1.12923/BZ.mt7621_5.60.1+12923.210416.1641.bin

UAP/USW (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /tmp folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExscp /Users/alexpro/Desktop/BZ.mt7621_5.60.1+12923.210416.1641.bin Alex@192.168.1.219:/tmp/fwupdate.bin
Enter your SSH password when prompted.
Run the following command:syswrapper.sh upgrade2 &

UDM/UDM Pro/UXG Pro (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:ubnt-upgrade paste_download_link_here Exubnt-upgrade https://fw-download.ubnt.com/data/udm/7675-udmpro-1.12.22-36b5213eaa2446aca8486f0b51e64cd3.bin

UDM/UDM Pro/UXG Pro (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /mnt/data folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/mnt/data/fwupdate.binExscp /Users/alexpro/Desktop/7675-udmpro-1.12.22-36b5213eaa2446aca8486f0b51e64cd3.bin Alex@192.168.1.219:/mnt/data/fwupdate.bin
Enter your SSH password when prompted.
Run the following command:ubnt-upgrade /mnt/data/fwupdate.bin

UCK G2, UCK G2 Plus, UDM SE, UDR, UDW, UNVR, UNVR Pro (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:ubnt-systool fwupdate paste_download_link_here Exubnt-systool fwupdate https://fw-download.ubnt.com/data/unifi-dream/dd49-UDR-2.4.10-cd3afa000ebf4a4fb15374481539961c.bin

UCK G2, UCK G2 Plus, UDM SE, UDR, UDW, UNVR, UNVR Pro (No Internet)

Download the desired firmware update from community.ui.com/releases.
Use the following SCP command to copy the file into the /tmp folder of your device. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/firmwarefile.bin <user>@<IP of device>:/tmp/fwupdate.binExscp /Users/alexpro/Desktop/dd49-UDR-2.4.10-cd3afa000ebf4a4fb15374481539961c.bin
Enter your SSH password when prompted.
Run the following command:ubnt-systool fwupdate /tmp/fwupdate.bin

USG (Internet)

Copy the update link from community.ui.com/releases.
SSH into your device.
Run the following command:upgrade paste_download_link_here Exupgrade https://dl.ui.com/unifi/firmware/UGW3/4.4.56.5449062/UGW3.v4.4.56.5449062.tar

USG (No Internet)

Download the desired firmware update from community.ui.com/releases.
Rename the file: upgrade.tar
Use the following SCP command to copy the file into the /home/<user> folder of your USG. This requires a compatible SCP application (e.g., Terminal on macOS and Linux, PuTTY/PowerShell on Windows).scp /folder_path/upgrade.tar <user>@<IP of device>:/home/<user>/upgrade.tarExscp /Users/alexpro/Desktop/upgrade.tar Alex@192.168.1.1:/home/Alex/upgrade.tar
Enter your SSH password when prompted.
SSH into your device.
Run the following command:sudo syswrapper.sh upgrade upgrade.tar

Manually Update the Network Application

Download the desired application update from community.ui.com/releases.
SSH into your device.
Run the following command (UDM/UDM Pro Only):unifi-os shell
Remove previously installed files:rm /tmp/unifi_sysvinit_all.deb &> /dev/null
Store the new application version on your device using the download link:curl -o “/tmp/unifi_sysvinit_all.deb” <network application link.deb>Excurl -o “/tmp/unifi_sysvinit_all.deb” https://dl.ui.com/unifi/6.2.26-a79cb15f05/unifi_sysvinit_all.deb
Once downloaded, install the new version:apt-get install -y /tmp/unifi_sysvinit_all.deb
Following installation, remove the downloaded file:rm /tmp/unifi_sysvinit_all.deb

Updating Devices in a Broken State

In rare occurrences, a device may stop functioning. UniFi APs may be updated using our TFTP Recovery. This should only be used if your AP completely stops functioning as a last resort prior to submitting an RMA. UniFi OS Consoles and gateways my be updated using Recovery Mode. This should only be used if prompted on your device’s LCM screen.

Source :
https://help.ui.com/hc/en-us/articles/204910064-UniFi-Advanced-Updating-Techniques

UniFi – Getting Support Files and Logs

It may be necessary to provide support files to our team when troubleshooting issues. These contain detailed logs and information about what is happening with your UniFi system. Although sensitive information is generally removed, we do not recommend sharing these publicly.

There are two support files to be aware of:

UniFi OS Support File: This contains logs related to your UniFi OS Console, the installed applications, your adopted UniFi devices, and the client devices connected.
Navigating to unifi.ui.com (or signing in locally via IP address) > select your UniFi OS Console > Console Settings > Download Support File. Note that it will have a *.tgz extension.
UniFi Network Support File: This only contains information about your UniFi Network application, your adopted UniFi Network devices, and the connected clients. This should only be used if you are self-hosting the UniFi Network application on a Windows, macOS or Linux machine.
Navigate to your UniFi Network Application > Settings > System > Download Network Support File. Note that it will have a *.supp extension.

Advanced

If the UOS Console or UniFi applications are inaccessible and you are not able to download the support file, you can download the logs by following these instructions. Please note, our support engineer will provide detailed information on which of the following will be required for troubleshooting.

1. SSH into the machine: ssh root@192.168.1.1

Note: If you need to change your SSH password, do so in the UniFi OS Settings, by navigating to unifi.ui.com (or signing in locally via IP address) > select your UniFi OS Console > Settings > System.

2. Create ZIP files for the logs. The commands’ format will be: tar -zcvf <file name> <folders path>.

UniFi OS logs: tar -zcvf unifi-core-logs.tar.gz /data/unifi-core/logs/
UniFi local portal (ULP) logs: tar -zcvf ulp-go-logs.tar.gz /data/ulp-go/log/
UniFi Network logs:
- For UniFi Dream Machine consoles:tar -zcvf unifi-logs.tar.gz /data/unifi/logs/
- For UniFi Cloud Key Gen2 consoles:tar -zcvf unifi-logs.tar.gz /usr/lib/unifi/logs
UniFi Protect logs:
- Without external disks: tar -zcvf unifi-protect-logs.tar.gz /data/unifi-protect/logs/
- With external disks: tar -zcvf unifi-protect-logs.tar.gz /srv/unifi-protect/logs/
UniFi Talk logs:
- tar -zcvf unifi-talk-logs.tar.gz /var/log/unifi-talk/
- tar -zcvf unifi-talk-base-logs.tar.gz /var/log/unifi-base/
- tar -zcvf unifi-talk-freeswitch-logs.tar.gz /var/log/freeswitch/
UniFi Connect logs: tar -zcvf unifi-connect-logs.tar.gz /data/unifi-connect/log/
System logs:
- ubnt-systool support /tmp/system
- tar zcvf system.tar.gz /tmp/system

3. Open a new terminal window and run the SCP command to copy the logs from the UniFi OS Console and onto your computer (or system).

Note: The period (.) in the path variable means it will be copied onto the currently opened directory in the terminal. And the asterisk (*) stands for “all”. So the following command will copy everything with the extension tar.gz (i.e. all the logs you prepared in Step 2).

scp root@192.168.1.1:/root/\*.gz .

4. Close both terminal windows to close the sessions.

If other logs are needed, our support agent will guide you and provide the necessary commands.

Source :
https://help.ui.com/hc/en-us/articles/360049956374-UniFi-Getting-Support-Files-and-Logs

UniFi Network – Updating Third-Party, non-Console UniFi Network Applications (Linux – Advanced)

This article provides the steps to update the UniFi Network application to the current stable release on a Debian or Ubuntu system via APT (Advanced Package Tool). If you run into issues following the process described in this article, please take a look at the scripts provided in this Community post that includes UniFi Network software installation on Ubuntu 18.04 and 16.04 and Debian 8/9.

Requirements

In order to update the UniFi Network application via APT, it is necessary to create source files or edit lines in an existing sources.list file with Linux text editors: vi or nano. The repo structure should be permanent, but if there are any changes they will be pointed out in the UniFi Network software version release posts, found in the Release section of the Community.

Before upgrading the UniFi Network application, make sure that you have backed up the UniFi Network Database. You will need to make sure that the user has sudo permissions. For more information about adding a user to sudo list, see this Debian article.

UniFi Network APT Steps

1. Install required packages before you begin with the following command:

sudo apt-get update && sudo apt-get install ca-certificates apt-transport-https

Click to copy

2. Use the following command to add a new source list:

echo 'deb https://www.ui.com/downloads/unifi/debian stable ubiquiti' | sudo tee /etc/apt/sources.list.d/100-ubnt-unifi.list

Click to copy

3. Add the GPG Keys. To add the GPG Keys use one of the two methods described below (Method A is recommended). When using the commands below, it is assumed you have sudo and wget installed, more information about sudo can be found here, and wget here.

User Tip: For Ubuntu 18.04, run the following commands before installing UniFi in step 4.

wget -qO - https://www.mongodb.org/static/pgp/server-3.4.asc | sudo apt-key add -
echo "deb https://repo.mongodb.org/apt/ubuntu xenial/mongodb-org/3.4 multiverse" | sudo tee /etc/apt/sources.list.d/mongodb-org-3.4.list
sudo apt-get update

Click to copy

See an example of what scripts the Community is using to install the UniFi Network application on Ubuntu 16.04 and 18.04 in this Community post.

(Method A) Install the following trusted key into /etc/apt/trusted.gpg.d

sudo wget -O /etc/apt/trusted.gpg.d/unifi-repo.gpg https://dl.ui.com/unifi/unifi-repo.gpg

Click to copy

(Method B) Using apt-key.

sudo apt-key adv --keyserver keyserver.ubuntu.com --recv 06E85760C0A52C50

Click to copy

4. Install and upgrade the UniFi Network application.

Note: On some Distributions, it’s possible an incompatible Java release can be installed during this step. We recommend running the following command before proceeding with this step, to restrict Ubuntu from automatically installing Java 11. If you wish to undo this later, replace “hold” with “unhold”.

sudo apt-mark hold openjdk-11-*

Install and upgrade the UniFi Network application with the following command:

sudo apt-get update && sudo apt-get install unifi -y

Click to copy

5. This step may not be required, depending on the Linux distro you have. If your distro does not come with MongoDB, and it’s not available in their repo, then please see the MongoDB installation guide. You can find the latest installation guide for Ubuntu here, and Debian here. We recommend at least MongoDB 2.6.10. Some users have changed the backend to use MongoDB 3 successfully too.

6. The UniFi Network application should now be accessible at the computer’s configured local or public IP address, by typing that IP address in a browser’s navigation bar (Chrome is recommended). If it is not launching, use the following command: sudo service unifi start.

Other helpful commands are:

To stop the UniFi service: sudo service unifi stop
To restart the UniFi service: sudo service unifi restart
To see the status of UniFi service: sudo service unifi status

We strongly recommend staying with the stable release, but for those users who wish to do otherwise, click here to expand and see possible suite names, as well as code names in the table within.

Log Files Location

Log files will be essential for any troubleshooting you might perform. Find them here:

/usr/lib/unifi/logs/server.log
/usr/lib/unifi/logs/mongod.log

If your application is running on a Unix/Linux based system, then you will require superuser (sudo) privileges to access these log files.

User Notes & Tips

These notes have been added thanks to user collaboration. Click to expand.

Source :
https://help.ui.com/hc/en-us/articles/220066768-UniFi-Network-Updating-Third-Party-non-Console-UniFi-Network-Applications-Linux-Advanced-

UniFi Network – Updating Third-Party, non-Console UniFi Network Applications

We recommend hosting your Network Application on a UniFi OS Console for the most seamless updating experience. In addition to providing the ability to toggle automatic Network Application updates, you can also initiate manual updates through the GUI.

Updating the Network Application

Updating your Network Application is very similar to the initial setup. You can download the latest version here.

You will be required to close any running instances of the Network Application prior to the installation. Do not worry, your network will still continue to function as normal (devices will remain connected with internet access, and traffic will continue to be routed).

After executing the file, the setup wizard will guide you through the process of updating your application. We always recommend downloading a backup file, found in your System Settings.

Note: macOS users may be required to move the downloaded file into the Applications folder, or right-click > open the file in order to begin the installation.

(Advanced) Updating via CLI on Linux-hosted Applications

It is also possible to use APT for managing updates on Debian and Ubuntu based installations. You may refer to this article for more details. This should only be attempted by users with appropriate knowledge of Linux.

Source :
https://help.ui.com/hc/en-us/articles/6330410381335-UniFi-Network-Updating-Third-Party-non-Console-UniFi-Network-Applications

UniFi Network – Self-Hosting your UniFi Network Without a Console (Advanced)

We strongly recommend that users opt for a UniFi OS Console instead of self-hosting the Network Application on third-party operating systems.

Self-hosting the UniFi Network application on a home computer or 3rd party virtual machine (VM) requires extensive knowledge of computer engineering, networking, and security. Invalid host specifications or configurations may lead to system crashes, poor performance, and compromised network security.

A UniFi OS Console, on the other hand, takes all the guessing out of the picture as it is already optimized for running all of our UniFi Applications. It is also a significantly more secure solution for remote access, as this is hosted on your physical premises, as opposed to a third-party virtual machine in the cloud.

Note: Although a UI SSO account is required for remote access, it is possible to setup and use UniFi OS Consoles as local-only devices without the need for an SSO account.

For advanced users hoping for a scalable cloud-hosting approach, we also offer our own UniFi OS Cloud Console.

Configuration of third-party hosts is outside of Ubiquiti’s official support scope. If you still wish to self-host the UniFi Network Application, please be aware of the risks and proceed with caution.

Download and install the UniFi Network Application

The UniFi Network Application may be downloaded for Microsoft Windows, macOS, and Linux from this page. The Network application is provided as a simple installer for Microsoft Windows and macOS hosts.

For Linux, a .deb file is provided. This can be installed using the dpkg command on Debian or Ubuntu.

After installing the UniFi Network Application, you may launch it and follow the instructions to complete setup. You can access the configuration page by typing https://<IP_of_Network_Application_host>:8443 into the navigation bar of a browser while the application is running.

Frequently Asked Questions

What are the UniFi Network application system requirements?
At a bare-minimum, we recommend the following system requirements (make sure to read the Release Notes for more details about a particular version):

Operating system:
- Linux: Ubuntu Desktop / Server 16.04; Debian 9 “Stretch”
- Windows: Windows 10; Windows Server 2016
- macOS: Mavericks 10.9, 10.10 Yosemite, 10.11 El Capitan, 10.12 Sierra, 10.13 High Sierra, 10.14 Mojave, 10.15 Catalina.
CPU: x86-64 Processor (Intel / AMD x64 Processors)
RAM: 2GB
Network: 100Mbps Wired Ethernet
HDD: Minimum 10GB free (20GB or more preferred)
Java: Java Runtime Environment (JRE) 8
Web Browser: Google Chrome
MongoDB: version 3.2 or later. Mongo is offered bundled: default is 2.4.14 (for macOS and Windows only).

Note: You will need to continually increase your system specs as you begin to adopt and manage more devices.

Does the UniFi Network application have to run at all times?
Although this is not required, we strongly recommend running the UniFi Network Application at all times. This enables you to configure your system at all times. It is also a requirement for proper statistics and reporting.

I’m getting a Java-related error during setup, what do I do?
The UniFi Network application requires Java, so you’ll need to install Java 8 for your specific platform before re-running the installer.

The install is not finishing successfully, what could it be?
Make sure that all system requirements above are met and that all ports used by UniFi are opened.

I’m getting a “Your connection is not private” security warning when accessing the UniFi Network Application in my browser, should I be concerned?
No, there is nothing to worry about. Simply proceed to the next page by clicking Advanced > Proceed.

Source :
https://help.ui.com/hc/en-us/articles/360012282453-UniFi-Network-Self-Hosting-your-UniFi-Network-Without-a-Console-Advanced-

UniFi Network – Understanding and Implementing Minimum RSSI

This article explains what Minimum RSSI is and how to configure it in the UniFi Network application. We only recommend using this if you are familiar with basic RF theory as misconfiguration may result in performance degradation of your network.

How Minimum RSSI works

Received Signal Strength Indication (RSSI) is a value indicating the perceived signal level of a wireless client from the AP’s perspective. The Minimum RSSI value is set individually on each AP and indicates the minimum signal level required for a client to remain connected.

The main purpose of this is to assist with a client’s roaming between two nearby APs. It prevents a device getting “stuck” connected to the initial AP at a weaker signal strength as opposed to roaming to a new AP that may be more optimal. Once the signal drops below the Minimum RSSI value set, the initial AP will kick the client so that it can reconnect to the new AP.

Once an AP kicks a client (by sending a de-authentication packet), it is up to the client to find a better AP to connect to. It may connect back to the same AP, especially if it is the only one within range. Since the signal strength still does not meet the Minimum RSSI, it will again be booted. Improper tuning can thus result in network instability. For this reason, it is important to realize that there is no one size fits all and you should carefully test your configuration to avoid introducing connectivity problems.

How to determine and configure Minimum RSSI

Minimum RSSI is can be enabled within the UniFi Network Application by selecting an AP in UniFi Devices and then navigating to Settings in the side-panel of the selected device. Once enabled, this can be manually set for your 2G and 5G radios independently.

You can view the Signal Strength for your current wireless clients by clicking on a device in the Client Devices tab. The signal is measured in units of dbm (decibels per milliwatt). You will notice that this is a negative number because the power is less than 1 mW:

dbm = 10 log P₁/1mW
0 dBm = 1 mW
-10 dBm = 0.1 mW
-20 dBm = 0.01 mW, and so forth

A value close to 0 indicates high signal quality, whereas a larger negative value indicates poor signal quality. Remember, you need to granularly select the appropriate value for each AP and avoid using a single value everywhere.

Other Considerations

There are many factors that can affect the a client’s RSSI at the AP side including distance, building materials, objects, interference, etc. As much as we would love to give a recommendation, it really isn’t this simple. It’s safe to say -80dBm would be a starting point for standard home or office configurations, but there are too many environmental variables so you should have caution at all times.

The best method to determine appropriate Minimum RSSI values is to perform a site survey. This can be done by testing the signal strength of various wireless clients at different distances. Each device will have different antenna configurations and will thus perform differently in the same geographic location. You want to connect to an SSID, make it specific to that AP (an override on that SSID), and then roam to what you would consider the outer edge of the desired coverage area. Mark the client’s RSSI, and then take a couple more points. The more data you gather, the better idea you’ll get for the minimum RSSI value to use.

Source :
https://help.ui.com/hc/en-us/articles/221321728-UniFi-Network-Understanding-and-Implementing-Minimum-RSSI

UniFi – HDD Requirements and Compatibility

HDDs are not required for normal operation, however they expand the functionality by enabling things such as video recording from UniFi Protect, and call recordings and voicemails from UniFi Talk.

We strongly recommend using the UniFi 8TB HDD for UniFi OS Consoles with a 3.5” HDD bay (UDM Pro, UDM SE, UNVR, and UNVR-Pro). These are specialized, industrial-grade drives that can support continuous read and write operations required by a video surveillance system.

Cloud Keys (UCK-G2-PLUS) require a 2.5” HDD for which we strongly recommend continuing to use the drive shipped natively with your equipment. If it will be replaced, the Toshiba 2.5″ 5400RPM 1TB HDD (MQ01ABD100V) appears most stable according to internal testing.

Incorrect drives will result in premature failure which can degrade your entire network’s performance, as well as prevent remote management.

Third-party Drives

If you insist on using a third-party drive, it should meet the following criteria:

It fits inside the HDD tray
- 3.5” for Dream Machines and Network Video Recorders
- 2.5” for the UCK Gen2 Plus
It is a surveillance-grade drive designed for continuous load
- These are generally 7200RPM, CMR Drives. SMR drives are not recommended and may lead to performance issues, loss of video footage, or even system crashes.
It offers at least 1 TB of storage. No maximum HDD capacity has been established.

If you’re using multiple HDDs with your UniFi OS Console, they must all be the same size.

The total usable storage capacity will be affected based on whether either the redundancy level is set to One Disk (RAID1 / RAID5) or Half of Disks (RAID10).

Incompatible HDDs

Some hard drives require an additional 12V external power supply. These hard drives are not supported by the UCK Gen2 Plus or the UNVR.

The following is a list of 3.5” drives that are confirmed to be incompatible with our UniFi OS Consoles:

Vendor	Series	Model	Capacity	Notes
Seagate	SkyHawk	ST10000VX0004	10TB	Does not fit the drive tray.
Seagate	Ultrathin	ST500LT032	500GB	Does not have bottom screws.
Western Digital	UltraSlim	WD5000MPCK	500GB	Does not have bottom screws and connectors do not fit the tray.
Any	Any	SMR Drives	Any	Drives fit the tray but cause issues.

If you have questions about a particular hard drive or need help choosing a hard drive, please reach out to the Ubiquiti Community for insights and recommendations.

Source :
https://help.ui.com/hc/en-us/articles/360037340954-UniFi-HDD-Requirements-and-Compatibility