MainWP Lighthouse - WordPress Plugin

A Practical Guide to Setting Up and Using MainWP Lighthouse

MainWP Lighthouse is not for one-off curiosity about speed scores. It is built for ongoing quality checks across sites already connected to your MainWP Dashboard. In this guide, we will walk through how to prepare the dashboard, where to enable the extension, which settings to review first, how to run an audit for a single site or your entire network, how to read the results without fooling yourself, and what to do when reports fail to generate or produce inconsistent scores.

This guide is written for anyone managing multiple sites, whether that is a site owner, freelancer, support agency, or technical administrator who needs visibility not just into WordPress updates, but also into performance, accessibility, best practices, and SEO across client projects. We will skip the marketing copy and focus on the actual workflow instead: preparation, installation, API key setup, bulk audits, scheduling, notification thresholds, report review, automation with WP-CLI and the REST API, troubleshooting, and choosing comparable alternatives.

One limitation is important to understand up front: the extension does not speed up your site by itself. It shows where the problems are, helps you compare sites side by side, lets you run scheduled checks, and makes it easier to spot projects that need optimization. Actual fixes for images, caching, JavaScript, accessibility, or SEO still have to happen in the theme, plugins, server settings, and content of each individual site.

What Problem It Solves Inside MainWP

Standard PageSpeed Insights is convenient when you need to check one page quickly. But that approach breaks down fast when you are maintaining a network of sites: the administrator ends up opening dozens of tabs, copying URLs, waiting for mobile and desktop results, and then trying to remember which projects got worse after a theme update, a new banner, or a caching change. MainWP Lighthouse moves that entire process into the normal MainWP workflow: the sites are already listed in your table, the audit runs from the central dashboard, and the results can be reviewed project by project.

The extension uses the Google PageSpeed Insights API. That API returns Lighthouse data and a report for the URL being tested: performance, accessibility, best practices, and SEO. Inside MainWP, its real value is not as a substitute for manual optimization, but as an early warning system for declining site quality. If a site suddenly drops in mobile performance or starts showing a weak SEO score, the administrator sees it in one place and can investigate immediately.

The strongest advantage of this format is comparison. A standalone score of 78 says very little on its own. But if most sites are still sitting near the green zone after an overnight desktop audit and one client site suddenly drops below your defined threshold, that becomes an actionable signal: check recent changes, caching, media, third-party scripts, ad blocks, analytics widgets, the theme, and plugins.

That said, a Lighthouse score should never become your only quality metric. PageSpeed includes lab data collected under controlled conditions and field data based on real users and enough usage history. Smaller sites may have no field data at all. That makes MainWP Lighthouse a strong fit for routine technical hygiene, but final optimization decisions should still be based on the actual page, the business use case, and the important page templates involved.

Who This Extension Is For, and When It Is Not Worth Using

MainWP Lighthouse makes the most sense when MainWP is already your operational hub. If you only manage one site, it is usually easier to open PageSpeed Insights manually or run Lighthouse in Chrome DevTools. The extension starts to make sense when you manage multiple sites across different clients, need periodic oversight, and do not want to maintain a separate spreadsheet of manual checks.

Good Use Cases

The clearest example is agency support. A team maintains client WordPress sites, handles updates, monitors security, and wants to add page quality checks to its standard process. In that setup, MainWP Lighthouse helps create a clear cycle: run the audit, identify poorly scoring sites, log optimization tasks, rerun the audit after fixes, and show the client how the site is trending over time.

The second use case is a freelancer or administrator responsible for several smaller projects. Here the value is not advanced analytics, but time savings. Instead of logging into every site one by one, you can quickly check a group of projects after a mass update to a theme, caching plugin, page builder, or ad insertion system.

The third use case is technical review before handing a site over to a client. After building a landing page, catalog, or corporate website, it is useful to run an audit, compare mobile and desktop results, fix obvious issues, and save the report as your baseline. It does not replace hands-on testing on real devices, but it helps catch basic problems like oversized images, poor contrast, missing meta descriptions, or unnecessary render-blocking resources.

