Ă۶ąĘÓƵ

Transcript

Hello and welcome everyone. Thank you for joining today’s tech sessions. My name is Yodon and just a couple of housekeeping notes before I let our presenter take it away. We encourage and hope you ask questions throughout this presentation in the Q&A chat available in the right corner when the presenter is speaking. However, rest assured that the last 5 to 10 minutes or so of the presentation are dedicated to answering your questions.

Additionally, as many of you will probably ask, a link to this recording will be emailed to all of you in about 24 hours and will also be available on Ă۶ąĘÓƵ’s ExperianCQ website should you wish to view it again or share it with your colleagues. Alright, perfect. I’m going to hand it over to David. Good luck and enjoy everyone.

Hello, good morning everyone. Well, I guess that’s all relative. I’m on the East Coast, so good afternoon to the folks who are at my time zone or a little bit beyond it. My name is David. I’ve been with Ă۶ąĘÓƵ for close to seven years now and I’m one of the Fastly subject matter experts. I’d like to go over kind of a little bit about kind of how it works, common things that you’ll run into, some case studies on some successful and less than successful merchants who have been working with us and hopefully give you guys some inspiration for where to take things to improve your website performance. Looks like we’ve got a few folks still streaming in, so I won’t jump too much. I won’t jump too deep just yet. Yep, that’s me. Despite being here for about seven years, I’ve been in the hosting business for about 20, so I do have some experience at various different levels and kind of started mostly from the infrastructure side, so I have a pretty solid understanding of where all these pieces fit in. So the agenda I want to go over, first off, I’m going to talk about why it’s very crucial to your site. We don’t just bake it in because we like it. We as Ă۶ąĘÓƵ believe it is absolutely critical to having a fast and reliable and stable website at scale, so we want to make sure everybody starts off on that advantage. As I mentioned, I want to go over some common complications. This isn’t going to cover everything, but the most common things I tend to see that filter in through the support side. As I mentioned, I want to go through some case studies of some of our excellent customers, some of the ones that definitely do need some work and are working towards it, and then kind of where to go next. So whether that is how to reach our support, what our support can help you with, and maybe a little bit of what they can’t help you with, and some resources for where to go next. And then as I already mentioned, we’re going to go through some Q&A. I don’t know if we’ll get every single question answered, but I’d certainly like to answer as many as I can. And if you have anything that is super unique or super specific to your website, if you are an Ă۶ąĘÓƵ Commerce Cloud customer and we can’t get to you, feel free to reach out to us. We may be able to help you through our case system on C140 through the Experience League. So as I mentioned, it is crucial. I’m not tooting my own horn here, speaking about how important it is. Personally, I believe it’s one of the most important aspects of your site. Even if you’re having certain other inefficiencies at the code level of performance issue, those are far less noticeable if those issues only occur one in 100 or one in 1,000 requests rather than every single time. If any of y’all have been in a call with me before, you may recognize the image I’ve got here as an analogy I tend to frequently use. If you imagine your website as a bookstore and every page is a book, your end users are going to be so much happier if they could just pick that book up off the shelf, walk out the door with it rather than every single time there’s a request that comes in, someone’s got to print it page by page. Now for certain cases, if you have things that are completely unique, absolutely, I can understand why you’d want to have certain things generated on the fly. But for the vast bulk of things, your About Us page, catalog items that aren’t going to change per user, it’s a much better experience for your end users and honestly for you to have that caching set up. You’ll see that you have minimal, as I said, word of gear, often zero overhead to the origin server. We have merchants that have a high cache volume and they can scale extremely large on an extremely limited server compared to our other merchants that have a lower cache ratio. As I mentioned, that’s going to lead to great user satisfaction and I didn’t put it here as a bullet point, but if it is something of concern to you, it’s a lower cost. Now beyond just that, there’s other things you can do with it. If you have multiple things, not just your store, let’s say you’ve got your blog or Wiki or forum, you can house those as far as your end user is concerned on the same domain, even if they’re not on the same server and the same service. There are some built-in functionalities in the Fasting module to do that. A lot of folks have probably already done that. It does have some limitations, but while we can’t necessarily provide support and guidance beyond that initial setup, it is very handy for a lot of merchants who may want to have multiple aspects to their site on their main domain rather than as a subdomain. One of the things that we do provide here, and this is also a big bullet point as to why it’s crucial, is we have our own customized version of the WAF that Fastly offers. If you were a direct Fastly customer, you will still get a WAF and it’s still a good WAF, but we’ve done some additional work with them to sort of tweak it for what we believe commerce websites need more.

