you can save cpu cycles and bandwidth by not rendering full pages when you only need to render a link preview
this would alleviate the “fedi DDoS problem”
an Accept: application/opengraph+html; */* would prefer opengraph metadata and avoid rendering the full HTML unless the server lacks support for content negotiation, which is fully backwards-compatible but makes it so much easier for websites to implement either lightweight opengraph rendering or reject link previews altogether
we don’t know if this should be a FEP but we’d love to know what y’all think
I’ve thought before that there should be a way to request only the <head> of an HTML document, similar to an HTTP HEAD request. But this is something that needs broad standardization to be useful…
opengraph itself doesn’t have broad standardization…
you’d be surprised how much you can do with very little, if you focus on your strengths. maybe we can get the small web to enforce these? (i.e. only emit opengraph metadata if the request calls for it…)
I guess it could make sense as a progressive enhancement type of thing, basically relying on the default fallback behavior of the Accept header. The idea would (should) be you make one HTTP request and then get back either an optimized response or otherwise the standard response that you have to parse yourself.
With that in mind, I wonder what would be the best thing to request and the best way to request it. As stated before I think the HTML head makes a bit more sense than specifying only OpenGraph. Also I am unsure of the correct semantics of something like text/head+html vs application/head+html, or if it should be something else entirely – text/html;headonly=true maybe? I think I need to read up more on how MIME types work exactly…
it should absolutely be application/, the only reason we use text/html and text/javascript and so on is because legacy reasons (and you can’t change that without breaking everything).
we don’t know why you’d want the entire head. most heads are 95% css/javascript by weight, which… well, most link preview generators don’t need or even want that. narrowing the scope would help a lot here.
Well, you might reasonably want <title>, more general <meta> tags that aren’t og: properties, and so on? Even things like <link> tags can be useful as well (rel=canonical, rel=alternate, …), and you could specify for the MIME type that styles/scripts should not be included. It would also be easier for servers to implement against static files – just parse the <head> out of the HTML file you already have, maybe filter out specific elements like <style> and <script>. Ideally you could implement this in a generic web server like nginx with some basic substitution filters and not be bound only to dynamically-generated HTML from some application backend.
Also I can’t find any info on text/html being “legacy”.
Also also: Does OEmbed try to do the same thing here? It’s not exactly the same, sure, but it does basically function as “GET some representation intended for embedded preview links”.
hmm, interesting, we can’t quite find anything to back up our claims about why we’re stuck with text/html, but we found this about the related text/javascript and we do think the same reasoning can be extended to html: RFC 9239: Updates to ECMAScript Media Types
after all, web applications are, as the name implies, applications, and they’re written in html (and css and often but not always javascript). so “application/*” should be the proper type, and you can see it in related formats e.g. application/xhtml+xml. but we’re also stuck with real-world usage.
since the goal is to reduce CPU load, we feel like shoving an entire HTML parser into static webservers might slightly defeat the purpose. as it turns out, rendering pure opengraph metadata should take less CPU than rendering a full page, so the primary advantage seems to be for dynamically-generated HTML from some application backend. if you have less work to do, you can do more of it with the same resources. (e.g. you’d be able to serve 5000 fedi instances instead of 500.)
as for oembed vs opengraph… is it common for link preview generators to support both? we’re not sure how to deal with that, honestly.
as it turns out, rendering pure opengraph metadata should take less CPU than rendering a full page, so the primary advantage seems to be for dynamically-generated HTML from some application backend. if you have less work to do, you can do more of it with the same resources. (e.g. you’d be able to serve 5000 fedi instances instead of 500.)