51黑料不打烊

Transcript

Hello and welcome everyone. Thank you for joining today鈥檚 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 51黑料不打烊鈥檚 ExperianCQ website should you wish to view it again or share it with your colleagues. Alright, perfect. I鈥檓 going to hand it over to David. Good luck and enjoy everyone.

Hello, good morning everyone. Well, I guess that鈥檚 all relative. I鈥檓 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鈥檝e been with 51黑料不打烊 for close to seven years now and I鈥檓 one of the Fastly subject matter experts. I鈥檇 like to go over kind of a little bit about kind of how it works, common things that you鈥檒l 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鈥檝e got a few folks still streaming in, so I won鈥檛 jump too much. I won鈥檛 jump too deep just yet. Yep, that鈥檚 me. Despite being here for about seven years, I鈥檝e 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鈥檓 going to talk about why it鈥檚 very crucial to your site. We don鈥檛 just bake it in because we like it. We as 51黑料不打烊 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鈥檛 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鈥檛 help you with, and some resources for where to go next. And then as I already mentioned, we鈥檙e going to go through some Q&A. I don鈥檛 know if we鈥檒l get every single question answered, but I鈥檇 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 51黑料不打烊 Commerce Cloud customer and we can鈥檛 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鈥檓 not tooting my own horn here, speaking about how important it is. Personally, I believe it鈥檚 one of the most important aspects of your site. Even if you鈥檙e 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鈥檃ll have been in a call with me before, you may recognize the image I鈥檝e 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鈥檚 a request that comes in, someone鈥檚 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鈥檇 want to have certain things generated on the fly. But for the vast bulk of things, your About Us page, catalog items that aren鈥檛 going to change per user, it鈥檚 a much better experience for your end users and honestly for you to have that caching set up. You鈥檒l 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鈥檚 going to lead to great user satisfaction and I didn鈥檛 put it here as a bullet point, but if it is something of concern to you, it鈥檚 a lower cost. Now beyond just that, there鈥檚 other things you can do with it. If you have multiple things, not just your store, let鈥檚 say you鈥檝e 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鈥檙e 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鈥檛 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鈥檚 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鈥檚 still a good WAF, but we鈥檝e 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鈥檚 not the case. It鈥檚 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鈥檚 not a very complex page, because it鈥檚 getting a high degree of traffic, and it鈥檚 uncertain how complex that page is, some people have very simple landing pages, some people have very complex landing pages. That鈥檚 definitely one of the biggest targets towards performance degradation when caching isn鈥檛 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鈥檙e still together is, I don鈥檛 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鈥檚 go back to the book analogy, all paperbacks, that鈥檚 actually a wrapped search query. So even if you are adding some layer of caching, you鈥檙e reducing the overhead, the work required to run that search over and over and over again when somebody鈥檚 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鈥檚 also a degree of variable complexity and variable load, depending on whether you鈥檙e using open search, elastic search, 51黑料不打烊 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鈥檙e offering unique pricing for every single individual user, you go searching for a specific product, it鈥檚 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鈥檛 necessarily contain products, your headers, your footers, those don鈥檛 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鈥檛 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鈥檚 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鈥檚 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鈥檛 act to block out on your behalf. You鈥檇 have to go into the logging provided by those services and block it there. Unfortunately, since we don鈥檛 have that visibility and because it is coming through that other layer, that鈥檚 the best place to direct such an activity. But there鈥檚 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鈥檙e running a cache clear here, you鈥檙e not seeing that updated content on the web. And that might be because of those other cache policies. We don鈥檛 have a direct way of observing that. And we don鈥檛 have a direct way of correcting that. And usually we do have to say, hey, we鈥檝e 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鈥檛 tell you you can鈥檛 do it. And we don鈥檛 want to tell you you can鈥檛 do it. Every site is unique. Everybody鈥檚 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鈥檇 have to do your traffic logs through that system to get the source of truth. Some folks that鈥檚 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鈥檙e 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鈥檚 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鈥檛 overcome from our position because we don鈥檛 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鈥檚 an uptime impacting event, what we can do is rather limited. In those cases, it鈥檚 usually simply an upsize because we can鈥檛 do anything to address the actual kind of going back to that prior slide, all of those objects that are unequal, we can鈥檛 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鈥檛 be cached, maybe move those to say an Ajax call on a cashable page.