When a Different Approach Is Better

If you only have one site, do not use MainWP, and have no plans to connect child sites, the extension adds an unnecessary layer. For one-off checks, PageSpeed Insights, Chrome DevTools, or local Lighthouse will be faster. If you need continuous Core Web Vitals monitoring for real users, you should look at dedicated observability tools instead, because scheduled Lighthouse audits are not the same as full user experience monitoring.

If your main goal is automatic optimization, image compression, caching, deferred JavaScript loading, or critical CSS generation, MainWP Lighthouse does not solve that directly either. It will highlight trouble areas, but the actual fixes still need to come from other tools: a caching plugin, CDN, server tuning, theme optimization, third-party script cleanup, and content improvements.

What to Check Before Installation

Preparing for MainWP Lighthouse comes down to three things: your MainWP dashboard itself needs to be stable, your child sites need to sync properly, and the Google PageSpeed Insights API needs to be available for recurring requests. If you skip this step, the first problem will look like "the extension does not work," even though the real cause may be timeouts, an unreachable site, limited dashboard resources, or an invalid API key.

MainWP Dashboard Health

MainWP extensions are installed on the dashboard site, not on the managed child sites. That distinction matters. If you upload the add-on to a client site, you will not get the central interface you expect, and troubleshooting will only get more confusing. Make sure your dashboard runs on a dedicated WordPress install, meets current PHP, memory, cURL, and execution-time requirements, and does not produce recurring errors when syncing child sites.

For larger site networks, execution time limits and cURL timeouts matter even more. A Lighthouse check does not always finish instantly: PageSpeed has to fetch the page, analyze it, and return the report. If your dashboard is already running short on resources during normal MainWP syncs, a bulk audit will only make that more obvious. Before installing the extension, open your site list, run a normal sync, confirm that child sites respond properly, and make sure the dashboard server stays stable under load.

Availability of the Pages Being Tested

PageSpeed Insights analyzes a URL as an external service. The page must be publicly accessible, not protected by basic authentication, not blocking Google, not returning a server error, and not requiring a logged-in session. For private staging sites or local URLs, the report may not generate at all. If you need to test a restricted page after login, Chrome DevTools Lighthouse in a browser where you are already signed in is usually the better option.

You should also confirm which page you actually want to evaluate. The home page may be fast while a product page, blog post, or lead form is slow. MainWP Lighthouse is useful for recurring site-level monitoring inside MainWP, but the practical value of each report depends on which URL is being tested and how well it represents the real user journey.

Google PageSpeed Insights API Key

Google's official documentation says you can try the PageSpeed Insights API without a key, but a key is recommended for frequent or automated requests. In MainWP's Lighthouse documentation, the key is listed as a required extension setting. It is best to prepare it ahead of time, especially if you plan to audit an entire network rather than just one site.

Do not expose your API key in articles, reports, public tickets, or third-party chats. In the MainWP interface, enter it only in the dedicated extension settings field. If the key is ever exposed by mistake, regenerate it in Google Cloud Console and update the setting immediately.

Installing and Enabling the Extension for the First Time

MainWP Lighthouse is installed from the dashboard. MainWP includes a shared Add-ons area where add-ons are divided into extensions and integrations. Lighthouse falls into the Google PageSpeed Insights API integration category, so after installation it is important not only to activate the add-on, but also to complete the settings that make the audit actually usable.

Installing Through Manage Add-ons

The recommended path is to open MainWP > Add-ons > Manage Add-ons, go to the add-on installer, find Lighthouse, select it, and start the installation. Once the installation finishes, activate the add-on. If MainWP Pro is already connected and your MainWP key is valid, the built-in manager is usually the easiest route because it shows which add-ons are available and whether they are already installed.

An alternative is to upload the ZIP archive through the standard WordPress plugin installer on the dashboard site. That approach makes sense if you downloaded the archive from your MainWP account and want to install it manually. In either case, make sure the upload is happening on the dashboard site itself. You do not need to install this extension on child sites.

