Image CDN

[veryspry]

Description

We recently announced a new feature called Image CDN.

Please post your feedback regarding this new feature, any performance observations and general Developer Experience (DX) of this feature.

We appreciate any all feedback and want to improve Image CDN! Thanks!

[Vacilando]

When will gatsby-source-drupal support Image CDN?

[TylerBarnes]

Hi @Vacilando ! We don't have an exact date on that but it's on our list of source plugins to add support to during the beta period.

[TylerBarnes]

Support will be shipped soon!

Draft PR here if you're interested in taking a look and trying it out. Check here for a canary version.

[TylerBarnes]

Drupal has support as of last week. Upgrade to the latest version and check the source-drupal docs for configuration info.

[Vacilando]

Thanks for the heads up, @TylerBarnes!

[TylerBarnes]

Anytime! Let me know if you run into any issues

[panzacoder]

Testing out this option while building locally. I see a new worker "Running gatsby.IMAGE_CDN jobs". It seems to take a really long time. Is this as expected?

I'm still running this for the first time as I type this, but I'm at 450s at 2500/11700 jobs complete. I'll update with total time when the job is done, and if it succeeds I will try running it on Netlify.

[panzacoder]

FYI, the build never finished. Every other build has crashed (I believe due to memory errors, I was hoping offloading the image processing would unblock my upgrade to v4), and the one I described above took ~30m to complete the image processing locally and the cloud image jobs, but ultimately was stuck at 782/882 page queries.

(This is an aside from this topic, but) I wish there was an easy way to tell what exactly was causing my memory issues. It's so frustrating to spend hours migrating code to find out that there's something wrong. I believe it's part of my repo but I have no inkling as to what is causing it.

[krismorf]

@panzacoder We had the same issue since 4.10 was released. We HAD to migrate to the new syntax or else we would reach memory limits on the gatsby.IMAGE_CDN jobs.

# from
node {
    localFile {
        childImageSharp {
            gatsbyImageData(width: 128, height: 128)
        }
    }
}

# to
node {
    gatsbyImage(width: 128, height: 128)
}

We are using multiple source plugins with images, we only had to change this for gatsby-source-wordpress.

[panzacoder]

Unfortunately I have a number of images that are still in my local repo, so I'm unable to use all CDN queries. I updated everything I could in my test branch but it won't work mixed.

[davidpaulsson]

Image CDN / gatsbyImage doesn't seem to work with pathPrefix 🙂 Everything builds fine with /path-prefix/, and I'd expect the image src to be domain.com/path-prefix/_gatsby/image/... but it's domain.com/_gatsby/image/... straight from the root.

[davidpaulsson]

This is a major blocker unfortunately

[wardpeet]

Thanks will fix!

[johnark88]

Really appreciate the work!
Any word on a fix for the pathPrefix while using gatsbyImage?

[Vacilando]

Same problem - what's the status of the fix, @wardpeet ?

[TylerBarnes]

I opened a PR adding support just now #36772

You can try it out with these canaries:

• [email protected]+fa632a40d6
• [email protected]+fa632a40d6
• [email protected]+fa632a40d6
• [email protected]+fa632a40d6
• [email protected]+fa632a40d6
• [email protected]+fa632a40d6

If it's not working after installing the canaries, try setting a yarn resolution:

{
 "resolutions": {
   "gatsby-plugin-utils": "3.19.0-alpha-image-cdn-pathprefix.48"
 }
}

EDIT: just bumped the versions in that list ☝️

[Haldaug]

I get this error message whenever there's an incremental build triggered by a new post in wordpress:

There was an error in your GraphQL query:

The first argument must be of type string or an instance of Buffer, ArrayBuffer, or Array or an Array-like Object. Received undefined

