Mitigating Facebook’s “x-fb-http-engine: Liger” site hammering using Apache or nginx

Facebook is using a sort of web page prerendering mechanism in it’s in-app browser for mobile users [see disclosure here]. It is used by Facebook’s in-app browser to speed up page rendering for web link content shared on Facebook. But it can cause serious headaches, and this post should explain how to mitigate it with Apache or nginx.

Web page prerendering is not uncommon way of reducing frontend load times. Most today’s browsers support it, and some of them use it regularly (like Chrome – did you notice how first results on Google sometimes render instantly?!). Some browsers prefer “preview” instead of “prerender” [like Safari], so other browsers [like Chrome] had to accept both instructions for the same action.

We all know that Magento CPU cycles come at a price. You should test on your own whether this FB in-app feature has implications on your web server performance and expenditure.

x-fb-http-engine: Liger – this is the identifier of the engine, BUT, FB in-app does not send it every time! It is being sent only when X-Purpose is sent:

X-Purpose: preview – page prerender/prefetcher HTTP header

regular images are not loaded – FB in-app requests only for HTML page

Every owner of Facebook page(s) that regularly shares links and with more than 10K fans should test their website for this particular page requests, as it might severely impact web site performance. Please, check this article on how to precisely log and test how severe your web site is affected.

I’m affected, what now?!

Since these requests are marked with two significant HTTP headers, we’ll use them to block this type of requests. We don’t want to block ALL prerender/preview requests, only those that come from Facebook’s in-app browser engine signed as “Liger“.

Don’t forget, prerendering can be quite cool and useful, so not all prerender/preview requests should be blocked – only those that originate from “Liger” engine. Prerendering advantages will be covered in the next article so – stay tuned!

I think that way I mitigo much more the effects in the server … it would be interesting to share this postulate and to see if this motor is also affected to you and if at the same time it manages to mitigate more the effects

Hi Drazen,
the approach suggest to NEGATE the access to the request with those headers? Does this result in a user being unable to visit your site through FB app? or whenever FB in-app browser detect that someone reply with 403 try to load the page entirely from your webserver?

I stumbled upon this article searching why I have much more nginx requests than the ones i see in google analytics, so i’d like to have all my traffic correctly shown on GA… is your approach viable to do this?

Your email address will not be published. Required fields are marked *

Comment *

You may use these HTML tags and attributes: <a href="" title=""> <blockquote cite=""> <code> <del datetime=""> <em> <s> <strike> <strong>. You may use following syntax for source code: <pre><code>$current = "Inchoo";</code></pre>.