First Visit to the Settings

After activation, open the Lighthouse section inside MainWP Add-ons. The first required step is to paste in your Google PageSpeed Insights API key and save the settings. Until the key is saved, audits may not run at all or may be useless for regular work. After that, run a test audit for one site before launching a full audit across the entire network.

1. Open MainWP > Add-ons > Lighthouse > Settings.
2. Paste your Google PageSpeed Insights API key into the settings field.
3. Select the report language if the interface offers that option.
4. Choose an audit strategy: Desktop, Mobile, or Both.
5. Save the settings and go to the extension dashboard.
6. Run an audit for one test site and wait for it to finish.

A test audit helps separate a settings issue from a site-specific issue. If one public site audits successfully and another does not, the problem is usually tied to the second site's availability, blocked requests, redirects, response time, or page instability.

Core Settings: Strategy, Language, Threshold, and Execution Time

MainWP Lighthouse settings should be treated as measurement rules, not just setup details. If you choose Desktop only, you may miss mobile issues. If you set the notification threshold too high, the dashboard will become noisy. If execution time is too short for a large network, some audits may never finish.

Strategy: Desktop, Mobile, or Both

The Google PageSpeed Insights API supports either desktop or mobile analysis. MainWP documentation says the extension lets you choose Desktop, Mobile, or Both. For most sites, the right starting point is Both, because mobile and desktop results often differ significantly. A heavy slider, map widget, video hero, or ad script may be barely noticeable on desktop but hit mobile performance hard.

If your network is large and the audit takes too long, you can temporarily start with Mobile as the stricter real-world scenario and run Desktop manually before reporting or after major changes. But it is not a good idea to ignore Desktop permanently if the project has a B2B audience, corporate users, or administrators who primarily work on desktop devices.

Language: Report Language

The language setting affects how the formatted results are localized. For a Russian-speaking team, choosing Russian may be more practical if non-developers also read the reports. For a technical team used to the English names of Lighthouse audits, English may be the better choice because it makes it easier to search Google's documentation and match the report against DevTools terminology.

The language setting does not change the audit logic itself. It is a readability and support decision. If you deliver client reports in Russian, it makes sense to align the report language with whoever is expected to review and approve the fixes.

Notifications Threshold

The notification threshold tells the extension when to alert you because a score falls below a selected value. Do not set it mechanically at the maximum. A new project with a clean theme and strong caching can justify a stricter threshold. An older site with a heavy theme, lots of widgets, and ad inserts will turn an overly high threshold into constant noise instead of a manageable task list.

A practical approach is to run a few manual audits first, learn the normal scoring range, fix obvious issues, and then set the threshold slightly below the working baseline. That way, a notification signals a change, not a constant reminder of old technical debt.

Automatically Audit Sites and Frequency

Automatic audits can usually be scheduled daily, weekly, or monthly if those intervals are available in the interface. For a small site network, a daily check may be perfectly reasonable. For a larger portfolio, it is usually better to start weekly or monthly, especially if the dashboard runs on limited hosting. After major changes to the theme, page builder, caching plugin, or marketing scripts, you can still trigger a manual audit outside the regular schedule.

Scheduling only makes sense when the foundation is stable. If the API key does not work, child sites fail to sync from time to time, or the dashboard server is already hitting its limits, automation will only repeat the same failure.

Maximum Execution Time, Script Run Time, and Throttling Delay

The extension includes time-related settings such as Maximum execution time, Maximum script run time, and Throttling delay time. These matter when reports do not finish or when the tested servers respond slowly. Raising the limits can help, but it is not a universal fix.

If reports are failing, start by testing one site manually. Then increase the limits gradually and watch whether the result changes. A throttling delay can slow report generation, but on weaker hosting it can sometimes lead to more stable output. If the problem only appears on one site, do not immediately change the global settings for your entire network. In that case, the better path is to investigate that specific project.