1 | fragment PostPreviewContent on WpPost {
   2 |   uri
   3 |   title
   4 |   databaseId
   5 |   excerpt
   6 |   isSticky
   7 |   date(formatString: "D. MMMM YYYY", locale: "nb")
   8 |   featuredImage {
   9 |     node {
> 10 |       gatsbyImage(
     |       ^
  11 |         width: 680
  12 |         layout: CONSTRAINED
  13 |         placeholder: BLURRED
  14 |         aspectRatio: 1.77777
  15 |         cropFocus: FACES
  16 |       )
  17 |       altText
  18 |       title
  19 |     }
  20 |   }

It seems like no Image CDN jobs are ran for new images encountered under an incremental build, thus failing the query.

When doing a cold build, this problem does not occur.

[TylerBarnes]

Hi @Haldaug can you paste your site ID here? I work at Gatsby so I'll be able to use that to look into this issue. You should be able to find it in the url when you visit your site dashboard in Gatsby Cloud.

Edit: If you don't feel comfortable posting it here you can also email it to me at [email protected]

[Haldaug]

Is this incident related by any chance? https://status.gatsbyjs.com/incidents/73dqycj7fv3s

It says that it is resolved, but my preview builds still fail when encountering a new image.

[TylerBarnes]

This will be fixed in #35687

[Haldaug]

Upgrading gatsby-source-wordpress to the newest version fixed this. Thanks!

[rburgst]

as stated here #35327 I do get very slow IMAGE_CDN jobs running on a wordpress sourced site that does not use IMAGE_CDN. Why?

I tried setting

export GATSBY_CLOUD_IMAGE_CDN=0

but that didnt change anything.

Even on gatsby-starter-wordpress-blog shows up and takes a quite long time.

Here is the output (mid build) from my actual project:

[================            ]   980.241 s 11119/19224 58% Running gatsby.IMAGE_CDN jobs
[============================]   567.656 s 4146/4146 100% Running gatsby-plugin-sharp.IMAGE_PROCESSING jobs

After 15 min, only 58% complete?

What is it doing?

Eventually the build completed after 25mins

[rburgst]

ok, figured out that this is the part where it downloads the remote images in the IMAGE_CDN job (also for non IMAGE_CDN features) which is quite misleading

[TylerBarnes]

This is because the image CDN job supports CI platforms that don't implement image CDN fully. For the WP slowdown we have this PR #35370 which should be merged soon

[moonmeister]

Noticing that the Image CDN doesn't provide Cache-Control headers. For example, this image's headers look like:

HTTP/2 200 OK
x-frame-options: DENY
x-xss-protection: 1; mode=block
x-content-type-options: nosniff
referrer-policy: same-origin
etag: CKu88dnK6fYCEAE=
content-type: image/avif
accept-ranges: bytes
date: Tue, 12 Apr 2022 21:53:04 GMT
via: 1.1 varnish
age: 975
x-served-by: cache-sea4457-SEA
x-cache: HIT
x-cache-hits: 1
x-timer: S1649800385.970063,VS0,VE3
server: GatsbyHosting
content-length: 633741
X-Firefox-Spdy: h2

Kyle asked me to mention this here as a possible oversight. What should the Cache-Control headers be for the Image CDN?

[TylerBarnes]

This is an oversight indeed. Thanks for bringing it up! We'll need to add support for this into Gatsby core by allowing a source plugin to provide some string for cache invalidation. pre-image-cdn I believe this was done with the File node's content digest but since we intentionally don't have the file yet we'll need to use something else.
Until we have that I think the max-age can't be set very high since there's currently no way to tell when an image changes but keeps the same url & args.

[moonmeister]

Thanks Tyler, sounds good!

[wardpeet]

We will be setting immutable caching headers on these images and use the node contentdigest, so as a user you would only request the image once

[krismorf]

Image CDN + gatsby-source-wordpress + getSrc

• Image CDN is enabled in Gatsby Cloud
• Local file node fetching is disabled in gatsby-source-wordpress
• Width is included in the GraphQL query: gatsbyImage(width: 1000)

We are passing each wordpress post's featured image into our SEO component.

const fallbackImage = getSrc(post.featuredImage.node.gatsbyImage)

return (
  <SEO image={fallbackImage}/>
)

Previously (before Image CDN):

<meta data-react-helmet="true" property="og:image" content="https://MAIN-DOMAIN/static/4d5ce3e9805c1b9ff68129e01fc32698/9bb58/IMAGE-FILENAME.png">

Now:

<meta property="og:image" content="https://MAIN-DOMAIN/_gatsby/image/c6dd23bbbbffeed4f1870396a206c565/a10bffb34a1a6d8444075de065771c17/IMAGE-FILENAME.png?u=https%3A%2F%2FWORDPRESS-DOMAIN%2Fwp-content%2Fuploads%2F2022%2F04%2FIMAGE-FILENAME.png&amp;a=w%3D250%26h%3D131%26fm%3Dpng%26q%3D75" data-react-helmet="true">

The issue comes with the added query string parameters in the URL, more specifically this: w=250&h=131&fm=png&q=75

I can remove these manually, but is this intentional?

[moonmeister]

So what is the issue? Are the parameters causing an issue? Or are you just not expecting them to be there?

[krismorf]

Both actually. Image turns out blurry on social media. Where is the 250px width coming from?

[moonmeister]

Yeah, it was a change in the spec that was made recently I believe.

[wardpeet]

@krismorf can you use resize resolver instead. That's what it's made for.

[hk86]

What is the purpose of all the additional parameters in the url? I use a Wordpress backend for multiple sites and actually do not want to expose the backend url to the public. Is it somehow possible to drop all the additional parameters?

[lnikell]

I'm migrating the website to a new GatsbyImage API that works with Gatsby Cloud Image CDN https://support.gatsbyjs.com/hc/en-us/articles/4522338898579 for a Headless Wordpress setup.

Following the guideline, I disabled

MediaItem: {
  createFileNodes: false,
},

Some images that are coming from a Wordpress are in SVG format. Previosly I was able access them by localFile.publicUrl which gave me a url in local static folder to that SVG. Now if I access it with publicUrl with a link like

/_gatsby/file/aHR0cHM6Ly92c2huLmN5b24uc2l0ZS93cC1jb250ZW50L3VwbG9hZHMvMjAyMS8wNS9Hcm91cC0xOTE2LnN2Zw==/Group-1916.svg

Gatsby crashes with the following error

[wardpeet]

Thank you, is any SVG failing or just a few?

[lnikell]

I checked multiple svgs and all of the failed on querying. I can check more.

[lnikell]

Image CDN in Gatsby Cloud and localy process images differently.
Here is the video of the bug that I discovered.

https://cln.sh/OQuILk

Query example

[lnikell]

So actually every environment does it differently. I'm getting 3 different results

1. npm start
2. npm run build && npm run serve
3. Gatsby Cloud

[wardpeet]

Sorry what exactly should we look at?

[lnikell]

Maybe it’s not obvious on a video, will check it tomorrow. But the quality of the left image was significantly worse in the cloud vs local build.

[wardpeet]

what if you force quality with an argument? It could be a different quality default setting.

[lnikell]

gatsby-plugin-sharp defaults does not work with gatsbyImage(). Tried to set placeholder: "none", but it does not take any affect. However using placeholder: NONE directly in the query works as expected. Tested with gatsby-source-wordpress plugin.

    {
      resolve: "gatsby-plugin-sharp",
      options: {
        defaultQuality: 85,
        defaults: {
          placeholder: "none",
        },
      },
    },

[wardpeet]

you should not install gatsby-plugin- sharp but use gatsby-source-wordpress configuration.

https://github.com/gatsbyjs/gatsby/blob/master/packages/gatsby-source-wordpress/docs/plugin-options.md#htmlplaceholdertype
You can set it to none, that's actually a fault in the readme

[lnikell]

Oh, perfect. Thanks! Sorry for a silly question.

[lnikell]

Using gatsby-plugin-image with new API + headless WP + Image CDN does not prevent redownloading media items from WP. My assumption was that with Image CDN there won't be additional redownloading of images that have been already downloaded to Gatsby Cloud and we will have a persisted image cache across builds. Currently I see that media files are downloading each time on node/config/package.json changes.

[moonmeister]

This is related to #35147 (comment). TLDR; currently the implementation hashes/invalidates cache based on image url, because the image may change without the URL changing they have to re fetch. This is an improvement they'd like to make in the future.

[lnikell]

Maybe. I'm talking about cheking a hashsum of the remote file and the original file that is stored in CDN + input parameters, it will prevent from downloading multiple times the same files. Also it will save tons of GB for Gatsby Cloud :)

[Haldaug]

This is related to #35147 (comment). TLDR; currently the implementation hashes/invalidates cache based on image url, because the image may change without the URL changing they have to re fetch. This is an improvement they'd like to make in the future.

Are there any further developments here? This would be an excellent feature, cutting my cold build times i half.

[DanielRiveraHQ]

https://heygrillheyfrontendmaster24444.gatsbyjs.io/dr-pepper-jalapeno-beef-jerky/

We tried to update a site we maintain to use the Image CDN, and on the first load, everything looks good, but if you refresh the page on chrome, the images don't load.

We use:

gatsby: 4.12.1
gatsby-source-WordPress: 6.10.1

[davidpaulsson]

Image CDN doesn't play nice with gatsby-source-contentful's cropFocus: FACES option. Here is the original image.

# contentful
gatsbyImageData(
  width: 608
  height: 405
  quality: 100
  cropFocus: FACES
  resizingBehavior: FILL
)

Generates these query params ?w=608&h=405&q=100&fm=webp&fit=fill&f=faces

# gatsby image cdn
gatsbyImage(
  width: 608
  height: 405
  quality: 100
  cropFocus: FACES
  fit: FILL # I think this maps to resizingBehavior?
)

[robmarshall]

I have found when using gatsbyImage with WordPress data, in most cases it works well - but returns the following error when the image is from an ACF node (width & height are set on the query):
Error: Expected positive integer for width but received 0 of type number
When looking into the GraphiQL there doesn't seem to be any data for the ACF particular node.

In addition. Sometimes on any node (ACF or other) gatsbyImage will throw the error:
WorkerError: Expected positive integer for width but received 1142.857142857143 of type number

It seems this error is from sharp expecting a round number. Not sure how an image node is returning a float.

It would be helpful to have errors outlining which images failed.

[shalawfatah]

@laurenskling very strange.
I have this:

{
  allWpBusinesses(limit: 5) {
    nodes {
      title
      featuredImage {
        node {
          gatsbyImage(
            width: 10
            formats: [AUTO]
          )
        }
      }
    }
  }
}

but I see this in response, just before the app crashes:

        {
          "title": "Paradise Valley RC Hobbies",
          "featuredImage": {
            "node": {
              "gatsbyImage": {
                "images": {
                  "sources": [],
                  "fallback": {
                    "src": "/_gatsby/image/0adecf12b4d2fa36930e782cb93ae1f3bb63",
                    "srcSet": "/_gatsby/image/ NaNw",
                    "sizes": "(min-width: NaNpx) NaNpx, 100vw"
                  }
                },
                "layout": "constrained",
                "width": null,
                "height": null,
                "backgroundColor": "rgb(168,152,136)"
              }
            }
          }
        }

If you notice both width and height are null while this is not ACF.

[laurenskling]

@shalawfatah for me, those images were broken. Like JPG broken. WP could show them, but they were unable to get parsed by Sharp. I'm no expert on JPG so never understand how images could get broken like that, but it's a thing.
You also see NaNpx and NaNw in your output. Something goes wrong with the image so it crashes. easiest thing to do is fix the image.

But i'd surely like to see a fix for this in Gatsby. We shouldn't be able to get NaNw string inside our output right?

[shalawfatah]

@laurenskling this seem to be on every image regardless, and happened only when I updated WP-GraphQL plugin, I'll change the format to WEBP to see if that helps.

[laurenskling]

yikes, I read too much about the latest WPGraphQL being broken. Is it fixed already? You might want to revert that one. Go checkout out all the chats in the slack, there was a bunch of talk about WPGraphQL Gatsby being broken

[shalawfatah]

@laurenskling
I reverted to the working version but it does not help. I removed a couple of fields to on the mediaItem expludeFieldNames but that did not help either. Basically I removed the fields sizes and srcSet but it did not help. Not sure what to do. Not sure where this came around to be honest.

	 MediaItem: {
	    createFileNodes: false,
            excludeFieldNames: [
              "contentNodes",
              "seo",
              "ancestors",
              "contentType",
              "author",
              "template",
              "mediaDetails",

[Vacilando]

Drupal 9 on Gatsby Cloud with Image CDN on, using the @latest Drupal source plugin.

In a component with

import { GatsbyImage, getImage } from 'gatsby-plugin-image'

const imageData = getImage( ...
<GatsbyImage image={imageData} >

Changed gatsbyImageData to gatsbyImage in here:

                    field_media_image {
                      localFile {
                        childImageSharp {
                          gatsbyImageData(
                            layout: FIXED
                            width: 100
                            height: 100
                            transformOptions: { grayscale: true }
                            placeholder: DOMINANT_COLOR
                          )
                        }
                      }
                    }

Got error 'Cannot query field "gatsbyImage" on type "ImageSharp". If you don't expect "gatsbyImage" to exist on the type "ImageSharp" it is most likely a typo.'

What am I doing wrong / how should image data be queried (anything Drupal-specific?)

[KyleAMathews]

@Vacilando this is unfortunately pretty common for our integrations w/ open source CMSs (WP/Drupal) as they have a long history & dozens of potential ways they can be setup. It's easier to test for SaaS CMSs as they typically have only one way of doing things. So rollout of new features with WP/Drupal is unfortunately a bit more lumpy and requires more help from the community to account for all the subtleties of setups out there.

[TylerBarnes]

We're on a call debugging right now 😄 I'll update here with our findings afterwards. Thanks @Vacilando for being so willing to help!

[TylerBarnes]

We discovered the attributes.filemime data is there, I'm currently debugging and trying to figure out why this isn't being set for the mimeType field.

[Vacilando]

I totally understand your point, @KyleAMathews. I just wasn't completely sure whether the Drupal support for Image CDN, new as it is, actually functioned on any other system. Now I know it does, so there might be something peculiar with my setup. I am in touch with @TylerBarnes to find out what exactly the problem is; we'll get to the root of it.

[TylerBarnes]

Figured it out! Image CDN support is only enabled when the skipFileDownloads plugin option is enabled, however we're still registering the GraphQL field even when that option isn't enabled.
@Vacilando you'll need to enable that option to use Image CDN:

  {
    resolve: `gatsby-source-drupal`,
    options: {
      baseUrl: process.env.DRUPAL_URL,
      skipFileDownloads: true,
    },
  },

Once I did that I did encounter another issue - a corrupt image file fails the build (if you want to see it go to [yoururl.com]/sites/default/files/media-icons/generic/video.png)

I released a canary version which does 2 things:

1. warns about corrupt files and skips over them
2. only registers the gatsbyImage field when skipFileDownloads is enabled. If it's not enabled it prints out a message with info about how to enable Gatsby Image CDN for Drupal.

You can install it with this version [email protected]

PR here #35619

[Vacilando]

Wow, looks most encouraging, thanks @TylerBarnes!
I'll give it a try and get back to you with results / comments.

[tqureshi-uog]

@TylerBarnes We just discovered that Image CDN does not work if you use a Hosting Integration like Azure :( However, we still want to use it for local development work and our Gatsby Cloud test sites. We thought we could achieve this by making skipFileDownloads an environment variable but if we set it to false instead of true, it wrecks all the gatsbyImage GraphQL queries as described by others above. This is extremely confusing because of the following lines in Step 4 of your documentation:

gatsbyImage replaces gatsbyImageData. gatsbyImage is compatible whether or not you’re using Image CDN and is the new field for using Gatsby-powered images.

So is the above statement true or not? It appears it's false for any Drupal site - you have to use the old-school gatsbyImageData GraphQL queries for sites that don't have Image CDN enabled. Again, what we hoped to do was keep the new query format so we could easily switch between having Image CDN enabled or not but the documentation is contradictory and confusing as written. Please clarify this issue.

[TylerBarnes]

@tqureshi-uog when you're on a host that doesn't support image CDN Gatsby will fetch the images during the build process. You should use the image CDN fields all the time in your situation.

[tqureshi-uog]

@tqureshi-uog when you're on a host that doesn't support image CDN Gatsby will fetch the images during the build process. You should use the image CDN fields all the time in your situation.

But it doesn't work - we have a ticket open with Gatsby Support about this. On our Azure environment, all image links generated a 404 error when Image CDN was turned on. When we turn it off without reverting to the old branch (that is, the branch that used gatsbyImageData instead of gatsbyImage), we get all sorts of build errors about invalid GraphQL queries. What are we supposed to do? I'm afraid the documentation is not at all clear and is extremely confusing and frustrating to follow.

[TylerBarnes]

Hmm, definitely sounds like there's a bug then. That should work. Are you able to share a reproduction repo?

[tqureshi-uog]

Hmm, definitely sounds like there's a bug then. That should work. Are you able to share a reproduction repo?

I've emailed you a link to our Gatsby Cloud dashboard for the site in question. But I think the following, more generic steps to reproduce should also illustrate the bug:

1. Set up a Gatsby Cloud site using Drupal 9 as the CMS
2. Create some content with images
3. In your gatsby-config.js file, either leave out the skipFileDownloads option for gatsby-source-drupal or set it to false
4. Make sure Image CDN is off in your Gatsby Cloud site settings
5. Set up a GraphQL query using the new gatsbyImage format (as opposed to gatsbyImageData)
6. Now if you attempt to run a build, you’ll get the same GraphQL errors we did, where it tells you it can’t query various fields (e.g. gatsbyImage, mimeType) on type file__file
7. If you run the same build with the GraphQL queries in the old-school gatsbyImageData format, the build will work
8. If you set skipFileDownloads to true and activate Image CDN in your Gatsby Cloud settings, the build will work UNLESS you try to deploy to another host like Azure. Then all your image URLs will be in the format siteonazure.com/_gatsby/image/[etc] which in turn will generate a 404 error (resulting in broken images all over the site)

If I understand you correctly, deploying to an external host should result in Gatsby Cloud ignoring Image CDN settings and downloading all image files the usual way. But you’d have to have skipFileDownloads set to false for that to occur, otherwise no files will be downloaded by the gatsby-source-drupal plugin and your build will fail. And once you set skipFileDownloads to “false” (or eliminate it from your config settings altogether), your GraphQL gatsbyImage queries will break.

Hopefully this clarifies what's going on. To summarize:

• skipFileDownloads set to true and GraphQL queries using gatsbyImage results in broken image links once your site is deployed to an external host
• skipFileDownloads set to false and GraphQL queries using gatsbyImage results in failed builds due to GraphQL query errors
• skipFileDownloads set to false and GraphQL queries using gatsbyImageData builds and deploys to external host successfully

[Vacilando]

Is there documentation of all properties we can use with gatsbyImage (as opposed to gatsbyImageData).

Eg I note that transformoptions documented at https://www.gatsbyjs.com/docs/reference/built-in-components/gatsby-plugin-image/#transformoptions does not work with gatsbyImage - it throws error: GraphQLError: Unknown argument "transformOptions" on field "file__file.gatsbyImage".

[TylerBarnes]

I believe right now the only documentation is in the GraphiQL schema tab. We will be updating the docs you linked to soon though

[rburgst]

It appears that the introduction of IMAGE_CDN the existing image processing for wordpress no longer works which IMHO is a serious regression. See #35626

[ashhitch]

Default Image settings

When using gatsby-plugin-sharp you can set default settings for image-processing, these obviously do not apply to image-CDN, so it would be great if there was a way to do something similar.

{
      resolve: `gatsby-plugin-sharp`,
      options: {
        defaults: {
          quality: 60,
          placeholder: 'none',
          backgroundColor: '#F5F5F5',
        },
      },
    },

[Vacilando]

Using @latest of gatsby-source-drupal (5.15.0), configured placeholderStyleName following instructions at https://www.gatsbyjs.com/plugins/gatsby-source-drupal/#configuring-placeholders-for-gatsby-images

However, at develop and on Gatsby Cloud I get the following:
Warning: there are unknown plugin options for "gatsby-source-drupal": placeholderStyleName

[TylerBarnes]

Good catch, thanks for reporting that. I'll fix it :)

[TylerBarnes]

#35644

[Vacilando]

Nice, how can I install the plugin with the merged code?

[TylerBarnes]

You can install it with [email protected]

[startinggravity]

I've run into an issue with querying posts from my Drupal site when the query includes an image using gatsbyImage. Here is an example:

relationships {
  field_main_image {
     gatsbyImage(width: 300)
   }
}

My build crashes if I don’t set a limit for the query results. From what I've tested so far, the build will not crash if a limit of 200 is set. The build crashes with a limit of 500 or if no limit is set.

The build doesn’t crash unless gatsbyImage is included in the query.

[TylerBarnes]

@apmsooner this is likely because your queries use a placeholder image and that file needs to be downloaded while the query is running to create the placeholder effects (notice the image_gallery field has the default placeholder). Did you set a small placeholder image size in Drupal?

[apmsooner]

@TylerBarnes - yes i have it set and it shows up in my derivatives. I used the same naming convention so didn't explicitly set it in gatsby-config.js since the docs say the default is what is used.

[apmsooner]

@TylerBarnes - docs do imply that the default matches up what i have here so thats why i didn't even set it in config.

{
  resolve: `gatsby-source-drupal`,
  options: {
    placeholderStyleName: `custom_placeholder` // default is `placeholder`
  }
}

[apmsooner]

I went ahead and explicitly set it to "placeholder" and i set to placeholder: NONE for both fields but neither of those changes affect build speed. It gets to this part and takes minutes per % point on that last task so I'm guessing build time when complete is probably looking like upwards of an hour. It only takes a few minutes when running: gatsby develop

[apmsooner]

@TylerBarnes @startinggravity - my understanding now is that gatsby build is not designed to be ran locally when cdn is enabled because there is no cdn in a local environment and the cdn emulation that happens in development mode is not applicable to local builds. That makes sense now why builds were stated to run normal in the cloud but really slow locally. I should have thought that one through but a clarifying statement in docs might be helpful too maybe under a "known limitations" section.

[mwskwong]

So how does it work when Image CDN meets headless CMS like Contentful, which has its own image CDN?

Practically, the images are now located in <your-domain>/_gatsby/image/... instead of images.ctfassets.net/.... How's that different from downloadLocal: true?

[TylerBarnes]

downloadLocal: true causes slower build times because assets are downloaded and transformed during the build process. With Image CDN they're not downloaded during the build process and are instead fetched from Contentful and transformed when the first frontend user requests that image.

As far as Contentful's CDN vs Gatsby Cloud Image CDN, you will get a frontend performance benefit due to Gatsby Cloud Image CDN serving assets from the same domain as your Gatsby site instead of from a different domain.

[mwskwong]

I see. Thanks. Well, that seems much better than downloadLocal since you got the best of both worlds.

I would assume other assets, like PDFs also get the same "caching-like" behavior?

[TylerBarnes]

They do! :) you can use the publicUrl field which should be a sibling field to the new gatsbyImage field. That will give you a CDN URL for a static file.

[Mrchow86]

[deleted] Nathan Grzesik

…

On Sat, 8 Oct 2022, 2:58 am Tyler Barnes, ***@***.***> wrote: I opened a PR adding support just now #36772 <#36772> You can try it out with these canaries: - ***@***.***+74fb9797c3 - ***@***.*** +74fb9797c3 - ***@***.***+74fb9797c3 - ***@***.***+74fb9797c3 - ***@***.*** +74fb9797c3 - ***@***.***+74fb9797c3 If it's not working after installing the canaries, try setting a yarn resolution: { "resolutions": { "gatsby-plugin-utils": "3.19.0-alpha-image-cdn-pathprefix.47" } } — Reply to this email directly, view it on GitHub <#35147 (reply in thread)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AX4R2JXHHGYGVGOTUSNFNL3WCBXEPANCNFSM5Q4HAWBA> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[TylerBarnes]

@Mrchow86 if you're getting unwanted notifications on this Github discussion you followed it at some point and need to unfollow it. If you're confused, the unfollow button is in the top right of this page.

[violy]

I've no answer after 8 days on my dedicated discussion…

I'm try to use gatsby-image with tracedSVGOptions and gatsby-source-wordpress.

According to my GraphQL exemple query in the original discussion, the featureImage.node.gatsbyImage query fails when I'm using tracedSVGOptions. My current workaround is to use featureImage.node.localFile.childImageSharp.gatsbyImageData !

But I'm trying to migrate to Gatsby Image CDN … and localFile is null …
→ because plugin configuration is MediaItem: {createFileNodes: false,},

Why tracedSVGOptions option and others Gatsby Image sharp options is not simply exposed by gatsby-source-wordpress plugin in GraphQL ?

Thanks.

[laradevitt]

Hi there. We're using the gatsby-source-drupal (5.25.0) plugin. Wondering if there is a way to exclude certain files, or certain types of files (e.g. PDF), from Gatsby Cloud Image CDN handling (so only those files will be downloaded locally)? I'm getting sporadic server errors on our PDFs (reported to Gatsby Cloud) and am looking for a temporary workaround that doesn't involve manually adding the files to the static/ folder. (Edit: Problem fixed but still interested in this functionality.) Thanks!

[KidusB9]

As a developer, I have found the Image CDN feature to be very useful. It has greatly improved the performance of my website, as the images are now loaded faster due to the CDN. The integration of the feature into my website was also straightforward and did not require much effort.

One thing that I would like to see improved is the available image transformations. It would be helpful to have more options for resizing and cropping images, as well as the ability to add custom transformations.

Overall, my experience with Image CDN has been positive and I would recommend it to other developers. Keep up the good work!

[chawes13]

When replacing gatsbyImageData with gatsbyImage, I've found the local development experience degrades significantly. Page requests frequently route to the development 404 page and the logs show errors for the query results timing out after 15s.

Is this an expected tradeoff for pages that haven't been cached locally yet or is this a hint of some other underlying issue?

[TylerBarnes]

What kind of query is being made on that page and which CMS are you using? Image CDN fetches placeholders and images at query time during development. If you're querying for a lot of nodes all at once it could be making more requests than your server can handle.

[TylerBarnes]

Also are there other errors above this one?

[chawes13]

We're using Contentful and pulling in around 7-10 images per page. This issue appears to occur most frequently when there are simultaneous requests triggered by a link hover, which is easy to trigger when using a mouse within a nav menu. Based on your previous comment it sounds like that is just overloading my local server.

[TylerBarnes]

Hmm, well with Contentful I don't think that would be the problem since Contentful can handle a lot of simultaneous requests 🤔 Your local server also shouldn't fail processing that many images. I wonder if there's a query timeout baked in somewhere and processing the images just takes longer than that timeout. Is it possible I could use your site to reproduce the issue?

[chawes13]

Unfortunately I'm not in a position to share the code. I switched back to using gatsbyImageData and it resolved these issues. The site isn't hosted on Gastby Cloud, so we weren't really reaping the benefits of the feature anyways (as far as my limited understanding goes).

[PercyTuncar]

Error

3:59:52 PM: error There was an error in your GraphQL query:
3:59:52 PM: Cannot query field "sizes" on type "ImageSharp".
3:59:52 PM: If you don't expect "sizes" to exist on the type "ImageSharp" it is most likely a typo. However, if you expect "sizes" to exist there are a couple of solutions to common problems:
3:59:52 PM: - If you added a new data source and/or changed something inside gatsby-node/gatsby-config, please try a restart of your development server.
3:59:52 PM: - You want to optionally use your field "sizes" and right now it is not used anywhere.
3:59:52 PM: It is recommended to explicitly type your GraphQL schema if you want to use optional fields.
3:59:52 PM: failed extract queries from components - 2.005s
3:59:52 PM: ​
3:59:52 PM: "build.command" failed
3:59:52 PM: ────────────────────────────────────────────────────────────────
3:59:52 PM: ​
3:59:52 PM: Error message

[agnescameron]

Hi, getting the error during build WorkerError: Expected positive integer for width but received 0 of type number when pulling mediaItems from Wordpress. Currently can't even get the paths of the requested items to log so very hard to debug -- any pointers appreciated. Using gatsby-source-wordpress

[laurenskling]

i've had this in the past as well. manually debugging the limit +1 until you hit the error to zone out the image that is crashing. Meaningful errors (stating which image is failing) would be extremely helpful, if not mandatory, in these cases.

[TylerBarnes]

I can see how that would be very frustrating, I'll take a look at improving the error message to include more info. Thanks for chiming in!

[samtous]

Any updates on this? Thanks! 🙏

[TylerBarnes]

Not yet but I have it on my list to look at this :)

[Korben00]

Hi everyone,
Concerning this problem: Error : Expected positive integer for width but received 0 of type number

until this is solved, I suggest a debugging method. You have to edit the file node_modules/gatsby-plugin-utils/dist/polyfill-remote-file/transform-images.js and add the following line after line 102:

console.log("outputPath", outputPath);

This will allow you to see the path of each file processed and thus to more easily locate the files that cause problems.

Good luck