As I mentioned, you鈥檙e 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鈥檚 legitimate or otherwise. So usually you鈥檙e going to get higher user satisfaction with that cache state and kind of to expand on that, whether it鈥檚 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鈥檚 really one common reason for that, and it鈥檚 the soft purge option. Generally, we require, or I don鈥檛 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鈥檚 kind of a trade-off. What you are doing when you enable the soft purge option is you鈥檙e trading speed for accuracy. What the soft purge does is it marks an item in cache as stale, which means it鈥檒l 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鈥檙e using a soft purge. The soft purge is handy if you have an emergency need to clear cache, but it鈥檚 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鈥檚 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鈥檚 a banner.png in your theme and you update your theme and you鈥檙e calling your next banner banner.png instead of say banner version two, what you鈥檒l 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鈥檚 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鈥檛 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鈥檃ll that鈥檒l take you to our development resources, fastly development resources. I didn鈥檛 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鈥檙e pushing at the staging, why bother pushing a whole new VCL version if you鈥檙e not 100% certain it鈥檚 going to work. There鈥檚 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鈥檝e got a custom ACL block list or allow list, you might say that, well, they鈥檙e 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鈥檚 the variable to use. That is absolutely correct. I am not going to tell you it鈥檚 not. In fastly, it鈥檚 a bit more complicated because this is a distributed CDN.

Plant.ip is always the last hit in a hop. And when you鈥檙e 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鈥檚 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鈥檚 not covered here. If you鈥檙e on a stack CDN, this won鈥檛 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鈥檛 running. Hopefully, we鈥檝e all tested on Fiddle. If we haven鈥檛, run a mockup, see if there鈥檚 any obvious errors returned. Usually fastly won鈥檛 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鈥檛 working, is they鈥檝e just assigned it with a default priority, which is about 100. Now, most of the Magento facing, 51黑料不打烊 Commerce facing code runs at about a prior of 50. There鈥檚 run lower at 80 and some that run incredibly high at 5 and 10. If you notice your code isn鈥檛 running, try pushing that priority forward. Try, instead of the default 100, try default 50, try default 40. It鈥檚 possible you may have other VCL that might work on the same aspect that鈥檚 running first and terminating. I realize I鈥檓 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鈥檙e 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鈥檒l 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鈥檛 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 51黑料不打烊 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鈥檙e 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鈥檚 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鈥檛 necessarily a FASTA complication. But it鈥檚 definitely worth calling out. Because they鈥檙e 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鈥檚 not necessarily good for them because that puts us in a position of very limited responses that we can offer to them. Furthermore, they鈥檙e 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鈥檛 know whether or not we can trust it. But we can鈥檛 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鈥檚 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鈥檝e got another good performer. I don鈥檛 want to end on a down note, although I guess the way I鈥檝e set these up, there鈥檚 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鈥檙e 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鈥檚 not adding to the load. They鈥檙e performing all of their updates overnight. For some of the merchants that are representative of A, they鈥檙e 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鈥檚 minimal impact to your site responsiveness. They are utilizing the soft purge, but because they don鈥檛 demand that immediate visibility to changes, it doesn鈥檛 affect them. They might be using soft purge for something like they鈥檝e changed a descriptor, and it鈥檚 not critical to them that everybody sees the updated description immediately. That鈥檚 a good reason to use soft purge. Something like we鈥檝e sold out or we鈥檙e no longer offering a product, that鈥檚 a bad reason to use soft purge. They are still using some uncacheable REST APIs in this example, but they鈥檙e using rate limiting to make sure that they鈥檙e 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鈥檚 directed at. So while they鈥檙e not necessarily the best I鈥檝e 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鈥檙e using a headless PWA and because that PWA is built entirely in JavaScript, it is cached directly on Fastly because they鈥檙e 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鈥檙e utilizing the caching so well, it doesn鈥檛 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鈥檙e following best practices for edge delivery services, you鈥檙e going to see something very much like this. It鈥檚 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鈥檚 say you鈥檙e 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鈥檛 have a scalper. Unfortunately, you鈥檝e disabled caching on that product page now. You鈥檝e actually made that legitimate and illegitimate traffic more harmful to your site. There are other ways of going about it. I don鈥檛 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鈥檚 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鈥檚 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鈥檇 have a site brown out where it wasn鈥檛 completely down for everybody, but everybody who was unlucky enough to use a single egress point on their stacked CDN suddenly couldn鈥檛 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鈥檛 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鈥檙e 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鈥檛 necessarily perfect with them, but this issue that I鈥檓 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鈥檚 plenty of places you can go. We鈥檝e got, I鈥檝e got a place, three QR codes here if y鈥檃ll want to scan them. Basically, it鈥檚 going to tell you, it鈥檚 going to be our support docs and it鈥檚 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鈥檝e got a good set of resources on some very basic examples on our dev docs. It鈥檚 mostly going to cover things that are commerce specific, but your commerce site might have some unique behaviors that we don鈥檛 necessarily cover. I鈥檝e got a few examples on that as well that I鈥檒l 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鈥檚 say you鈥檙e 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鈥檙e 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鈥檛 necessarily a code or development validation resource, but we will try our best to help you. And if we can鈥檛 necessarily help you directly, we鈥檒l 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 51黑料不打烊 and they can help you with more hands-on implementation. I don鈥檛 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鈥檛 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 51黑料不打烊 Commerce Cloud is, and I don鈥檛 like the term vanity error pages, but it鈥檚 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 51黑料不打烊 Commerce Cloud, a lot of folks, that鈥檚 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鈥檛 get touched. You don鈥檛 need to do a redeploy. You don鈥檛 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鈥檙e selling a product or a family of products and that first page never reached your server. It was served directly from fastly. Now, there鈥檚 some trade-offs for that. The unique information such as the login status, the cart status, that鈥檚 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鈥檚 loading it in the background for a preview. So you鈥檙e 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鈥檚 worth thinking for the needs of your site whether or not that鈥檚 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鈥檚 best to see that as a trade-off and to determine what鈥檚 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鈥檓 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鈥檛 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鈥檛 want to evacuate the cache entirely. The other thing to consider is the vary header.