Running Bulk Audits Across Child Sites Without Creating Chaos

The most useful part of MainWP Lighthouse is not the audit button itself, but the ability to build a clean process for a group of sites. The documentation describes several ways to launch audits: Audit All Sites, Bulk Actions for selected sites, and Audit Site from the action menu of a specific site. Each one is useful, but only if you use it deliberately.

When to Run Audit All Sites

A full network audit makes sense after initial setup, before a regular reporting cycle, or after a broad change that affects many projects. For example, you might update a shared set of optimization plugins, change CDN rules, introduce a new image policy, or roll out a theme update across similar sites. In those situations, a full audit helps you see where the changes went smoothly and where quality dropped.

What you should not do is run a full network audit every time you need to inspect one problematic site. A bulk audit consumes time, adds load to the dashboard, and can distract from the actual issue. For targeted troubleshooting, use a single-site audit.

Using Bulk Actions for Selected Groups

Bulk Actions is useful when sites can be grouped meaningfully: by client, theme family, hosting tier, plugin stack, region, or a shared update history. That gives you cleaner comparisons. If only the sites on one hosting platform decline, your conclusion will be different than if a single landing page drops randomly.

Before running a bulk check, make sure groups, tags, or client relationships are used consistently in MainWP. Once that is in place, Lighthouse becomes part of operational oversight rather than just a long list of scores.

Auditing One Site as a Diagnostic Mode

A single-site audit is what you use when investigating a complaint, checking work after optimization, reviewing changes before publishing, or looking into a suspected issue. For example, a client reports that the home page feels slow after a new content block was added. You run the audit only for that site, review the mobile and desktop scores, inspect the warnings, and then repeat the audit after the fix.

For a more precise picture, it helps to open the same URL in PageSpeed Insights or Chrome DevTools. If MainWP and PageSpeed point to similar issues, you can trust the direction of the diagnosis. If the results differ sharply, remember that Lighthouse scores can vary with network conditions, server state, caching, and third-party resources.

How to Read the Report Without Mistaking Noise for Signal

A Lighthouse report looks simple because it starts with numeric scores, but poor interpretation leads to bad decisions. A score of 90 or above is generally considered good for a lab category, 50 to 89 indicates room for improvement, and anything below 50 signals a serious issue. But a single number does not tell you what actually needs to be fixed.

Performance: Focus on Causes Before Scores

Performance usually gets the most attention, but chasing a single number is rarely useful. Look at the concrete signals: images, render-blocking resources, unnecessary JavaScript, oversized DOM, slow server response, layout instability, and heavy third-party scripts. Some issues can be solved with caching and image settings, while others require changes to the theme, builder, or content itself.

If the audit shows a weak mobile score, check whether the mobile version is loading the same heavy hero section, video, carousel, map, or widget bundle. Sometimes the improvement does not come from "speeding up the whole site," but from removing one poorly chosen block from a key page.

Accessibility: Do Not Treat It as a Secondary Metric

Lighthouse accessibility checks cover the part of accessibility that can be tested automatically: contrast, element labels, alt attributes, structure, and other machine-detectable signals. It is not a full accessibility audit, but it is a very useful filter for obvious mistakes. If a site scores poorly, do not dismiss it as "not important for SEO." Accessibility problems often overlap with real UX problems: text is hard to read, buttons are unclear, and forms are badly labeled.

Best Practices and SEO: Basic Page Hygiene

Best Practices helps surface insecure or outdated approaches, browser errors, HTTPS issues, and other technical warnings. The SEO audit checks the basic elements that help search engines understand a page: meta descriptions, valid links, response status, indexability, and mobile readability. These checks do not guarantee ranking gains, but they do help prevent avoidable technical mistakes.

Do not promise traffic growth to a client just because Lighthouse is green. A strong report shows that the page is technically cleaner, but SEO results still depend on content, demand, competition, links, indexing, and user behavior.

Field Data and Lab Data

