Can't get consistent Gatsby Img behavior

Description

I’ve finally managed to get Gatsby images work as expected on desktop devices, to find out that they are totally not working on mobile safari/firefox/chrome on ios devices. Moreover, I can’t get consistent behavior of images when deploying my project on gh-pages. One deploy everything works, other one, with no changes at all, images just get stuck on blur phase. I found a temporary fix of deleting cache folder in my project, but I don’t think that it’s the best way of solving this.

Steps to reproduce

Plugins that I use

{
   resolve: `gatsby-source-filesystem`,
   options: {
     path: `${__dirname}/src/posts`,
     name: 'posts',
   },
 },
 {
   resolve: `gatsby-source-filesystem`,
   options: {
     name: `images`,
     path: `${__dirname}/src/assets/images`,
   },
 },
 {
   resolve: `gatsby-source-filesystem`,
   options: {
     name: `photos`,
     path: `${__dirname}/src/assets/photos`,
   },
 },
 {
   resolve: `gatsby-source-filesystem`,
   options: {
     name: `headers`,
     path: `${__dirname}/src/assets/headers`,
   },
 },

 {
   resolve: `gatsby-transformer-remark`,
   options: {
     plugins: [
       {
         resolve: `gatsby-remark-images`,
         options: {
           maxWidth: 630,
         },
       },
       'gatsby-remark-copy-linked-files',
     ],
   },
 },
 `gatsby-transformer-sharp`,
 `gatsby-plugin-sharp`,
 `gatsby-plugin-react-helmet`,
 `gatsby-plugin-sass`,
],

Queries (note: they are placed in separate pages):

export const query = graphql`
  query HeaderQuery {
    headerImage: imageSharp(id: { regex: "/headers/" }) {
      sizes(maxWidth: 2000) {
        ...GatsbyImageSharpSizes_tracedSVG
      }
    }
  }
`
export const query = graphql`
  query PhotosQuery {
    allFile(
      filter: {
        extension: { regex: "/(jpeg|jpg|gif|png)/" }
        sourceInstanceName: { eq: "photos" }
      }
    ) {
      edges {
        node {
          childImageSharp {
            sizes(maxWidth: 2000) {
              ...GatsbyImageSharpSizes
            }
          }
        }
      }
    }
  }
`

Images:

<div className="g-container">
      {data.allFile.edges.map(entry => (
        <Img
          className="photo"
          title="grid image"
          alt="test"
          sizes={entry.node.childImageSharp.sizes}
        />
      ))}
    </div>

<Img
      className="header-legal"
      title="Header image"
      alt="test"
      sizes={data.headerImage.sizes}
    />
`

Expected result

1)I expect everything to work on every npm run develop or npm run deploy but from time to time they are not working in both development mode and build mode. 2)I expect images to have lazy load on mobile devices, but it seems like they don’t even have blur, when page loads and behave like normal <img>

Actual result

You can see demo of not working mobile images here:

https://d-ivashchuk.github.io/taurus-gatsby/photos

Or here:

https://d-ivashchuk.github.io/taurus-gatsby/legal

Environment

  System:
    OS: macOS Sierra 10.12.6
    CPU: x64 Intel(R) Core(TM) i7-6820HQ CPU @ 2.70GHz
    Shell: 3.2.57 - /bin/bash
  Binaries:
    Node: 6.10.1 - /usr/local/bin/node
    npm: 6.1.0 - /usr/local/bin/npm
  Browsers:
    Chrome: 67.0.3396.99
    Firefox: 56.0.2
    Safari: 11.1.2
  npmPackages:
    gatsby: ^1.9.243 => 1.9.273 
    gatsby-image: ^1.0.54 => 1.0.54 
    gatsby-link: ^1.6.40 => 1.6.45 
    gatsby-plugin-google-analytics: ^1.0.24 => 1.0.31 
    gatsby-plugin-react-helmet: ^1.0.8 => 1.0.8 
    gatsby-plugin-sass: ^1.0.25 => 1.0.26 
    gatsby-plugin-sharp: ^1.6.48 => 1.6.48 
    gatsby-remark-copy-linked-files: ^1.5.30 => 1.5.37 
    gatsby-remark-images: ^1.5.60 => 1.5.67 
    gatsby-source-filesystem: ^1.5.27 => 1.5.39 
    gatsby-transformer-remark: ^1.7.39 => 1.7.44 
    gatsby-transformer-sharp: ^1.6.27 => 1.6.27 
  npmGlobalPackages:
    gatsby-cli: 1.1.58

Apart from this issue I want to thank you guys for creating Gatsby and helping people like me to become proficient with it. Great Job!

[coreyward]

Is it fine to use Webp format fragments even if the site is targeted to Safari because a fallback is generated and this will be used.

If you know that this is exclusively going to be used by iOS you could just leave off the _withWebp part of the fragment, but if you leave it there there’s no real harm (a few extra bytes of data in the srcset).

In a fluid fragment, the maxWidth should be the maximum container width in the biggest screen size that needs to be supported.

If by this you mean that the maxWidth should be the largest that this image is displayed (i.e., its maximum contained size), then yes. If you’re doing something where it’s only displayed at, say, 50% of the viewport width (50vw) you can actually override the sizes attribute to provide a more accurate recipe for the browser, but the default is fairly safe.

Quality set to 100% is not recommended to get fast-loading sites… 😅

😉

[PolGuixe]

@coreyward I am using quality 100% to accentuate the effect of these big pictures. 😅 Won’t go like this into production.

I’ve checked the size of the image downloaded and instead of 1200px, the image is 1800px which is the next resolution step. The device I am using for testing is an iPhone 8 Plus. Edit: pixel ratio on this device is about 3, screen width 414px --> 414*3= 1242 > 1200 hence it jumps to the next resolution step.

Just to confirm best practices:

1. Is it fine to use Webp format fragments even if the site is targeted to Safari because a fallback is generated and this will be used.

2. In a fluid fragment, the maxWidth should be the maximum container width in the biggest screen size that needs to be supported.

3. Quality set to 100% is not recommended to get fast-loading sites… 😅

I’ll keep doing a test to see if I can get a good consistency.