Lighthouse: Treat error pages that ultimately redirect as non-error pages

Created on 12 Jan 2020  路  5Comments  路  Source: GoogleChrome/lighthouse

I have a page hosted on gh-pages with a custom domain built with create-react-app with routes and using the 404 redirect hack, so on the browser is all perfect I can access all my pages like example.com/products directly, but when I try to test it on lighthouse it returns only an error with the 404 code, the test shouldn't have been redirected to the correct page ?

P3 bug

All 5 comments

Thanks for filing @ThiagoIII are you able to fill out any more details in the bug report template? Can you provide an example URL or report for what you're talking about?

using the 404 redirect hack

What specific 404 redirect hack are you referring to? A 404.html page with a JS-based redirect? Is your 404.html a copy of your index but still serves a 404 status code?

Hi Patrick thanks for the response, and sorry did not know about the bug template.
So if you LH here https://tyvs.com.br/empresa it will return a error with 404 code.

I used React with Router and this 404.html , this is the "hack":
<!DOCTYPE html> <html> <head> <meta charset="utf-8"> <title>React Redirect to https://tyvs.com.br</title> <meta name="description" content="this is a workaround for reactJS for googlebot to know where to look now, it is actually to show content when the page is refreshing"> <script type="text/javascript"> // Single Page Apps for GitHub Pages // https://github.com/rafrex/spa-github-pages // Copyright (c) 2016 Rafael Pedicini, licensed under the MIT License // ---------------------------------------------------------------------- // This script takes the current url and converts the path and query // string into just a query string, and then redirects the browser // to the new url with only a query string and hash fragment, // e.g. http://www.foo.tld/one/two?a=b&c=d#qwe, becomes // http://www.foo.tld/?p=/one/two&q=a=b~and~c=d#qwe // Note: this 404.html file must be at least 512 bytes for it to work // with Internet Explorer (it is currently > 512 bytes) // If you're creating a Project Pages site and NOT using a custom domain, // then set segmentCount to 1 (enterprise users may need to set it to > 1). // This way the code will only replace the route part of the path, and not // the real directory in which the app resides, for example: // https://username.github.io/repo-name/one/two?a=b&c=d#qwe becomes // https://username.github.io/repo-name/?p=/one/two&q=a=b~and~c=d#qwe // Otherwise, leave segmentCount as 0. var segmentCount = 0; var l = window.location; l.replace( l.protocol + '//' + l.hostname + (l.port ? ':' + l.port : '') + l.pathname.split('/').slice(0, 1 + segmentCount).join('/') + '/?p=/' + l.pathname.slice(1).split('/').slice(segmentCount).join('/').replace(/&/g, '~and~') + (l.search ? '&q=' + l.search.slice(1).replace(/&/g, '~and~') : '') + l.hash ); </script> </head> <body> </body> </html>

With a script at the section of my index.html:
<script type="text/javascript">!function(i){if(i.search){var l={};i.search.slice(1).split("&").forEach(function(i){var a=i.split("=");l[a[0]]=a.slice(1).join("=").replace(/~and~/g,"&")}),void 0!==l.p&&window.history.replaceState(null,null,i.pathname.slice(0,-1)+(l.p||"")+(l.q?"?"+l.q:"")+i.hash)}}(window.location)</script>

So yes I think that a 404.html page with a JS-based redirect.

I just wanted to test my components "page" you know, the thing is I just found out that I need to add a few letters to the path so it will work properly I think.

Using Chrome 79, windows 8.1

Thanks again

Thanks very much for the URL and explanation!

Lighthouse doesn't currently respect client-side redirects on error pages. https://github.com/GoogleChrome/lighthouse/issues/8984 is one step in the path to properly supporting the JS-based redirect like this does though we're likely a ways off.

Clever gh-pages workaround though! :) As a workaround for now you could audit the redirected URL directly (https://tyvs.com.br/?p=/empresa)

image

Thanks man!

Lighthouse doesn't currently respect client-side redirects on error pages. #8984 is one step in the path to properly supporting the JS-based redirect like this does though we're likely a ways off.

Completly answered my question!

Should I close this issue now ?
Thanks again!

I think we can leave this open. Even once we support client-side redirects in general, it will be an extra bit to change the error page behavior. Fixing this is blocked by the work in #8984.

Was this page helpful?
0 / 5 - 0 ratings