PageSpeed Insights separates real-user data from lab diagnostics. New pages or low-traffic URLs may have no real-user data at all. Lab metrics are useful for debugging, but they simulate test conditions and may not match what real users experience. That is why MainWP Lighthouse reports should capture not just the score, but also whether the problem is repeatable.

A practical rule is this: if one audit shows a poor result, rerun it after the cache is warmed and when the server is not handling other heavy work. If the issue repeats and lines up with specific Lighthouse warnings, then it is worth creating a fix task.

Practical Workflow: Weekly Audits for Client Sites

Here is a real-world example. An administrator has a MainWP Dashboard connected to several client sites: corporate sites, a blog, a small store, and service landing pages. The goal is to identify declining quality once a week without spending the morning manually checking PageSpeed Insights site by site.

Goal

Build a recurring list of sites where the mobile or desktop score has dropped below the working threshold, then review the specific report and assign the needed fixes. The real outcome is not "every site became perfect," but a clear operating process for detecting and validating problems.

Preparation

Before starting, the administrator confirms that the MainWP Dashboard syncs with child sites, the API key is saved, the strategy is set to Both, and automatic auditing is enabled at a reasonable frequency. Sites still protected by a password or living on local addresses are not included in the standard audit process, because PageSpeed will not be able to fetch them correctly.

Steps

1. Open MainWP > Add-ons > Lighthouse > Settings and confirm that the API key is saved.
2. Select the Both strategy so you can see both mobile and desktop results.
3. Enable automatic auditing and choose a frequency that does not overload the dashboard.
4. Set the notification threshold only after a few test audits, not before.
5. Run the first full audit manually to establish a baseline.
6. Sort the results by the weakest scores and open the reports for the affected sites.
7. After making fixes, rerun the audit only for the sites that changed.

Validation

After the first cycle, you should be able to see which sites remain consistently healthy, which need optimization, and which cannot be checked because of access issues, timeouts, or API errors. What matters is not a single green score, but a repeatable process: the audit runs, weaker sites are identified, reports open correctly, and fixes can be confirmed with a follow-up check.

Nuance

If one site sometimes gets a good score and then suddenly collapses without any code changes, check the cache, third-party scripts, server response, background tasks, ad inserts, and hosting stability. Lighthouse is sensitive to test conditions. Look for repeatability first, then draw conclusions.

Automation with WP-CLI and the REST API

MainWP Lighthouse is not just useful in the interface. The official documentation also describes how to launch audits through WP-CLI and use REST API routes for extensions. Not everyone needs that, but for an agency or technical team, automation makes it possible to integrate audits into an internal operating process.

WP-CLI for Controlled Execution

The WP-CLI command is useful when the dashboard is maintained by a technical specialist who wants to trigger audits on a server schedule, from an internal checklist, or after a batch of updates. MainWP documentation includes commands for auditing specific site IDs and for auditing all sites:

wp mainwp-lighthouse audit 125,126
wp mainwp-lighthouse audit --all

Before using this approach, make sure WP-CLI is running in the context of the dashboard site and that the user has access to the correct WordPress installation. Do not run the bulk command when the server is already busy with backups, updates, content imports, or other heavy jobs.

REST API for External Workflows

MainWP REST API v2 uses a Bearer token and routes such as /wp-json/mainwp/v2/. The documentation for Lighthouse extension endpoints lists routes for triggering audits and retrieving results: auditing all supported sites, auditing one site, getting results for all sites, and getting results for a single site. That makes it possible to build an internal agency dashboard or reporting system that pulls Lighthouse status without a manual login to the MainWP Dashboard.

curl -X POST \
  -H "Authorization: Bearer YOUR_API_KEY" \
  "https://your-dashboard.com/wp-json/mainwp/v2/lighthouse/audit"

REST API secrets should never be stored in client notes, public repositories, or HTML guides. Create a separate key with only the permissions you actually need, store it in a secure vault, and disable it if the integration is no longer used. If your dashboard is local and not publicly reachable, an external client will not be able to call the REST API directly.

