locked
High TTFB for both Akamai and Verizon RRS feed

  • Question

  • Hi, I am getting very high Time To First Byte for cached images via Azure CDN

    via Akamai: 700ms-1900ms

    via Verizon: 150-500ms

    Using an other service provider (which uses Akamai CDN) I get TTFB as low as 5-20ms.

    Kindly look into the issue.

    Wednesday, July 19, 2017 12:13 PM

Answers

  • I see theres a Vary:origin header in the response. On Akamai, if any Vary header exists with a value other than accept-encoding, it will not be cacheable. You must remove it before it can be cached on Akamai.

    Verizon's default behavior is to strip the vary: origin header and then cache the asset.

    • Marked as answer by AK Lodhi Friday, July 21, 2017 3:30 PM
    Thursday, July 20, 2017 10:53 PM

All replies

  • This could be variety of reasons. Please provide the URLs for your test image.
    Wednesday, July 19, 2017 7:23 PM
  • Hi Richard. Here are the links to a test image:

    Azure-Akamai:
    https://trell.azureedge.net/images/mini/gMoYQnWnr02J8ItTxTYY.jpg

    Azure-Verizon:
    https://trell-cdn.azureedge.net/images/mini/gMoYQnWnr02J8ItTxTYY.jpg

    Using other service provider (which uses Akamai CDN):
    http://res.cloudinary.com/trell/user-content/images/mini/gMoYQnWnr02J8ItTxTYY.jpg


    Azure-Verizon has acceptable TTFB values while Azure-Akamai is takes around 1.5 seconds to deliver the first byte.

    • Edited by AK Lodhi Thursday, July 20, 2017 8:29 AM
    Thursday, July 20, 2017 8:25 AM
  • I see theres a Vary:origin header in the response. On Akamai, if any Vary header exists with a value other than accept-encoding, it will not be cacheable. You must remove it before it can be cached on Akamai.

    Verizon's default behavior is to strip the vary: origin header and then cache the asset.

    • Marked as answer by AK Lodhi Friday, July 21, 2017 3:30 PM
    Thursday, July 20, 2017 10:53 PM
  • Thanks a lot.

    I'll remove the header.

    Friday, July 21, 2017 3:31 PM