Diving into Technical SEO Using Cloudflare Workers | Hacker News Reader

Diving into Technical SEO Using Cloudflare Workers

blog.cloudflare.com

116 pointsjgrahamc43 comments

Cloudflare Workers sound cool, but their pricing is, to me, all wrong. I'd like to try them out on some of my low-volume side-projects to see if I'll find them useful and like them, but $5 per month per site is more than I pay for the entire server for all the sites combined.

I don't like being that guy who asks for free stuff, but a free tier would at least mean that I get to spend an hour or two trying the feature out. Not that $5 is a prohibitive cost, but Workers haven't sounded good enough to take my credit card out for.

I wonder if there is some way to use these maliciously that makes offering a free tier undesirable. Five dollars seems like an artificial barrier. It’s basically free, but requires you to put some money down, and get your finances on record.

I agree, developers in general will adopt faster if it’s free, or if there is a reasonable trial period, but in this case I am wondering if there’s more to this.

There is a free trial period if I remember correctly.

https://blog.cloudflare.com/announcing-workers-dev/

We hear you. Head on over and reserve a subdomain, free.

Our SEO app in Cloudflare uses Workers and has a free tier. No need for the $5 bucks fee. Our main use case is monitoring for SEO problems and patching them fast in Cloudflare https://www.cloudflare.com/apps/ranksense

(shameless, but possibly helpful plug)

We have a runtime that can be used similarly to Cloud Flare workers. You can even write JS that runs on both since we both target the browser's Service Worker API.

You can run it locally, deploy it on our servers (free credit for the first $25 of usage), or if you're a little crazy you can even deploy it to your own servers: https://github.com/superfly/fly

Coming soon: https://workers.dev/

Go sign up now.

It's possible I'm missing something, but everything in this blog post seems extremely narrowly applicable.

The author points out that you should just handle redirects in the platform if you can. For hreflang tags, is there a reason besides using a legacy system that you need to inject hreflang tags outside your app/platform?

It seems that "platform" in this instance is referring to some kind of CDN. Some CDNs handle redirects well, but some don't. Cloudflare workers are on the "edge" and this is "edge SEO" (apparently). Most CDNs don't allow the types of modifications present in this blog post.

AAhhh that makes more sense! In that case, edits at the edge do make a lot of sense.

Am I right thinking, that there are no viable alterneratives to Cloudflare Workers on the market at the moment?

And if you decide to move from Cloudflare to another major CDN provider, you will have to change how your product works?

Because that's what StackOverflow and Reddit did. They are not using Cloudflare anymore.

So, does using Cloudflare Workers create a serious vendor lock-in, that makes changing a CDN provider much more costly in the future?

EDIT: I am thinking primarily about Fastly, as it's where the majority of large players move from Cloudflare. Also, about KeyCDN, which can be a much more cost-efficient alternative to the Cloudflare's Enterprise plan.

AWS Lambda@Edge should do most of the same thing, so it's not entirely locked-in.

You'd have to work really hard to share code between Lambda@Edge and ... anything else, unfortunately.

Depends on what you mean. There are several 'smart' CDN offerings out there. Amazon Cloudfront Lambda's and https://fly.io/ jump immediately to mind.

I believe you'd need to port your CDN code when moving on any of those platforms though. You might get away without re-architecting anything else.

Hi! I'm from fly.io!

You can write JavaScript that runs just fine on both fly.io and Cloud Flare workers. We both target the in browser Service Worker API. We actually have a few users that deploy the same code to us + Cloud Flare, and use our runtime for local testing + CI: https://github.com/superfly/fly

In this case it's more useful to think of Cloudflare as a compute platform than a CDN. There are many other places where you can take JavaScript you write to run on Cloudflare and get it running (Lambda, App Engine, your own server). It won't be globally distributed or as fast, but it could be made to run.

Have you checked out StackPath [https://StackPath.com] (I’m an employee)?

We have a serverless product that is very similar to Workers. Our global footprint can handle 65tbts and we also do distributed containers and VMs at the edge. We also don’t require users to use our DNS.

We tried our the EdgeEngine but saw major latency spikes. Competition is good but SP also charges for bandwidth and a higher charge per call which makes it unattractive for high-volume usage.

Really appreciate your feedback. I definitely want to hear more about the latency spikes, if you don't mind. Also happy to talk further on the price per request and bandwidth pricing logic.

Can you shoot me an email? ben.gabler (at) stackpath (dot) com

Cloudflare Workers is a functions-as-a-service platform that runs on all the nodes of their CDN platform and works in the path of every request. Lambda@Edge, Stackpath, Fly.io are 3 similar options and there are dozens of single-region FaaS vendors. Fastly is working on a WebAssembly based compute environment.

CDNs are commodity so it's really the extra features that cause companies to move. With something like Workers that allow you to build whatever functionality you want, it actually reduces reasons to move in the first place. Also CF doesnt charge for bandwidth which is a unique advantage.

There are other alternatives but not as powerful yet. We are currently working on a solution for Fastly, it's early days though :) get in touch with us at Sloth and I'll let you know when it's available.

Has anyone here used Cloudflare workers yet? I know they just launched recently. - Where you using new or existing code (coming from Lambda for example)? - How did the performance compare? - Did you run into any difficulties?

Yes, we've run billions of requests through them. They have the best performance and the lowest-latency, along with running globally instead of a single datacenter. It's just javascript so you can use npm packages and compile the final script to deploy.

Does it guarantee some sort of high availability? Like if two of your datacenters are struck by a meteor would a third one serve my audience? (same question for you workers KV)

Cloudflare is a CDN so they're designed for high-availability with over 100+ datacenters.

CDNs are designed to forward requests to a origin server and cache the results, but you can serve your site completely from Workers if you embed all the code and data into the deployed script or store content in KV.

Does have to fit in their 1MB limit though (i think)

It's the CPU time that you should really worry about mainly. But the limits are here: https://developers.cloudflare.com/workers/writing-workers/re...

I signed up for a subdomain with the https://workers.dev launch, but since then I've heard nothing from Cloudflare about when they'll actually turn it on.

If your goal is to augment an existing domain on Cloudflare (as in the post), you can actually use Workers today. Login to your Cloudflare dashboard and click the "Workers" tab.

We use them to restrict access to some static assets (beta documentation) by checking an authorization endpoint. Haven't had any problems--but we're also doing this at a very small scale.

Yes, it's a super rad product. Using it for a few things, so far:

1) Working on a project right now that provides edge-level analytics for your sites w/ a focus on privacy: more accurate than Google Analytics (JS blockers remove ~1/3 of your traffic stats) and less icky for your users. Funny this comes up, I'm putting together a list for people who are interested in beta testing, if that sounds appealing: https://xyz.us16.list-manage.com/subscribe?u=0b8a0e873d096aa...