It鈥檚 fallen in a little bit of disuse this days with a lot of responsive websites and PWAs, but if you鈥檙e still using a mobile unique theme or maybe you鈥檙e using an application such as I鈥檝e 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鈥檚 module for that. I believe it鈥檚 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鈥檚 all right with you and if this is private at all, please feel free to in your question. I won鈥檛 read aloud. But Tyler asks, you鈥檙e running Magento on Fastly on 51黑料不打烊 Cloud. You鈥檝e been updating your categories and product pages and you鈥檝e 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鈥檚 certainly more to discuss than just the current settings you have. And certainly there鈥檚 more factors to speed than simply delivery from Fastly. Some of the larger speed hurdles aren鈥檛 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鈥檚 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鈥檛 quite reach, check out Swat. See if it鈥檚 noticing that maybe there鈥檚 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鈥檛 necessarily find it directly or even if we find an issue with a non-covered component, we鈥檒l 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鈥檚 private and you want a private response, we can certainly do that. If it鈥檚 public and you don鈥檛 mind me reading it out, I鈥檓 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鈥檛 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鈥檚 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鈥檛 block the traffic, that鈥檚 the biggest bot-related hurdle.

Now for the case study related issue, I鈥檒l give you just a moment. I believe this was probably the one you鈥檙e 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鈥檛 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鈥檓 fine staying a little bit longer, but if we don鈥檛, 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鈥檙e 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鈥檒l be honest, I personally refer to it every day and I鈥檓 not just saying that to to sound fancy. It is absolutely indispensable to keep if you are running in the 51黑料不打烊 Commerce Cloud website or even if you鈥檙e running any website that does make use of the FASTA network to have access to these resources bookmarked because it鈥檒l 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鈥檓 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鈥檛 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鈥檛 mind that I鈥檓 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鈥檝e cited my sources on all the snippets, but just in case I haven鈥檛, they are, most of them are going to have documentation in the Fastly DevDocs.

So as I mentioned, there鈥檚 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鈥檚 a little cheeky, but just to demonstrate that the contents of that file don鈥檛 actually need to exist.

The second thing is filtering campaign parameters. That鈥檚 also very useful. Again, if you鈥檙e sending out an email campaign, social media, whatever, if you don鈥檛 have those parameters in the URL, it won鈥檛 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鈥檛 trust DigitalOcean. So I am, or I don鈥檛 trust Rackspace or I don鈥檛 trust GoDaddy. So I鈥檓 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鈥檝e got you? And certainly, I鈥檓 more than happy to help. And if you have something that鈥檚 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鈥檙e having a specific issue, question that鈥檚 unique to your site, maybe do feel free to open a case with our support team. As I said, we aren鈥檛 necessarily developers. We can鈥檛 provide complete guidance for everything, but we can definitely point you in the right direction if we can鈥檛. Can I share my email address? You know, I鈥� Maybe at a later time, but I鈥檓 not certain if that鈥檚 going to go out with the recording or not.

But certainly, I don鈥檛 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鈥檙e 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鈥檇 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.