lighthouse

lighthouse copied to clipboard

We were looking at the facade audit as part of the Web Almanac this year and discovered it can never pass and not sure that's right.

So at the moment if there are no facade-eligible third-party resource it returns notApplicable. If there are any facade-eligible third-party resource it returns 0 in the score (aka fail).

However, this means if a site uses facade, then it's no longer using the facade-eligible third-party resource and so returns notApplicable as the facade itself is not a facade-eligible third-party resource.

Should Lighthouse return a score of 1 (aka pass) if a site is correctly using facades rather than notApplicable?

Here's an example URL that, at the time of writing, is using the lite-youtube embed: https://pagespeed.web.dev/report?url=https%3A%2F%2Fwww.castleminerals.com%2F (as the audit recommends) but the audit is showing the grey "not applicable" icon, instead of the green pass icon:

And the Lighthouse JSON similarly shows it as not applicable:

        "third-party-facades": {
            "id": "third-party-facades",
            "title": "Lazy load third-party resources with facades",
            "description": "Some third-party embeds can be lazy loaded. Consider replacing them with a facade until they are required. [Learn more](https://web.dev/third-party-facades/).",
            "score": null,
            "scoreDisplayMode": "notApplicable"
        },

Not the biggest deal in the world, but confused us for a bit so thought I'd raise this issue for you to consider.

Should Lighthouse return a score of 1 (aka pass) if a site is correctly using facades rather than notApplicable?

If someone designs their own facade solution for something like Youtube then we won't be able to detect it. However the audit should still "not fail" because the site is still benefiting from deferring the YT embed.

In theory we could detect all of the "known" facades but this is probably more work than it's worth, and we would be showing some subtle bias towards the facades that are "known".

Perhaps we could make the audit pass instead of N/A and rephrase the passing state to something like "No third-party resources detected that are deferrable with a facade".

Fair points. I think changing to pass instead of notApplicable as you suggest is the best we can get then.

Not sure this is related but I have a case where I'm using facades for the Vimeo video api. It starts off life as a HTML element on the page, an anchor link should the javascript fail the video can still be accessed.

<a href="https://player.vimeo.com/video/******" data-parameters="autoplay=true;byline=false;controls=false;loop=true;muted=true;playsinline=true;portrait=false;title=false;" class="apiVideoBlockLink">
  <svg focusable="false" class="apiVideoBlockIcon play">
    <title>Play video</title>
    <use href="/static/images/svg.svg#svg-play"></use>
   </svg>
   <svg focusable="false" class="apiVideoBlockIcon pause">
      <title>Pause video</title>
      <use href="/static/images/svg.svg#svg-pause"></use>
    </svg>
</a>

I have an entry js file that uses module loading

<script type="module" src="appEsm.js"></script>

Inside the entry file I check to see if the element is on the page and import an additional script that includes the vimeo api to add the iframe to the page.

const heroVideoApis = document.querySelectorAll(".apiVideoBlockLink");
if(heroVideoApis.length > 0){
  import("./components/_heroVideoApi.js").then(modules => {
    new modules.HeroVideoApi(heroVideoApis);
  })
}

I'm not using an iframe in the server rendered html, I'm deferring my js by using modules, and only loading the Vimeo API if the element exists on the page. To me this ticks all the boxes of the guide on using facades, but I still get the "Some third-party resources can be lazy loaded with a facade" in the diagnostics panel.

@iamallyniam that looks like a separate issue, can you please fill out a new bug report?

Thanks for clarifying @adamraine