Skip to main content

Comments

20 comments

Date Votes
  • Eyal Katz Talmon

    Hi, thanks for reaching out!

    In order for me to better understand the described issue, could you kindly check for the "x-cld-error" header, and let me know of its value? In addition, could you try the simplified image tag below and let me know if the "bad image" is displayed?

    <cl-image loading="lazy" 
              width="386" height="225"
              public-id="sample"
              default_image="noimage.png"
              secure="true">
       <cl-placeholder type="pixelate"></cl-placeholder>
    </cl-image>
    0
  • Bjorn Harvold

    Hi Eyal!

    It is actually no error coming back from Cloudinary. The no image means the image is still loading. I took at the image urls and saw something interesting.

    Attaching a video:

    https://www.dropbox.com/s/sy8xf3x1ug5nceu/cl-pixelate-2.mov?dl=0

    The first 13 images in my card list does not contain e_pixelate on the url. I'm thought it had something to do with loading="lazy" and what it does with the viewport so I removed it, but it did not change the fact that the first 13 images never contains e_pixelate on the url.

    So definitely some monkey business with your viewport code I am guessing here.

    0
  • Bjorn Harvold

    By the way, the English in my last post was messy to say the least ;-) Did this while on a conf call 

    0
  • Shirly Manor

    Hi Bjorn,

    Are you referring to our lazy loading feature? 

    You can read more about it here: https://cloudinary.com/blog/how_to_get_killer_page_performance_with_angular_lazy_loading#lazy-load-cloudinary

    Looking forward to your response, 

    0
  • Bjorn Harvold

    Hi Shirly,

    Please read the contents of the ticket and specifically the issue I am experiencing.

    Cheers

    1
  • Eyal Katz Talmon

    Hi Bjorn,

    I've consulted the originally described issue with the dev team, and we're still looking into it, however, we didn't manage to reproduce the behavior on our end yet. This means that the issue might be related to your specific environment/project.

    In order for us to further investigate, could you kindly provide the below information?

    • Could you confirm whether the issue persists when omitting the "class" attribute?
    • Does the issue occur with different placeholder types? Can you try using the "blur" (default) type as well?
    • Does the issue reproduces with all images, every time, or, does it happen intermittently?
    • Could you try setting the "public-id" in a non-dynamic manner? (e.g - setting it to "sample")
    • Could you try setting the "default-image" to "sample" as well?\
    • Is there any live/staging site we could use in order to see the issue and try to debug it?

    Any additional information would be greatly helpful.

    Regarding your observation -

       "The first 13 images in my card list does not contain e_pixelate on the url. I'm thought it had something to do with loading="lazy" and what it does with the viewport so I removed it, but it did not change the fact that the first 13 images never contains e_pixelate on the url."

    In general, that's the designed behavior. When using lazy loading, requests for the pixelated images are sent on load, and requests for the actual images are sent when entering the viewport. It looks like the component/page was loaded into the relevant viewport, and that caused the requests for the actual (non-pixelated) images to be sent before. In that case, it still makes sense to send requests for both place holders and images, so the end-user can see the placeholder until the image loads.

    When omitting the loading="lazy", both the pixelated ant actual images are being requested on loading time. That's because the pixelated images are downloaded much faster, and could be displayed until the actual images are downloaded. 

    Does that make sense?

    Looking forward to your reply regarding the above followup questions.

    Regards.

    0
  • Bjorn Harvold

    Hi Eyal,

    I went through the steps you mentioned. Nothing changes the fact that the first 13 images do not have e_pixellate on it. Blur also did not change that. When I removed loading=lazy, 30 of the first images did not have e_pixellate on them.

    I have made our traveliko.com staging environment available for you to look at. Unlike our production environment, I've removed our custom image loader code and I am using your cl-image tag with lazy loading and the pixelate placeholder. The homepage is a good place to see this in action:

    https://staging-www.traveliko.com

    0
  • Jay Akhtar

    Hi Bjorn,

    Following your previous screen recording, I tried to work on the staging link provided by you, I noticed the search stalls when any keyword is typed. The loading wheel keeps spinning in the search area. No results are returned. Network tab shows one GET request to

    Request URL: https://staging-www.traveliko.com/ngsw.json?ngsw-cache-bust=0.647851733230863

    Is it possible to provide steps on this? or any additional information that can be useful.

    Best regards,
    Jay

    0
  • Bjorn Harvold

    Hi Jay,

     

    Staging server is not on all the time. I have turned it on again now and it will remain on for 14 hours.

     

    Cheers

    0
  • Eyal Katz Talmon

    Hi Bjorn,

    I'd like to clarify a few things in order to make sure we're on the same page. When using lazy loading with a placeholder (e.g pixelate), requests for the actual images (i.e - not the placeholders) are being performed as soon as the images enter the viewport, or, a buffer of pixels around the viewport. 

    This means that URLs without e_pixelate are supposed to be sent as soon as the images enter this "buffered viewport". My assumption is that those 13 requests are made for images that are located within that space. Thus this behavior seems to be as designed.

    In addition, notice, that each of the images with non-pixelated requests has another request (below the 13 requests) that does have the e_pixelate parameter. This serves the functionality of the "place-holders" - showing a lighter version of the image until the actual heavier version loads.

    Does that make sense?

    Please let me know if you have any additional questions.

    0
  • Bjorn Harvold

    Hi Eyal,

    Thank you for the clarification. What I am seeing when I remove loading=“lazy” is that 30 of the first images not having e_pixelate on the url. What I want is that every image is served up w the e_pixelate tag. Otherwise, the user sees this browser native placeholder of a missing image until the actual image loads. Isn’t that what the pixelate placeholder was designed for? To remove that user experience? Until your placeholder functionality came along, we had to make use of the imageOnLoad functionality w an extra div overlay and it was not a pretty solution.

    Would love to know how to properly make use of the new placeholder so users first see the pixelated version until the real image finishes loading.

    Cheers,
    Bjorn

    0
  • Eyal Katz Talmon
    Edited

    Hi Bjorn, 

    Thank you for your reply, and I apologize for the back and forth.
    Of course, users should not see the browser's default placeholders (the broken image icon). 
    In order for me further investigate and trace the issues' origin, can you confirm that the staging environment is currently running?

    How can I reproduce the issue with the staging environment? Do I need to register?Currently, I can only see this interface.

    Thanks!

    Eyal

     

    0
  • Bjorn Harvold

    Hi Eyal,

     

    The staging environment is only available on request and not 24/7. I have turned the server on again and it will remain on for another 8 hours (end of my day).

    You should see hotel data displaying. Let me know if you have any questions for me.

     

    Cheers

    0
  • Eyal Katz Talmon

    Hi Bjorn,

    I just wanted to let you know that our dev team is currently investigating the issue, and I'll let you know about any insight we have regarding it.

    In addition, we'll let you know if/when we need your staging environment to be running - for testing and reproduction purposes.

    I think it is best to create a support ticket at support@cloudinary.com (or submit a request via our support center) and continue the correspondence there. If that is alright with you, kindly open a ticket and mention this forum thread as a reference (you can also mention my name). However, if you prefer continuing the thread here, that's alright as well.

    Regards

    0
  • Bjorn Harvold

    Done

    0
  • Stijn Beeckmans

    Hi @Bjorn,
    I'm running into the same problems as you...
    Did you find a solution for your problem via the support ticket? Can you provide a link here to the support ticket?

    0
  • Bjorn Harvold

    Hi Stijn - These issues have been resolved in v2 beta. If you’re ready for a massive upgrade check out the beta docs. We are not ready yet.

    0
  • Eyal Katz Talmon

    Hey Stijn, as Bjorn mentioned (thanks!), these issues are fixed in the JS v2 SDK which is in beta at the moment. Be sure to let us know if you have any questions or need assistance - you can open a support ticket here.

    Cheers

    0
  • Originate

    I am having the same issue with @nuxt/cloudinary module. using the image component it seemed to me that the class applied on the Vue <cld-image> component was causing this. But now it just seems random after ive been testing it its happening intermittently . Can you advise on best practice here ?

    0
  • Loic Verger Del Bove

    Hi there,

    As Eyal and Bjorn mentioned, these issues are fixed on the v2 of our frontend SDKs, the Vue SDK v2 is not yet ready but we are working on it. 

    Thanks for your patience.

    Loic

    0

Post is closed for comments.

Didn't find what you were looking for?

New post