So okay. Now, one of the reasons why I tend to point out that caching is so important is not every request is equal. A common misconception, and it really stems from how this is phrased, is the higher your volume of traffic, the more strain is placed on the server, and folks tend to expect that to be a straight curve. That’s not the case. It’s more of a bell curve, and it depends entirely on the nature of the requests that are coming in. You may actually find that some of the most performance draining on your website might be your landing page. If you have, even if it’s not a very complex page, because it’s getting a high degree of traffic, and it’s uncertain how complex that page is, some people have very simple landing pages, some people have very complex landing pages. That’s definitely one of the biggest targets towards performance degradation when caching isn’t there. Beyond that is search, and it kind of its little cousin there, the category page. The reason why those two are separate, but they’re still together is, I don’t know, for the folks that are not into the nuts and bolts of the commerce, and for the nuts and bolts into the commerce underlying system, if you ever go to a catalog saying, all widgets of this type, so let’s go back to the book analogy, all paperbacks, that’s actually a wrapped search query. So even if you are adding some layer of caching, you’re reducing the overhead, the work required to run that search over and over and over again when somebody’s just looking for paperbacks, and that may not change from person to person.

So as I mentioned, as you can see on the slide, the reason why is that’s also a degree of variable complexity and variable load, depending on whether you’re using open search, elastic search, Ă۶ąĘÓƵ Live search, some modules have kind of back ported the old MySQL search, which is not great in terms of performance, but certainly that can be smoothed over if caching is available. The product pages themselves, for a lot of folks, this is kind of overlooked. Now, unless you are in a business where you’re offering unique pricing for every single individual user, you go searching for a specific product, it’s not going to change from person to person, except maybe when it runs out of stock. So it is essential to keep that cached as well. And at the bottom, the things that are probably the least harmful, but absolutely no real reason not to cache would be your CMS pages and your page fragments, things like your about us page or a little bit of detail that doesn’t necessarily contain products, your headers, your footers, those don’t necessarily change from page load request to request. So why not cache them? Why not reduce that overhead for things that are never going to change? All right. So some of the most common complications I have seen filtered through our support team, they fall really into three different major categories. These are not meant to be all encompassing. There are certainly other things beyond these three. But these are the three that tend to have the most tricky resolutions. The first is actually a stat CDN. We don’t officially support this, but we do have a lot of merchants that will put Cloud Front or Cloudflare or Akamai in front of their website. Now, this does add some complications to our support team at several layers. The first off is our logging is no longer 100% reliable. And now it’s not going to not record an event. But the IP address that is going to be recorded in our log is going to be that other CDN. It’s going to be Akamai or Cloudflare or Cloud Front. So if you are getting, say, a denial of service attack or a malicious user, we can’t act to block out on your behalf. You’d have to go into the logging provided by those services and block it there. Unfortunately, since we don’t have that visibility and because it is coming through that other layer, that’s the best place to direct such an activity. But there’s other complications on top of that. Those services may have their own caching policies. And so you may see issues where pages that have been updated or refreshed, even if you’re running a cache clear here, you’re not seeing that updated content on the web. And that might be because of those other cache policies. We don’t have a direct way of observing that. And we don’t have a direct way of correcting that. And usually we do have to say, hey, we’ve detected this. Try to test on that other service, validate your settings there. And actually I see a great question here, effective solution for two CDNs. The way I try to describe this with folks is we don’t tell you you can’t do it. And we don’t want to tell you you can’t do it. Every site is unique. Everybody’s requirements are unique. But it does take some of that support model and it moves some things around a bit. Because it impacts our visibility and our ability to make certain actions, it pushes some aspects that normally we would handle here. As I said, things like security for denial of service attack. And that kind of pushes it onto you or to your other provider. Likewise, same with logins. Since ours is no longer 100% accurate, you’d have to do your traffic logs through that system to get the source of truth. Some folks that’s a good trade off because they may have certain requirements that are dictated to them by their department heads. For other folks, it does become a stumbling block. And we’re more than willing to work with you as best as we can. But there are points where if we no longer have that direct layer, level of influence or visibility, it does limit us a bit. And that’s actually the next bullet point down there is once that second layer is added, there are limitations that we want to help you with, but we can’t overcome from our position because we don’t have access to those systems.

