"Issues were logged in the Issues panel in Chrome DevTools": how to fix it

Quick answer: This audit fails when Chrome logs a Cookie, Mixed content, Content security policy, cross-origin policy, or heavy-ad issue during page load. Expand the audit to see the issue type and URL, then open the Issues panel in DevTools for the exact message. Fix issues on your own domain; for third-party URLs, update, replace, or remove the embed.

This audit fails when Chrome raises an entry in the DevTools Issues panel while your page loads. It is one of the most commonly failed Best Practices audits: in our study of 269 Shopify storefronts, 194 of them (72.1%) failed it. The report only tells you the issue type and the URL involved, so most people get stuck on the next step. This page covers what each type means, which ones you can fix, and which ones belong to a third party.

TL;DR

• What: Chrome logged a problem in the Issues panel during load. Lighthouse counts five types only: Cookie, Mixed content, Content security policy, Blocked by cross-origin policy, and Heavy resource usage by ads.
• Why it matters: It is a pass-or-fail Best Practices audit. Each row usually means a request was blocked or is about to stop working.
• Fix: Expand the audit, read the issue type and URL, then open the Issues panel in DevTools for the full message. Fix the issues on your own origin. For third-party URLs, update, replace, or remove the embed.

What does "Issues were logged in the Issues panel in Chrome DevTools" mean?

Chrome has a separate channel for browser-level problems that are not JavaScript errors. These go to the Issues panel in DevTools, not to the console. Lighthouse reads that channel during the page load and fails the audit if it finds an issue of a type it tracks.

The audit is binary. One issue fails it, and there is no threshold. The Lighthouse report shows one row per issue type, with the affected URLs underneath:

Why does DevTools show issues that Lighthouse does not count?

The Issues panel reports many more categories than this audit checks. Form fields without an id or name, low text contrast, quirks mode, and deprecated API warnings all appear in the panel, but none of them fail inspector-issues. Some are checked by other audits instead: contrast by color-contrast, deprecated APIs by the separate deprecations audit.

So treat the Lighthouse rows as the list to fix. If the panel shows ten entries and Lighthouse lists one issue type, the other nine do not affect this audit.

How do I find the exact issue Lighthouse flagged?

1. In the Lighthouse report, open Best Practices and expand "Issues were logged in the Issues panel in Chrome Devtools". Note each issue type and the URLs under it. The URL tells you who owns the problem.
2. In DevTools, open the Issues panel: click the issues badge at the top right of DevTools, or open the command menu (Ctrl+Shift+P, or Cmd+Shift+P on Mac) and run Show Issues. Reload the page with the panel open. Each entry expands to the exact message, the affected request, and a link to the element or cookie.
3. In the JSON output, read the rows directly when you check many pages:

   lighthouse https://example.com --only-categories=best-practices --output=json --quiet \
     | jq -r '.audits["inspector-issues"].details.items[]
              | .issueType + "\t" + ([.subItems.items[]?.url] | join(" "))'
   

Use an incognito window with extensions turned off when you reproduce by hand. Extensions add their own issues to the panel.

How do I fix each issue type?

How do I fix a Cookie issue?

Open the Issues panel and read the cookie entry. It names the cookie and the request. The common messages are:

• "Indicate whether to send a cookie in a cross-site request by specifying its SameSite attribute". Set SameSite explicitly. Use SameSite=Lax for first-party cookies, and SameSite=None; Secure only for cookies that must work inside a cross-site iframe.
• "Mark cross-site cookies as Secure to allow setting them in cross-site contexts". A SameSite=None cookie also needs Secure.
• A third-party cookie warning on an embedded frame. The cookie belongs to the vendor domain in the row (chat, payments, A/B testing, reviews). Only the vendor can change it. If the vendor offers a partitioned cookie (Partitioned attribute) or a newer SDK, update to it.

Set-Cookie: session=abc123; Path=/; Secure; HttpOnly; SameSite=Lax
Set-Cookie: widget_id=xyz; Path=/; Secure; SameSite=None; Partitioned

If the cookie URL is on your own domain, the fix is the Set-Cookie header on your server or in your framework's cookie settings.

How do I fix a Mixed content issue?