How to Keep Automation from Turning into Noise

An automated audit needs clear ownership. If the team schedules daily runs but nobody reviews the reports, the system becomes background noise. It is better to run audits less often and tie the output to an actual task: verify a decline after updates, attach the report to maintenance work, open an optimization ticket, and rerun the audit after the fix.

How to Verify the Result After Setup and Optimization

Once MainWP Lighthouse is enabled, do not just confirm that it runs. Confirm that the result is actually usable. The extension should answer four questions: which sites were checked, where the scores are worse than expected, which problems keep repeating, and whether the fix actually helped.

Minimum Review After the First Audit

• The Lighthouse list shows results for the selected site or group of sites.
• The report opens from the action menu for a specific site.
• Mobile and desktop strategies appear exactly as chosen in the settings.
• The notification threshold does not create constant noise from already known legacy issues.
• A follow-up audit after a fix either shows a change or confirms that the issue is still there.

If you optimized a page, do not compare one run before and one run after as if they were absolute truth. Repeat the test, make sure the cache is warm, and verify that the server is not under parallel load. For a client, it is better to show a short chain of evidence: the problem, the fix applied, the follow-up result, and the limits of the test itself.

What Counts as a Good Result

A good result does not always mean a perfect score. On some sites with lots of third-party services, maps, analytics, forms, booking widgets, or ad networks, pushing the score to the maximum may be too costly or may even hurt the business. In that case, MainWP Lighthouse is most useful as a way to surface the most expensive problems and keep quality from quietly drifting downward.

A practical standard is this: critical templates load faster, obvious accessibility issues are resolved, the SEO foundation is intact, scores stay above the agreed threshold, and the team understands which remaining issues are accepted consciously as tradeoffs.

Widgets, Columns, and a Faster Portfolio Overview

MainWP Lighthouse plays another important role: it helps bring site quality signals into the places where the administrator is already working, not just into a separate report. The documentation notes that Desktop and Mobile Performance Score columns can be enabled in the Manage Sites table through Page Settings, and widgets are available both on the overall Overview page and on each child site page. That changes team behavior: instead of treating speed checks as a separate task, quality becomes part of the daily portfolio review.

Columns in Manage Sites

Table columns are useful for sorting and quickly spotting weaker projects. If your site list is large, you do not need to open every report individually. Just display the mobile and desktop scores, sort the table, and see which sites need attention. This is especially useful after a regular audit, because you are looking at both update status and page quality in a single operational view.

What you should not do is enable the columns and forget the context behind them. A score in a table is a starting point for diagnosis, not a diagnosis by itself. If a site is near the bottom of the list, open the report, review the specific warnings, and check whether the issue repeats. For client projects, it helps to add an internal note such as "low mobile score due to third-party booking widget" or "rerun audit after image optimization." That turns the table into a real working tool instead of a decorative score counter.

Widget on the Main Overview Page

The widget on the overall Overview page shows the best-performing and worst-performing sites by score. That is useful for morning checks: the administrator opens the dashboard and immediately sees where the situation looks weakest. This widget works especially well together with a notification threshold. The threshold catches drops below a defined level, while the widget shows the relative picture: which sites stay healthy, which always hover near the edge, and which have suddenly fallen out of the normal range.

For an agency, it is worth agreeing in advance how the team responds to this widget. For example, if a site appears among the weakest sites for the first time, someone reviews it manually and reruns the audit. If it has been there for a long time because of a known business tradeoff, the team does not open the same task over and over, but documents the reason in client notes or the internal process. Without that discipline, any monitoring system turns into fatigue.

Widget on the Child Site Page

The widget on a specific child site page helps you judge movement over time. MainWP documentation says it shows Desktop and Mobile scores and the change since the previous audit. That is far more useful than a single isolated number. If the score was low and stays low, that is one kind of task. If the score was stable and suddenly drops after an update, that points you toward recent changes: a new plugin, ad code, a heavy image, a builder block, caching changes, or a redirect.