As I mentioned, so beyond the two factor authentication, if you do have questions about that more, we can go over that absolutely afterward. The other most common thing would just be that the cache is broken or disabled. Now, the reason why I have to put these two together is there are folks that do have per the way their site is implemented or per other directives, they are intentionally running with cache disabled. I do want to throw a word of caution. Sites in that state do not meet our go live requirements. So that does mean that if you are impacted, if there’s an uptime impacting event, what we can do is rather limited. In those cases, it’s usually simply an upsize because we can’t do anything to address the actual kind of going back to that prior slide, all of those objects that are unequal, we can’t necessarily address. Now, some things that can be done would be to limit or throttle traffic as well. But do keep that in mind because that may be worth discussing more. If you have aspects that can’t be cached, maybe move those to say an Ajax call on a cashable page.

As I mentioned, you’re going to notice those sites that are not cached properly or have not been cached, they are going to be slower, just generally overall, but particularly during periods of higher graphic, whether that’s legitimate or otherwise. So usually you’re going to get higher user satisfaction with that cache state and kind of to expand on that, whether it’s a bot crawler or actual malicious attacks, even a benign thing like Google or Bing will affect your site performance. I think a third most common complication we see with folks is slow updates.

And actually there’s really one common reason for that, and it’s the soft purge option. Generally, we require, or I don’t know if we require, we advise it if you have a site that has a high degree of traffic. But I do want to let you know that that’s kind of a trade-off. What you are doing when you enable the soft purge option is you’re trading speed for accuracy. What the soft purge does is it marks an item in cache as stale, which means it’ll continue to serve that item to your end users while the update is happening in the background. Now that does two things beyond the obvious, serving the old content. It also means that even though you are serving cache data, the load on your end server is still higher. So other actions that we usually advise and best practices of clearing your cache outside of normal or peak business hours, that would still fall in line even if you’re using a soft purge. The soft purge is handy if you have an emergency need to clear cache, but it’s still not advisable to do that at the middle of peak traffic.

Now, another common reason for that would be if you have TTL, a very high TTL, and you may actually notice that it’s not fastly cached that slow to update. It might be something embedded in the folks that are not using versioning for their file names. So if you have a, it’s a banner.png in your theme and you update your theme and you’re calling your next banner banner.png instead of say banner version two, what you’ll see is if you have a one-year TTL for at least one year, people are going to be seeing the old banner. So that is something that is easily addressable, but it’s not necessarily a fastly problem, but it certainly can be.

All right. Now, beyond user or experience issues, you may have some common code issues. Our support team really isn’t a development resource, but we will often try to point you in the right direction. And both at the end of this and in one of the future slides, I do have some links for y’all that’ll take you to our development resources, fastly development resources. I didn’t include a link for it, but I will put that here in the chat later for fastly fiddle, which is an excellent resource to test and validate your code before you push it. Even if you’re pushing at the staging, why bother pushing a whole new VCL version if you’re not 100% certain it’s going to work. There’s limitations to fiddle. It is not 100% feature equivalent of a live version, but it is a really good way to do your tests and mockups very quickly. Now, the most common thing you might notice, say you’ve got a custom ACL block list or allow list, you might say that, well, they’re not filtering traffic. Now, the first thing to check for is if you are using a match against client.ip. Now, in a traditional hosted varnish instance, that’s the variable to use. That is absolutely correct. I am not going to tell you it’s not. In fastly, it’s a bit more complicated because this is a distributed CDN.

