The image resize endpoint redirects to the actual image (causes slowness)

Using Ghost
1

Hello,
I noticed that the /content/images/size/wNNN returns 302 redirects in the response.
Then another request is being fired to the actual image at /content/images/*

That’s slow!

See the waterfall chart:

tsehCPpd14
tsehCPpd141313×793 62.7 KB

2

Hey there @RadoslavGatev! From what I can see in the screenshot I believe these assets are coming from this article Continuous Deployment of SQL Server Data Tools (SSDT) Projects, Part 1: Make it repeatable and self-sufficient ?
I checked the image responses and they’re all 200

33
33748×1570 213 KB

I’m guessing what happened is that you published the post and looked at the image responses very soon after? The images were probably still being processed at the time.

Hope this clears things up :slightly_smiling_face:

3

Correct, these assets are coming from various posts.

All my posts were published on v2.X where I believe this image resizing was not implemented yet. What should I do to trigger the processing?

4

Image processing has been in Ghost since v2, you can read more about it here:

Image processing is triggered automatically, you just need to wait until all images are processed. The time it takes depends on the amount of images and how large they are :slightly_smiling_face:

5

Well, how much time is the processing supposed to take? My blog has been updated to 3.0 for at least 5 days now.

Can I see the code that does the processing in background?

6

As shown in the screenshot before, your images have already been processed. Are you still seeing 302 redirects for image assets?

7

Yes, still get redirects. Here is the code I deploy: GitHub - RadoslavGatev/gatevnotes

This image is one example of those redirects: https://www.gatevnotes.com/content/images/size/w1000/2019/02/ssdt-devops-ci-cd.jpg You end up landing at /content/images/2019…

8

Any ideas? I still get redirects even when the post was just posted. What can I check? How does the processing work besides the fact it’s automatic?

9

Resized images are generated on the fly when a sized image URL is requested and then cached for subsequent requests, there is no background processing job.

A 302 to the original image will occur in the following situations:

  • it’s a file type that can’t be resized (eg, .svg, .gif, .ico)
  • there is no image_sizes config in the active theme’s package.json
  • the requested image size is not present in the image_sizes config
  • the active storage adapter does not support image resizing (it must have a .saveRaw() method)
  • sharp dependency is not installed

Does your theme’s package.json contain an image_sizes config with the sizes that you are requesting? Are you using a custom storage adapter at all? Are you attempting to run a cluster/load balanced system?

1 Like
10

Thanks for the reply, @Kevin!

  • FIles are either .jpg or .png
  • image_sizes is present in package.json of the theme, I use Casper
  • the requested image size is present in the image_sizes config
  • I don’t use a custom storage adapter
  • Hmm, okay I see sharp is defined as an optional dependency. Let’s consult the deployment logs:
Selected npm version 6.9.0
Updating iisnode.yml at D:\home\site\wwwroot\iisnode.yml

> sharp@0.23.2 install D:\home\site\wwwroot\node_modules\sharp
> (node install/libvips && node install/dll-copy && prebuild-install) || (node-gyp rebuild && node install/dll-copy)

ERR! sharp Windows x86 (32-bit) node.exe is not supported
info sharp Attempting to build from source via node-gyp but this may fail due to the above error
info sharp Please see https://sharp.pixelplumbing.com/page/install for required dependencies

D:\home\site\wwwroot\node_modules\sharp>if not defined npm_config_node_gyp (node "D:\Program Files (x86)\npm\6.9.0\node_modules\npm\node_modules\npm-lifecycle\node-gyp-bin\\..\..\node_modules\node-gyp\bin\node-gyp.js" rebuild )  else (node "D:\Program Files (x86)\npm\6.9.0\node_modules\npm\node_modules\node-gyp\bin\node-gyp.js" rebuild ) 
Building the projects in this solution one at a time. To enable parallel build, please add the "/m" switch.
  VError.cpp
  VInterpolate.cpp
  VImage.cpp
  win_delay_load_hook.cc
..\src\libvips\cplusplus\VError.cpp(33): fatal error C1083: Cannot open include file: 'vips/intl.h': No such file or directory [D:\home\site\wwwroot\node_modules\sharp\build\libvips-cpp.vcxproj]
..\src\libvips\cplusplus\VImage.cpp(41): fatal error C1083: Cannot open include file: 'vips/intl.h': No such file or directory [D:\home\site\wwwroot\node_modules\sharp\build\libvips-cpp.vcxproj]
..\src\libvips\cplusplus\VInterpolate.cpp(34): fatal error C1083: Cannot open include file: 'vips/intl.h': No such file or directory [D:\home\site\wwwroot\node_modules\sharp\build\libvips-cpp.vcxproj]
gyp ERR! build error 
gyp ERR! stack Error: `msbuild` failed with exit code: 1
gyp ERR! stack     at ChildProcess.onExit (D:\Program Files (x86)\npm\6.9.0\node_modules\npm\node_modules\node-gyp\lib\build.js:262:23)
gyp ERR! stack     at ChildProcess.emit (events.js:198:13)
gyp ERR! stack     at Process.ChildProcess._handle.onexit (internal/child_process.js:248:12)
gyp ERR! System Windows_NT 10.0.14393
gyp ERR! command "D:\\Program Files (x86)\\nodejs\\10.16.3\\node.exe" "D:\\Program Files (x86)\\npm\\6.9.0\\node_modules\\npm\\node_modules\\node-gyp\\bin\\node-gyp.js" "rebuild"
gyp ERR! cwd D:\home\site\wwwroot\node_modules\sharp
gyp ERR! node -v v10.16.3
gyp ERR! node-gyp -v v3.8.0
gyp ERR! not ok

I think that’s the reason. Okay seems like sharp documentation clearly states that Only 64-bit (x64) node.exe is supported.. I am not an expert in node but what will happen if I use node x64 just for installation and then run the site with node x32?

11

That probably wouldn’t work, since the binaries would probably be incompatible… is there a reason you’re using 32bit?

12

Yes, I am using the free tier of Azure App Service which allows you to use x32 only. Besides that you achieve a better density using 32 bit apps in Azure App Service, so more bang for the buck in case you pay for it.