2) Extreme caching on a Wordpress site – using Cloudflare's edge cache WP plugin[1] and the worker from the workers-example repo[2] – currently at a 97% cache hit rate across the site.

update: just double-checked the cache hit stat on Cloudflare, after writing this comment - actually have a 99.95% cache rate as of today (!)

[1] https://wordpress.org/plugins/cloudflare-page-cache/

[2] https://github.com/cloudflare/worker-examples/tree/master/ex...

> JS blockers remove ~1/3 of your traffic stats

I'd love to hear more about this – could you elaborate? Any resources you can share to back it up? Thx!

Basically anyone who uses Firefox, or anyone who has uBlock, AdBlock, uMatrix, Purify, etc. the installed is invisible to JS-based analytics. They simply never load the GOogle Analytics, NewRelic, or whatever code as part of their “tracking protection”.

In financial services, we see about 15% higher unique users per day when analyzing HTTP logs versus Google Analytics. In fact, I’ve heard but not verified that GA now applies a “correction factor” to their stats to account for this.

Thanks, just signed up for the beta test mailing list. I'm interested to give it a try on Taskade. https://taskade.com

> edge-level analytics

Another approach to this using Workers:

https://logflare.app/

Unless you go for Enterprise you can only have a single worker per site making QA and staging hell.

Their JavaScript environment/APIs are not standard and there’s no proper spec that I could find.

The debugging environment/IDE is decent for an in-browser one but we had some horrible issues with a stale version being loaded from local storage and accidentally applied to the entire site effectively bringing us down for several minutes.

On every change I also saw several error pages myself during warmup period which made me wonder how many customers were getting them.

This was all ~6 months ago though so things might have improved since then.

Performance wise we’re very happy with it though as it beats the Apache reverse proxy it replaces hands down.

They're using the Service Worker API: https://developer.mozilla.org/en-US/docs/Web/API/Service_Wor...

It's not running in a browser so they reimplemented some things but the overall API surface is the same. They also have some extra APIs for CF only features.

Debugging is a problem though, but there's another project called Cloudworker that emulates a local instance: https://blog.cloudflare.com/cloudworker-a-local-cloudflare-w...

(shameless, but possibly helpful plug)

You can run CF worker code locally, write tests, etc using our edge app runtime: https://github.com/superfly/fly

Also check out: https://www.stackpath.com/products/edgeengine/

> When we first started out, we needed to implement simple redirects, which should be easy to create on the majority of platforms but wasn’t supported in this instance.

> When the second barrier arose, we needed to inject Hreflang tags, cross-linking an old multi-lingual website on a bespoke platform build to an outdated spec. This required experiments to find an efficient way of implementing the tags without increasing latency or adding new code to the server – in a manner befitting of search engine crawling.

Is this a primary use case? When it's not practical to make the changes at the origin server?

What are the use cases when you are able to make server changes more easily?

Can you test what workers will do on a local development site somehow?

> Is this a primary use case? When it's not practical to make the changes at the origin server?

One major use-case, yes. "We'll pay big bucks for you to fix the website. But also, we can't make any changes to the website." Fine, "patch" it with Cloudflare, just one more layer on top of the un-fixable mess for the next guy to deal with (in exchange for even bigger bucks).

Ah, the joys of consulting - ability to create messes while calling them success stories.

Our use cases were on very well built websites and platforms. Just to give you an example:

- Redirects: We have several clients in the tech industry who host their docs and pages on Github pages. Github pages doesn't support 301s. This allowed us to both create 301s correctly and have a more manageable 301 platform for the non-development team.

- A/B testing through ghosting: A very large e-commerce client of ours wanted to run A/B test by ghosting (not to change URL) and slow roll out of the new platform. Through this they could chose which URL's were on the new platform and which ones on the old one and slowly rolled it all out.

In the future you will also be able to create pipelines so that there is a better management and audit process for bigger firms with security protocols around.

So, there are more benefits to this than just "When it's not practical to make the changes at the origin server". Infact if you are just "patching" then it's trouble.

Reply on news.ycombinator.com