Plant.ip is always the last hit in a hop. And when you’re talking about a global CDN, you might have multiple hits before it reaches your origin server or before the code is actually executed. Fastly does have an alternative variable for that. It’s actually an HTTP header called rec. HTTP fastly client IP. That is recorded as traffic enters the fastly network. And that is always what you should use if you are setting up something to check against the IPs. Just consider it good practice, good habit to keep up. Now, granted, caveat to that that’s not covered here. If you’re on a stack CDN, this won’t work at all either. The true IP will only be on that outer layer. And that is where those ACLs, the allows, the denies, that is where those need to occur. Now, the second thing you might see is the new VCL you employed isn’t running. Hopefully, we’ve all tested on Fiddle. If we haven’t, run a mockup, see if there’s any obvious errors returned. Usually fastly won’t let you push code that has an error in it. But every once in a while, that does occur. The next thing to check for that, though, is the priorities. They may seem kind of arbitrary, but the priorities run from lowest to highest. And one of the most common things I see when people are saying, hey, my new code isn’t working, is they’ve just assigned it with a default priority, which is about 100. Now, most of the Magento facing, Ă۶ąĘÓƵ Commerce facing code runs at about a prior of 50. There’s run lower at 80 and some that run incredibly high at 5 and 10. If you notice your code isn’t running, try pushing that priority forward. Try, instead of the default 100, try default 50, try default 40. It’s possible you may have other VCL that might work on the same aspect that’s running first and terminating. I realize I’m talking a lot. So if anybody does have questions, please feel free to ask. I did not properly introduce them, but I have Robin and Tanner with me. They’re two of my trusted co workers. They are excellent. They are knowledgeable. And between the three of us, we should be able to answer questions you have. And thank you for letting me talk. I know you are with me. All right. So as I mentioned, I did want to go over some case studies. Normally in these sort of walk arounds we’ll do a direct demonstration, but with my level of access to the systems, I erred on the side of caution. If I go through any of these interfaces, I might potentially leak some information from any of our merchants, and I don’t want to do that. So I decided to go on the made for TV movie route and have some amalgam characters, which are little bits of different merchants we have running on Ă۶ąĘÓƵ commerce cloud right now. The names have been changed to protect the innocent. But I want to make sure that you can see some of our highs, some of our lows, and some of our in betweens and maybe get some inspiration for optimizations and settings you might want to run. I wanted to lead off with a good one. So my first case study is Z. Or Z if you’re outside the United States. They are running a headless PWA.

And one of the things that they did is the PWA is running entirely in JavaScript.

But not just that. That JavaScript is cached and stored entirely within the FASTA network. They are using a cacheable graph QL calls. So that’s a graph QL get with parameters attached. And what this means is that their hosting server is the entire FASTA network. They have over 102 servers just dedicated to their front end. They are one of the fastest merchants we have running on us. And the only time their origin server is ever called is when someone hits their speed is amazing. And I did not get permission to share them directly with you. But if you have lofty goals or ambitions, this might be an idea to look towards.

Now, I do want to go up and down in here. We do have kind of an under performer. Oh. Now, they are using graph QL post. That is not cacheable. That also throws in another unique complication which isn’t necessarily a FASTA complication. But it’s definitely worth calling out. Because they’re all post, nothing is unique in the logs. Which means if somebody is checking out and if somebody is on a catalog page and if somebody is conducting a denial of service attack, those three things look exactly the same from the log system. And that’s not necessarily good for them because that puts us in a position of very limited responses that we can offer to them. Furthermore, they’re using a stack CDN. As you can see from the image I kind of put up there, this means every single request is basically a Trojan horse and we don’t know whether or not we can trust it. But we can’t really do much about it other than to let that in.