An http:// URL is loaded on an https:// page. Change the reference to https://. Look in templates, CMS content, and hard-coded image or script URLs from an old domain. As a safety net, the Content-Security-Policy: upgrade-insecure-requests header tells browsers to request https:// for those URLs. It only works if the resource is available over HTTPS. See Does not use HTTPS for the full picture, since mixed content fails that audit too.

How do I fix a Content security policy issue?

A CSP blocked something. The Issues panel shows the directive that blocked it (script-src, frame-src, connect-src, frame-ancestors) and the blocked URL. Two cases:

• Your CSP blocked a resource you want. Add that origin to the right directive, or move the inline script into a file and add a nonce or hash. Do not add unsafe-inline to clear the issue. That removes the protection the header gives you.
• The blocked URL is a third party, and the policy is theirs. A frame you embed can refuse to be framed with its own frame-ancestors policy. You cannot change their header. Remove the embed, or load the vendor's widget the way their documentation describes.

If the blocked resource is something you do not need, the best fix is to delete the code that requests it.

How do I fix "Blocked by cross-origin policy"?

A response was blocked because of Cross-Origin-Embedder-Policy (COEP) on your page or Cross-Origin-Resource-Policy (CORP) on the resource. This usually happens after you add Cross-Origin-Embedder-Policy: require-corp to enable cross-origin isolation, and a third-party image or script does not send a matching CORP header.

• For resources you own, send Cross-Origin-Resource-Policy: cross-origin (or same-site) on them.
• For third-party resources, load them with crossorigin so CORS applies, or switch your page to Cross-Origin-Embedder-Policy: credentialless.
• If you do not need cross-origin isolation (SharedArrayBuffer, precise timers), remove the COEP header.

How do I fix "Heavy resource usage by ads"?

Chrome unloads an ad frame that uses more than 4 MB of network data, more than 15 seconds of CPU in any 30-second window, or more than 60 seconds of CPU in total. The ad network or the creative owns this problem. Report the creative to your ad network, block that advertiser or category in the network's settings, and check that no ad slot autoplays heavy video.

Can I pass this audit if a third party causes the issue?

Often you cannot fix the issue itself. You can only decide whether to keep the embed. We re-ran four failing Shopify stores from our study. All four had a Content security policy row with the blocked URL https://shop.app/, which is Shopify's own Shop domain. That request comes from Shopify's platform scripts, not from the theme, so a merchant cannot change the policy. One store also had a Cookie row on two embedded shipping-widget iframes.

When the URL in the row is not yours, the options are:

1. Remove the embed if it does not earn its place. This is the only fix you fully control.
2. Update the vendor SDK. Vendors fix cookie attributes and CSP conflicts in new versions.
3. Report it to the vendor with the exact Issues panel message.
4. Accept the finding. This audit has a low weight in the Best Practices score. A failed row from a platform script you cannot remove costs you less than removing a feature that sells.

How do I verify the fix?

1. Re-run Lighthouse. "No issues in the Issues panel in Chrome Devtools" should appear in the passed-audits list.
2. Open the Issues panel in an incognito window, reload, and confirm the fixed issue type no longer appears.
3. Check a second page type, such as a product page and a cart page. Embeds and cookies often differ by template.
4. For cookie fixes, read the response header with curl -sSI <url> | grep -i set-cookie and confirm the attributes.

What mistakes should I avoid?

• Fixing what DevTools shows instead of what Lighthouse lists. Only five issue types fail this audit. Form-field and contrast issues in the panel do not.
• Loosening your CSP to clear the row. unsafe-inline or a wildcard source clears the issue and removes the protection.
• Setting SameSite=None on every cookie. Use it only on cookies that must work in a cross-site frame. Use Lax for the rest.
• Blaming your code for a vendor URL. Read the URL in the row first. If it is not your domain, the fix is a vendor or embed decision.

Related audits

• Browser errors were logged to the console: CSP blocks and mixed content often appear there as console errors at the same time
• Does not use HTTPS: mixed content fails both audits for the same reason
• Reduce unused JavaScript: the embeds that cause third-party issues are often the ones you no longer need

Audit your URL at https://lighthouse-md.com.