The adoption of performing edge SEO (through applications such as Sloth, Spark, and LogFlare) has risen in the past year.
More businesses are also able to use existing technologies such as Cloudflare Workers and Distilled ODN to get around platform restrictions and congested development queues.
Cloudflare has helped start the discussions in marketing departments around the world and helped early adopters advance their SEO campaigns. But the next phase of adoption will be spurred on by two key elements:
For the most part, the implementation possibilities through “edge SEO” are almost limitless. Use cases include:
Other use cases can be:
Akamai Edge Workers are set for beta in October.
Fastly, from what we can tell, are working on a solution using WASM.
Enabling lazy-loading can be useful in achieving faster page load times, and therefore better performance for users and within organic search results.
Given that a lot of websites could benefit from the new Chrome 76 functionality, but may struggle to expedite implementation through traditional development methods as quickly as they would like, edge SEO offers an alternative implementation method.
Simon Cox has documented this process, using Cloudflare Workers and Spark via his blog.
While the solution may not be “best practice”, it can provide a valuable stop-gap before “correct” implementation.
For smaller websites and businesses, it can provide the end solution where the development costs may be prohibitive versus the relatively low costs of Cloudflare Workers.
This led to Google releasing a series of articles and videos to help SEO pros get to grips with the technology, with dynamic rendering being an important recommendation.
The costs of prerendering/dynamic rendering can vary depending on the chosen provider, as well as the number of pages your website has, and how often you want/need the cache to be refreshed.
Using workers, it’s possible to reduce the number of cached page requests and costs in using a third-party rendering integrator. This is done by setting up a worker to follow the below process:
There is a secondary function to this and that is what happens in the “fallback” if no cached version of the page exists in storage.
This can happen either through a page being brand new and not yet being cached by the worker, or the page not being included in the XML sitemaps or URL lists inputted into the Google Cloud Functions (GCF).
During the “fallback” phase, we can trigger pre-rendering of the page. But this then leads to further decisions to make. We can either:
Alternatively, rather than trigger pre-rendering of the page, we can return a 503 status code, and trigger the prerendering of a version for caching. From experience, this is the preferred option.
Collecting log files can sometimes be an issue due to a number of factors such as:
Using edge workers, we can collect a form of server logfile by registering and logging the request.
Through tools such as Sloth, log file collection into an Amazon S3 bucket is made simpler. It also allows for collection in tools such as LogDNA, for export and analysis in other third-party tools.
Further, this solution allows for log collection on Salesforce CommerceCloud/Demandware websites – unfortunately not for Shopify websites.
In theory, it should work. However, the relationship between Shopify and Cloudflare went “grey cloud” in early 2019. This means it’s not possible to use Cloudflare Workers for any edge SEO purpose on the platform.
The advent of Akamai Edge Workers might, however, provide an alternate route.
For the most part, CDNs such as Cloudflare, Akamai, AWS, and Fastly are in wide use.
Being able to unlock and use these additional features can be vital in implementing essential and critical fixes.
Implementing things through these methods can be:
BrightonSEO Slides: Produced by author, September 2019Spark lazy-loading image on Spark: SimonCox.comSloth.cloud Dashboard: Screenshots taken by author, September 2019