The only action we can take for this merchant when they encounter, whether it’s a legitimate or illegitimate traffic search, is an upsize. The user, the organization right now that kind of O is representing is actually on right now a hosting size that is not one that we advertise as offering. And we do have merchants that do utilize caching, although not necessarily to the ideal levels that are on a quarter of the capacity that can serve twice as much traffic. So where at all possible, avoid using the REST API and avoid using GraphQL post unless it is absolutely for sensitive data because that will definitely have both performance and visibility impact on your site. Now we’ve got another good performer. I don’t want to end on a down note, although I guess the way I’ve set these up, there’s four of them, so I kind of will. They are aggressively using caching. Not to the level of our first example here, but every single page is cached. They are filtering out the campaign parameters from the URLs. So those unique links that folks are getting their emails, they’re still popping up in the URL bar. They can still be tracked via JavaScript. As far as FAS is concerned, as far as the origin is concerned, those 100 unique links are the same page. It’s not adding to the load. They’re performing all of their updates overnight. For some of the merchants that are representative of A, they’re seeing them scheduled down to 2 a.m. local time on a Wednesday just to make sure that nothing happens. Other folks are not nearly as stringent, but definitely if your peak sales are 9 to 5 or 5 to 10, make sure that your updates are scheduled to run after that so that there’s minimal impact to your site responsiveness. They are utilizing the soft purge, but because they don’t demand that immediate visibility to changes, it doesn’t affect them. They might be using soft purge for something like they’ve changed a descriptor, and it’s not critical to them that everybody sees the updated description immediately. That’s a good reason to use soft purge. Something like we’ve sold out or we’re no longer offering a product, that’s a bad reason to use soft purge. They are still using some uncacheable REST APIs in this example, but they’re using rate limiting to make sure that they’re not being abused. The most common target for abuse for the REST API is actually checking whether or not a credit card is valid. That is definitely probably the only thing that you would want to use the rate limiting for because rate limiting will disable caching on any target it’s directed at. So while they’re not necessarily the best I’ve seen on our platform, the only time the origin server is called is when people are checking out for the most part.

Oh, absolutely. I can definitely show that. So as I mentioned, this merchant is a they’re using a headless PWA and because that PWA is built entirely in JavaScript, it is cached directly on Fastly because they’re also using cacheable GraphQL. That means the calls to the servers for everything except for unique customer specific data is cached. I did a run page to page. It is they are an excellent performer. And as I mentioned, because they’re utilizing the caching so well, it doesn’t matter where their server is hosted. It will load just as fast for me in Virginia, as it will for Robin in Texas, as it will for someone else in LA, as it will for someone in Ontario, in London, in Tokyo. It will be just as fast.

And I might as well answer this as well, since this is kind of related. Yes, edge delivery service actually functions using Fastly. So provided you’re following best practices for edge delivery services, you’re going to see something very much like this. It’s not a one to one, but because edge delivery service can use Fastly as a back end, adopting those good Fastly practices will be good practices for edge delivery services. So it is directly transferable.

All right. And unfortunately, because I picked four, I did want to go over another underperformer.

