Oneboxed gfycat slower than embedded video

I noticed that the oneboxed gfycat video plays at a slower FPS than the embedded version. Compare below:

Oneboxed (achived by pasting gfycat link into post)

Embedded (achieved by copying video location from gfycat and pasting into post)

Is this intentional for the sake of network resources, or is it a bug? I notice that the direct (second) link is on instead of, so I’m not sure if maybe gfycat updated their backend and Discourse hasn’t adjusted yet.

1 Like

Looks like Gfycat is giving only the mobile version of the video on their oembed now. Will ping the Gfycat guys.


GfyCat got back to me, and this change was intended.

The alternative is to someone to step up and implement a special Onebox for GfyCat using the official library so adding #pr-welcome here.


Hello @Falco,

I see that the official gfycat.js library requires a piece of code (the library loader, a simple <script> tag from their to be included just once for all videos. Is there any way of achieving that in OneBox?

1 Like

Hey @nbianca after reading this again and taking at how the lib works I’m not sure we want to use it.

We could try to create our own logic for this Onebox, creating a video tag with both webm and mp4 sources, with the loop on and autoplay off.

What do you think @zogstrip ?


That’s indeed the way to go.


I am working on this.

EDIT: Done.


Any chance autoplay could be enabled by default for the gfycat onebox instead? Gfycat clips are essentially glorified gifs (even limited to 15 seconds), so preferably they’d behave similarly. There shouldn’t be an issue with bandwidth because webm files are substantially smaller than their gif equivelants which already autoplay (the one in the OP is 1/6th the size of the equivalent gif).


Can they contain audio? If so, then autoplay off will greatly save the ears of many.


Gfycat clips do not contain audio. Audio is stripped from uploaded files that do contain it.


Found a tweet confirming that too (from 2014, but browsing the site, it seems legit still).


We definitely want the tag loop in there, and about autoplay I did some research.

I went on some Gaming and Anime Discourses, and I believe they want to keep the current behavior, wrt, autoplay and loop ON.

Looking trough this Chrome Blog I believe that if we use:

<video controls loop autoplay muted>

we get the better of all worlds, consistent behavior and bandwidth savings.


Hello @Falco ,

I made the changes. Probably, the most bandwidth savings would be made if we used the low quality source. However, there is no way we can actually switch between sources and I am not sure if the browser can do that by itself (taking into consideration bandwidth, if on desktop or mobile, etc.)

Anyway, it is ready for merge.


Doesn’t help for video, unfortunately, but there is an emerging multiple image format for supporting retina devices and non-retina devices, etc:

I do want us to start doing srcset natively in the future for images!


I just updated the gfycat onebox, to be more inline with what we have.

We now support:

  • Support both$id and$id URLs
  • Favicon
  • Title
  • Author
  • Tags
  • Autoplay
    • Desktop: Only if smaller than 10MB
    • Mobile: Only if smaller than 10MB and when the gfy is in the user viewport

Using this documentation here (we recently published it on our docs) will make all shared Gfycats faster regardless of browser. There is logic in there that detects factors like browser, OS, network speed, etc. and we also provide users the option to toggle between high quality and lower resolution. Gfycat Iframe Documentation

1 Like

I like what you did showing who made the Gfycat and showing the title and tags. Thanks Rafael!