This widget is especially useful when validating fixes. Suppose you compressed the home page images, disabled an unnecessary script, and enabled deferred loading. After the follow-up audit, you can do more than just open the full report. You can also see whether the score changed directly on the site page inside MainWP. If the widget shows improvement and the specific warnings are less severe, the result is ready to share in a client report or close as an internal task.

Do not evaluate a specialist's work based on one widget alone. Use it as navigation. It shows where to look, but the quality of the fix still has to be confirmed by the actual audit details, a follow-up check, and a manual review of the page.

How to Turn the Report into a Fix Plan

The most common mistake with Lighthouse is opening the report, seeing a long list of recommendations, and trying to fix everything at once. For a client site, that is rarely the smartest approach. Some items have a major impact, some depend on third-party services, some require theme or content changes, and some are acceptable tradeoffs. MainWP Lighthouse helps you find the problems, but the fix plan still has to be built separately.

Group Issues by Ownership

Once you open the report, it helps to split the issues into four buckets. First is content: heavy images, oversized hero blocks, unoptimized video, and unnecessary embeds. Those can often be fixed without development. Second is site configuration: caching, minification, deferred loading, CDN, lazy loading, and fonts. That is usually handled by the administrator or performance specialist. Third is theme and code: oversized DOM, heavy components, render-blocking scripts, and inaccessible interface elements. That is the developer's or theme author's territory. Fourth is external services: maps, chat tools, analytics, pixels, and booking widgets. There the question becomes what matters more to the business.

This kind of separation helps you avoid overpromising. If Lighthouse is complaining about a third-party chat widget, removing the widget may improve the score but hurt sales or support. In the client report, it is more honest to say: "the low score is partly caused by a third-party widget; we recommend testing deferred loading or accepting it as a business tradeoff." That is better than blindly chasing a green circle.

Start with Repeatable, Low-Risk Fixes

Across a site portfolio, the same problems tend to repeat: uncompressed images, missing media dimensions, too many third-party fonts, render-blocking CSS and JS, weak caching, or unnecessary builder blocks. If MainWP Lighthouse highlights the same issues across multiple projects, that is a sign to make a systemic improvement. For example, you might update your internal image-prep standard, your caching setup template, or your publishing checklist for new pages.

Prioritization should usually be based on impact and risk together. Image compression, a WebP or AVIF policy, lazy loading, removing unused blocks, and checking meta descriptions are usually safer than deep theme refactoring. Changing JavaScript loading order may help a lot, but it also requires testing forms, checkout flows, interactive blocks, and analytics. That is why every fix should be followed by a repeat audit and a manual review of the key page.

Save a Baseline Before You Change Anything

Before optimization begins, save the original state: the score, audit strategy, tested URL, main warnings, and the date of the internal review in your own system. We do not use dates in the article itself, but in the actual workflow they matter because memory is unreliable. After the fix, rerun the audit and compare not just the overall score, but the specific items behind it. If the score improves but an important warning remains, the task is not done yet. If the score barely changes but you removed a critical accessibility or SEO issue, that is still a meaningful result.

For agencies, a short internal note works well: "Before: mobile performance below threshold, mainly caused by images and render-blocking JS. Done: compressed hero image, adjusted caching, deferred widget loading. Verified: follow-up audit, manual home page review, lead form submits correctly." That format is clear for both the technical specialist and the project manager.

Do Not Fix Lighthouse by Breaking the User Journey

Some recommendations may conflict with the business purpose of the page. A heavy booking widget may be critical for conversion, a map may be necessary for helping users find the office, and a first-screen video may be important for presenting the product. The answer is not always full removal. Often the better approach is to defer loading, replace autoplay with click-to-play, show a static cover image, reduce the widget footprint, or load the script only on the pages that actually need it.

After those changes, do not just recheck Lighthouse. Recheck the user flow itself: the form still submits, the map still opens, buttons still work, the cart still functions, analytics still records events, and the mobile menu still behaves correctly. MainWP Lighthouse is good at finding technical issues, but the final decision always has to respect the real user journey.