They are using the rate limiter. And as I said, the rate limiter is great for targeting APIs that you believe are subject to abuse. The problem is, is if the rate limiter is not used on a very narrow scope, as I mentioned, it does disable caching. And so if you have, let’s say you’re rate limiting a product page, some folks might be running a sale and they think, oh, I want to keep people from refreshing so I don’t have a scalper. Unfortunately, you’ve disabled caching on that product page now. You’ve actually made that legitimate and illegitimate traffic more harmful to your site. There are other ways of going about it. I don’t cover them here. But there are other options for limiting traffic. And we can definitely go over that a little bit at a high level afterwards if you want to. But that’s definitely worth reaching out to us later if you do find yourself in a scenario where that occurs. The problem with this merchant as well is that they also stack their CDN. And because they were utilizing rate limiting on Fastly, but not on their other CDN, aside from the caching being turned off, Fastly is only seeing those other CDN’s IPs. What happened, and it actually happened over the course of several months before it was caught, is they would have sporadic outages because all of their legitimate and illegitimate traffic was coming out through about 10 egress IPs. And so what would happen is rather than shut the entire site out, all users that were going through one IP that might have had one malicious user effectively blocked, they would have, rather than the site blackout, they’d have a site brown out where it wasn’t completely down for everybody, but everybody who was unlucky enough to use a single egress point on their stacked CDN suddenly couldn’t access the site at all because that CDN egress point was black. Now, what we had to work with them on was kind of coaching best practices. And while we strictly don’t support that stacked CDN, we gave them some pointers and some directions on how to enable rate limiting on their outer CDN. And I spoke with my counterpart at that CDN and said, hey, this is what we’re encountering. What can you offer our merchants? And we were able to see them with some degree of success off in a better place. Things aren’t necessarily perfect with them, but this issue that I’m kind of showing here in this case study was addressed and their site now only has outages for legitimate issues and not necessarily because of kind of what was effectively a misconfiguration.

So as I mentioned from here, there’s plenty of places you can go. We’ve got, I’ve got a place, three QR codes here if y’all want to scan them. Basically, it’s going to tell you, it’s going to be our support docs and it’s going to be several fastly related support docs. I can even paste some of those links here into the chat as well for all of you to refer to. So we’ve got a good set of resources on some very basic examples on our dev docs. It’s mostly going to cover things that are commerce specific, but your commerce site might have some unique behaviors that we don’t necessarily cover. I’ve got a few examples on that as well that I’ll share in the chat room as well.

Now, the fastly developer documentation, if you are a developer for a site on commerce cloud, or let’s say you’re not on commerce cloud, but you are utilizing fastly, absolutely keep this stuff bookmarked. It is a fantastic resource. Almost every page has an example and they even support exporting those examples to fiddle. So if you want to play around with the code, test, change, iterate, you absolutely can and you’re empowered to do so. It is definitely a resource worth having. Now, if you do need to reach out to our support team, as I mentioned, we aren’t necessarily a code or development validation resource, but we will try our best to help you. And if we can’t necessarily help you directly, we’ll try to find the resource on our development documentation or in fastly developer documentation to kind of give you a step forward. Now, if you need more direct hands-on assistance, we do have a consulting team at Ă۶ąĘÓƵ and they can help you with more hands-on implementation. I don’t want to speak for them or speak to them, but they are a great team to work with. And usually for those cases where you need something that is just outside of what our support team can help you with, that is a perfect reason to reach out to your accounts team for that engagement. Now, hopefully I can give you some inspiration on some places to go further if those case studies didn’t give you as much. The first thing is you may want to consider using synthetic responses. Right now the most common use for that on Ă۶ąĘÓƵ Commerce Cloud is, and I don’t like the term vanity error pages, but it’s the point of having your error pages native site rather than looking like a generic, but you can do so much more with it.

I have an example and I will paste it in here. For anyone who has used Apple Pay verification on Ă۶ąĘÓƵ Commerce Cloud, a lot of folks, that’s a pain in the butt because they have to upload something to their project and that either requires committing it to Git, which is not great from a safety practice, or it requires committing it to a writable location and then remapping it in fastly. I have an example here on how to use a synthetic page so when you need to update your Apple Pay verification, you do it directly in fastly. Your server doesn’t get touched. You don’t need to do a redeploy. You don’t need to give someone access to FTP. You can just update it. Now, one of the other things I have seen some merchants do is they have taken their landing page for a sales campaign and pushed that as a synthetic response. What that means is someone comes in for a sale, you’re selling a product or a family of products and that first page never reached your server. It was served directly from fastly. Now, there’s some trade-offs for that. The unique information such as the login status, the cart status, that’s not going to be there, but you are going to see zero overhead for people that might just be clicking it or might have something in their email client that’s loading it in the background for a preview. So you’re going to see a significant drop in overhead.

