Site-kit-wp: JavaScript error: Loading chunk 0 failed

[jamesozzie]

Bug Description

Some users continue to experience errors in some places when using Site Kit, particularly around the splash/setup screen which prevents them from using the plugin.

E.g.

Loading chunk 0 failed. (error: https://theguyinthekitchen.com/wp-content/plugins/google-site-kit/dist/assets/js/chunk-googlesitekit-adminbar~chunk-googlesitekit-setup-wizard~chunk-googlesitekit-setup-wizard-proxy-7b6a86fd3073896743e0.js)

    in Unknown
    in Suspense
    in DashboardSplashApp
    in ErrorHandler
    in GoogleSitekitDashboardSplash

The error indicates a chunk loading failure, which is an on-demand loading of a React component or JavaScript partial.

These were added as part of the original design of the plugin but no longer offer much benefit, and result in a poor experience in the event of a loading failure which could happen for a number of reasons.

As such, they should be removed and we can re-evaluate their use and implementation in the future if needed.

Historical context

Following on from #1323 investigate JS error below. This occurs after clicking on the "Proceed" button during site verification.

Since reporting the user who initially reported this error has been able to proceed with setup successfully.

Initial report (via WordPress support forum):
https://wordpress.org/support/topic/connection-loop/

Additional information:

• Support unable to replicate
• Additional users may be impacted, although only confirmed JS error specifically from original topic
• Site Health info provided with initial support topic
• First report from user during 1.6.0 setup

---

_Do not alter or remove anything below. The following sections will be managed by moderators only._

Acceptance criteria

• All dynamic imports should be removed

Implementation Brief

• Replace lazy imports with normal static imports and remove use of React.Suspense
  
  
  
  • assets/js/components/dashboard-splash/dashboard-splash-app.js
  
  
  • assets/js/googlesitekit-module.js
  
  
• Delete assets/js/googlesitekit-adminbar-loader.js, entry in webpack, etc
  
  
  
  • Enqueue googlesitekit-adminbar in its place
  
  
• Update assets/js/googlesitekit-adminbar.js to delay rendering the Admin Bar app until the menu item is hovered
  
  
  
  • Using domReady, add an event listener onto the admin bar menu item's mouseover event to call the init function (should only run once)
    
    _We should also add another listener on focus or other event for accessibility_
  
  
• Add trackEvent( 'admin_bar', 'page_stats_view' ) to GoogleSitekitAdminbar for consistency with loader behavior
  
  
  
  • Can use useEffect with no dependencies to only run once when first rendered
  
  

Test Coverage

• No additions or changes necessary – existing E2E coverage should be sufficient

Visual Regression Changes

• No changes expected

QA Brief

This issue removed the chunks that were failing to load for some users entirely so there is no longer a possibility of this error being raised again. The main thing to check are the areas that previously used these chunks which are only a few places:

• Proxy splash screen should still load just fine
• GCP splash screen should still load just fine - this is more of a legacy developer-specific path but technically still supported (requires providing your own client ID and client secret via Developer Settings)
• Admin bar item
  
  
  
  • once Site Kit is setup, configure it to use a site that has data and navigate to the front end for a page that has data in SC or GA (the admin bar item should appear)
  
  
  • The admin bar stats should display as normal when hovering the menu item
  
  
  • Be sure to test the admin bar thoroughly as this part received the most changes
  
  

Changelog entry

• Remove usage of JavaScript chunk files to fix potential issues with certain server configurations.

[ernee]

Other users experienced similar errors before this, and some resolved it in different ways:
https://wordpress.org/support/topic/error-plugin-help/
https://wordpress.org/support/topic/loading-chunk-0-failed/ (disabled security plugin firewall)
https://wordpress.org/support/topic/site-kit-encountered-an-error-2/ (used workaround to reset proxy)

[ernee]

Another support topic: https://wordpress.org/support/topic/site-kit-encountered-an-error-loading-chunk-1-failed/

[dayafterdesign]

I just had the same issue. Disabling my GridPane 6g WAF to process set-up resolved it.

[ernee]

Another scenario where this issue can be recreated is using a site with Cloudflare's SSL and not updating the WordPress Settings (in some configurations like with Cloudflare's Flexible SSL this may occur when proper redirections are not in place). Site Kit's requests are served as mixed content and blocked in the browser:

[cole10up]

Going to move this one to Execution looking at the reproducible steps.

[kismatboy]

me too have same problem and fixed it after installing cloudflare official plugin :) thanks for the support :)

[pablosfc1]

Yes, I had this problem. Then I have Cloudfare with HTTPS forced. But at configure the plugin Site Kit shown me the message "encountered an error: Loading chunk 3 failed." Additionally I had to activate the Really Simple SSL plugin in Wordpress, then the Google Site Kit it's functioning ok now.

[felixarntz]

@jamesozzie @ernee @LuckynaSan Has this (or similar "random" JS issues) still been surfacing over the past few weeks? This should have been fixed in 1.15.0, since we only use hashed JavaScript filenames since that, which change every release, basically preventing any over-aggressive caching.

[jamesozzie]

@felixarntz They have in fact, we've had 3 or 4 topics open in relation to this. It's been a "Loading chunk 1 failed" (as opposed to 0)

Some users have confirmed clearing their cache resolves the issue. See below:

https://wordpress.org/support/topic/error-in-admin-phppagegooglesitekit-splash/ (Resolved - clearing cache)
https://wordpress.org/support/topic/issue-for-adsense/ (Awaiting response) - Loading chunk 5
https://wordpress.org/support/topic/loading-chunk-1-failed/ (Awaiting response)
https://wordpress.org/support/topic/help-please-226/ (Awaiting response)

Also there was a separate JS error reported today:
https://wordpress.org/support/topic/google-site-kit-2/

[jamesozzie]

Additional topics opened with similar errors this week, awaiting response from users. Unknown whether the issue occurred after a plugin updated from a specific version.
https://wordpress.org/support/topic/loading-chunk-1-failed-2/ (Awaiting response) Loading chunk 1 failed
https://wordpress.org/support/topic/error-after-install-plugin-3/ (Possibly hosting/firewall related) Loading chunk 4 failed

[felixarntz]

@tofumatt @eugene-manuilov Any ideas why users could still experience this? I guess caching is ruled out because we now use file hashes.

[eugene-manuilov]

@felixarntz It looks like those topics report the same problem that happens at the splash screen in certain circumstances. It's definitely not relevant to the work that we did to add hashes to javascript files because these issues happen only with chunk files that's functionality hasn't been changed.

I have tried to replicate it on my end, but haven't been able to do it. We need more information about the environment (plugins/theme/hosting/etc) in which this issue can be reproduced.

[jamesozzie]

@felixarntz @eugene-manuilov I'm able to reproduce this issue on one site using a hosting provider that blocks outgoing http connections (Loading chunk 4 failed). More details in the related support topic.

[Bubbgump209]

I have a similar error from a host that does NOT block outbound HTTP:

Test of HTTP from the host:

# curl -v ifconfig.me
* About to connect() to ifconfig.me port 80 (#0)
*   Trying 216.239.34.21... connected
* Connected to ifconfig.me (216.239.34.21) port 80 (#0)
> GET / HTTP/1.1
> User-Agent: curl/7.19.7 (x86_64-redhat-linux-gnu) libcurl/7.19.7 NSS/3.44 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
> Host: ifconfig.me
> Accept: */*
> 
< HTTP/1.1 200 OK
< Date: Mon, 28 Sep 2020 13:58:26 GMT
< Content-Type: text/plain; charset=utf-8
< Content-Length: 14
< X-Powered-By: Express
< Access-Control-Allow-Origin: *
< Via: 1.1 google
< 
* Connection #0 to host ifconfig.me left intact
* Closing connection #0
199.188.200.14

Specific error:

Loading chunk 1 failed.
(error: https://www.rpiathome.com/wp-content/plugins/google-site-kit/dist/assets/js/chunk-googlesitekit-adminbar~chunk-googlesitekit-setup-wizard-proxy-f262ebd34a6cc64e6bbf.js)

    in Unknown
    in Suspense
    in DashboardSplashApp
    in GoogleSitekitDashboardSplash
    in RestoreSnapshots
    in ErrorHandler
    in Root

It would lead one to believe that HTTP vs HTTPS is not a factor.

[felixarntz]

Looking at the second screenshot in https://github.com/google/site-kit-wp/issues/1391#issuecomment-628008695, it looks like the chunk file is loaded with the insecure HTTP protocol although the site is using HTTPS (and the JS file enqueued by WordPress also uses HTTPS as expected). Could there be some problem in the way Webpack loads these chunks possibly? cc @eugene-manuilov

[aaemnnosttv]

I would think any chunks would be loaded using the same scheme as the script that calls it.

Also, a host which blocks outbound requests wouldn't matter here as this request is from the browser to the host. The only thing that might block it would be something like a CSP (although it's loading from the same host as the main script so I wouldn't think that could be a problem) or perhaps some kind of rule on the server which happens to block the URL based on some pattern.

One thing we should do is revisit whether or not we need these dynamically loaded component chunks at all. Perhaps we should just replace the dynamic imports with static ones?

Otherwise, any kind of normal request failure (e.g. network interruption) should be recoverable using a plugin like this to retry a chunk if it fails to load? https://github.com/mattlewis92/webpack-retry-chunk-load-plugin

[aaemnnosttv]

@tofumatt – moving this to AC for definition after discussing further with @felixarntz .

[felixarntz]

IB ✅

[tofumatt]

Ah, so just to be clear, the Webpack chunk loader will handle loading the Admin Bar chunks on-demand and this won’t mess with the JS assets loaded for non-Site Kit pages where the admin bar is present?

I suppose loading that asset for admins/logged-in-users-only would be fine anyway, but just curious.

At any rate, either way IB ✅

[felixarntz]

@tofumatt The only reason this "lazy-loading" was implemented originally was to not load the entire admin bar JS code immediately. However, we're using dependencies and those already are loaded on pageload, so the impact of loading the actual googlesitekit-adminbar.js file immediately is minimal.

It may be worth revisiting optimization of what's immediately enqueued in the frontend when the Site Kit admin bar menu is relevant, but that can happen in a separate issue and is lower priority, especially because of the above (we're not really causing a performance regression here by doing this).

[jamesozzie]

Another user encountered a similar error, while including some console errors. The same occurs when checking from another administrator account in an incognito window.

GET …/wp-content/plugins/google-site-kit/dist/assets/js/chunk-googlesitekit-adminbar~chunk-googlesitekit-setup-wizard-proxy-39bf2f5072bd0d1cdc96.js
[HTTP/2 403 Forbidden 151ms]

The resource from “…/wp-content/plugins/google-site-kit/dist/assets/js/chunk-googlesitekit-adminbar~chunk-googlesitekit-setup-wizard-proxy-39bf2f5072bd0d1cdc96.js” was blocked due to MIME type (“text/html”) mismatch (X-Content-Type-Options: nosniff).
admin.php
ChunkLoadError: Loading chunk 1 failed.
(error: …/wp-content/plugins/google-site-kit/…unk-googlesitekit-setup-wizard-proxy-39bf2f5072bd0d1cdc96.js)

Caught an error: ChunkLoadError: Loading chunk 1 failed.
(error: …/wp-content/plugins/google-site-kit/…unk-googlesitekit-setup-wizard-proxy-39bf2f5072bd0d1cdc96.js)

[felixarntz]

@aaemnnosttv Assigning to you for QA Brief.

[wpdarren]

QA update: Pass

Confirmed:

1. Proxy splash screen loads fine. Successfully connected SK to Google account and Search Console + GA. No Javascript errors appeared in the console on all steps. Step 1 https://d.pr/i/7k7lxW Step 2 https://d.pr/i/huZthx Step 3 https://d.pr/i/JVid67 Step 4 https://d.pr/i/m43RUd Step 5 https://d.pr/i/GhWgRD
2. GCP splash screen. Activated 2E Tests GCP Credentials Plugin for developer settings.The GCP splash screen appears and no Javascript errors appear in the console https://d.pr/i/jL7fq2
3. When on the FE for a page, the data from SC and GA appears in the admin bar item. https://d.pr/i/X5MSEt
4. When on the FE for a post, the data from SC and GA appears in the admin bar item. https://d.pr/i/SaTAFg
5. Crossed checked the data on the admin bar item with SC and GA

Environment:

WP: 5.5.3
PHP: 7.3.21
SiteKit: 1.19.0 (on develop branch)