Common Problems and Troubleshooting

Most MainWP Lighthouse issues come down to three areas: the API key, the availability of the page being tested, and dashboard resource limits. Below is a practical troubleshooting flow that avoids risky changes to WordPress core, the plugin, or the theme.

The Audit Does Not Start or Fails Immediately

Symptom: after clicking Audit Site or Audit All Sites, no result appears, or the interface shows an error. Possible causes include a missing Google PageSpeed Insights API key, a key copied with extra characters, the dashboard being unable to send the request through cURL, the site being unavailable to PageSpeed, or the selected URL returning an error.

Check the key in the Lighthouse settings, save the settings again, and run an audit for one known public site. Then open the same URL manually in PageSpeed Insights. If PageSpeed cannot audit the page, the issue is not MainWP. If the page works manually, check the dashboard limits, cURL behavior, and WordPress error logs.

Reports Do Not Finish for Some Sites

Symptom: some sites are audited successfully, while others hang or never receive a report. Possible causes include a slow server on the affected site, protection against external requests, an unstable redirect, execution limits that are too low, or parallel load on the dashboard.

Start by testing one problematic site separately. If the error repeats, temporarily raise Maximum execution time or Maximum script run time in the extension settings, if your server supports those values. If that still does not help, do not keep raising the limits forever. Check the URL availability, server response, firewall, CDN, and bot-blocking rules.

Scores Vary Widely Between Runs

Symptom: a site with no visible changes gets noticeably different scores. That can happen because Lighthouse is variable by nature: network conditions, server resources, cache state, third-party scripts, ad networks, and external widgets all influence the result. PageSpeed also separates lab data from real-user data, and real-user data may be missing for low-traffic pages.

Do not make decisions based on a single run. Repeat the audit after the cache is warmed, test the same page in PageSpeed Insights, and compare the specific warnings. If only the total score changes but the issue list stays mostly the same, fix the recurring causes. If each run points to different bottlenecks, look for an unstable external resource or a hosting issue.

Notifications Arrive Too Often

Symptom: the notification threshold is configured, but the team gets too many alerts and stops reacting to them. The usual cause is a threshold that is too aggressive, or a process that does not distinguish between old known issues and new declines.

Start by collecting baseline data from several audits. Then set the threshold so that a notification means a real drop from the normal working state, not a reminder that every imperfect site still has flaws. For older projects, it may make sense to maintain a separate optimization plan and temporarily hold them to a different standard than new sites.

REST API or WP-CLI Does Not Produce the Expected Result

Symptom: the command runs but the audit never starts, the REST API returns an authorization error, or the external client cannot see the dashboard. Check that the extension is installed and active, that the REST API key has the required permissions, that the permalink setting is not Plain, and that the dashboard is reachable from the environment sending the request. A local dashboard is usually not accessible to an external API client.

If automation is not critical, get the interface workflow stable first. Then add WP-CLI or the REST API. That makes it easier to isolate the problem: Lighthouse itself, the API key, REST permissions, network reachability, or the command environment.

When MainWP Lighthouse Is the Right Choice

MainWP Lighthouse is worth using if you already manage multiple WordPress sites through MainWP and want to add page quality checks to your regular operating process. The extension is especially useful for agencies, freelancers, and administrators who need to spot weaker sites in one place, run scheduled audits, verify results after optimization, and optionally integrate WP-CLI or the REST API.

Before rolling it out, do not skip the basics: a stable dashboard, working child site sync, public access to the URLs being tested, a saved Google PageSpeed Insights API key, and reasonable execution-time limits. After the first audit, tune the thresholds so that notifications are helpful instead of noisy.

If what you need is regular Lighthouse oversight inside MainWP, go to the download section and download the MainWP Lighthouse archive, then start with a single test site. If you only manage one project or are looking for automatic optimization, start instead with PageSpeed Insights, Chrome DevTools, and dedicated caching, image, and performance plugins.