Now, the other thing I mentioned a couple of times here is that soft purge. As I mentioned, that is a trade-off and it’s worth thinking for the needs of your site whether or not that’s the best approach. There are a lot of proponents for it. There are a lot that are not necessarily for that. In my mindset, it’s best to see that as a trade-off and to determine what’s best for your needs at that time. Does my site need to always be fast for every request or do I need to make sure when I’m pushing an update that that update is visible as quickly as possible? If speed is your main objective, soft purge is for you. If accuracy is your main concern, maybe don’t consider it. You can manually soft purge some objects by the API and that might be good for those cases where something just had a typo and you want to update the typo but you don’t want to evacuate the cache entirely. The other thing to consider is the vary header.

It’s fallen in a little bit of disuse this days with a lot of responsive websites and PWAs, but if you’re still using a mobile unique theme or maybe you’re using an application such as I’ve seen one merchant use an Android web view and they want to have a unique view for their website for that Android web view, that would be a good case to use the vary header. There is actually a resource in Fastly’s module for that. I believe it’s called use the mobile theme module, mobile theme support. That kind of automates most of the coding for you. One bit of a caveat I will attach to this is while a self-hosted Redis instance may have an unlimited number or a very high number of vary states, Fastly really only supports two. So more conditions you add to that vary header, the less reliable your cache will be. So do keep that in mind. I do see some more questions coming in. So I will try to address that in a moment.

How about now? So if it’s all right with you and if this is private at all, please feel free to in your question. I won’t read aloud. But Tyler asks, you’re running Magento on Fastly on Ă۶ąĘÓƵ Cloud. You’ve been updating your categories and product pages and you’ve noticed that categories and product pages have been caching for 24 hours or plus. You do have soft purge, purge category, purge product, purge static benefits and enable the edge modules.

So this is kind of going to be a case by case basis. There’s certainly more to discuss than just the current settings you have. And certainly there’s more factors to speed than simply delivery from Fastly. Some of the larger speed hurdles aren’t necessarily delivery of the page itself. It may be the contents of the page if you have very large or complicated JavaScript, the browser itself may have to stall during rendering. If you are looking for some guidance, I may suggest that you are, you did say that you are on a commerce cloud, open up a case with us. We can definitely give you a review. If not, I would also say maybe look at the swap tool. It’s not necessarily Fastly specific, but it does look for a lot of very common speed and performance related issues. And if you do see that you just are having some hurdles you can’t quite reach, check out Swat. See if it’s noticing that maybe there’s some potential bottlenecks in your products that are impacting the page generation speed, which would then make it slower to prime that cache. If you are seeing that the cache is evicting more frequently than you want to, maybe you have a background cron or maybe you have a module that is kind of clearing that cache out of turn. Certainly if you submit a case to us, we can definitely help you look for that.

And even if we can’t necessarily find it directly or even if we find an issue with a non-covered component, we’ll certainly try to give you the best foot forward into addressing that issue.

Does anyone else have any questions you want to ask? Feel free to chat them out. If it’s private and you want a private response, we can certainly do that. If it’s public and you don’t mind me reading it out, I’m more than happy to do that as well. Just let me know.

And if you need me to go over anything again because I tend to talk fast, I can do that as well.

Yes, I can definitely let me go back to the QR codes.

Okay, Saif. Now if you need to reach Fastly, you don’t have the ability to directly reach out to them, but you can reach out to us and our support and we can, if there is a Fastly issue that does require that team directly, we can reach out to them on your behalf and open that discussion for you.

Okay, the bot attack. Were you talking about the case study or the Stack CDN? Okay, well I can go over those one more time. Yeah, so the bot attack, they would sort it too. So let’s go. So this would be the…

So these are the Stack CDN complications and bot attacks are really the biggest problem with this complication is because it obscures our visibility, because it kind of breaks the logs and because we can’t block the traffic, that’s the biggest bot-related hurdle.

Now for the case study related issue, I’ll give you just a moment. I believe this was probably the one you’re talking about, kind of our underperformer, but there was another one that was sort of attack related and this was just showing that because they were using both an uncacheable GraphQL call and the Stack CDN, every single request that was coming in and was logged was identical, whether it was a checkout or someone loading a product page or somebody trying an injection attack from the visibility of the logs, we couldn’t differentiate it and it kind of unfortunately put us in a situation where all we could do is offer more resources to this customer and ask that they reach out to their outer CDN partner because they would be best equipped to help first off validate and detect the attack but also to block it.

All right, well if anybody has any other questions, I’m fine staying a little bit longer, but if we don’t, as mentioned, there is going to be a recording of this sent out within about 24 hours, I believe, and if you think of questions later, our support team is here, so we’re more than happy to ask questions you have. We do have a very good level of documentation on the subject and certainly if you want to refer to the FASTA documentation as well, it is incredibly helpful.

I’ll be honest, I personally refer to it every day and I’m not just saying that to to sound fancy. It is absolutely indispensable to keep if you are running in the Ă۶ąĘÓƵ Commerce Cloud website or even if you’re running any website that does make use of the FASTA network to have access to these resources bookmarked because it’ll give you some great direction on where to move to not only optimize your site delivery but also if you do need to make unique customizations or change. Yes, actually, yes, I will do that for you right now.

I did mention I was going to put that, so these should be what are covered in here. I’m going to paste the first one here. Actually, no, let me see if I can paste all of them.

I apologize, I pasted that to the wrong thing.

Let me see.

I apologize.

Okay, this should have some good resources. This is actually covering all of those. It doesn’t cover Fiddle, but I did mention that was also indispensable, so give me one moment. I will give you the link for Fiddle as well. It is fiddle.fastly.dev.

Now, I did mention I would also like to share a couple of examples. Hopefully, you don’t mind that I’m going to tack this on as well. So these are some things that may be worth putting into consideration as well. These are some fiddles I have given to merchants in the past. Nothing specific or unique to them, but it may give you a stepping stone. I believe I’ve cited my sources on all the snippets, but just in case I haven’t, they are, most of them are going to have documentation in the Fastly DevDocs.

So as I mentioned, there’s a snippet in Fastly. You can actually clone that directly from the Fastly fiddle on how to apply Apple Pay using that synthetic response. It’s a little cheeky, but just to demonstrate that the contents of that file don’t actually need to exist.

The second thing is filtering campaign parameters. That’s also very useful. Again, if you’re sending out an email campaign, social media, whatever, if you don’t have those parameters in the URL, it won’t break your caching. And then the last but not least is if all else fails. Now, the built-in blocking mechanisms allow you to block by IP, but also by CIDR notation. And if all else fails, you can actually block by ASN, basically blocked by IASP. So you might have a network that might have multiple IP ranges and you can say, well, listen, I don’t trust DigitalOcean. So I am, or I don’t trust Rackspace or I don’t trust GoDaddy. So I’m going to block all traffic from them regardless of their IP address. You can use that as well.

All right. Do we have any other questions? Anything else I can, while I’ve got you? And certainly, I’m more than happy to help. And if you have something that’s a little bit more in-depth, please absolutely feel free if you want to think about it for a moment and reach back later. Absolutely. As I mentioned, if you have something or you’re having a specific issue, question that’s unique to your site, maybe do feel free to open a case with our support team. As I said, we aren’t necessarily developers. We can’t provide complete guidance for everything, but we can definitely point you in the right direction if we can’t. Can I share my email address? You know, I… Maybe at a later time, but I’m not certain if that’s going to go out with the recording or not.

But certainly, I don’t want to appear unreachable. But I generally am not in my position at a direct engagement point.

All right. Perfect. Thank you. I think we’re good on questions. Thank you so much, David. That was great. And then also, thank you all for attending Tech Sessions. A quick reminder, again, is a link to this recording will be emailed to all of you in 24 hours and will be available on the Dovie Experience website if you’d like to view it again or share with your colleagues. Thank you all then for attending. We hope to see you guys in the next one. Thanks. Bye.