For the part year, I have been working for playbuzz. the company develops a platform that helps publishers and bloggers create more engaging content.
Once our users create their own stories using the creator they can embed them into their sites using a classic iframe. This is the most common way to embed items into web pages, and it has been used on many sites for more than 20 years.
Let's first review how we would use plain old iframe:
<script src="//cdn.playbuzz.com/sdk.js"></script>
<div class="pb_feed"
data-item="xxx-xxx-xxx">
</div>When the sdk.js script run - it builds an iframe on the host page and refer its src attribute to the relevant item on the playbuzz servers.
//host page
<html>
<head>...</head>
<body>
...
<div class="pb_feed" data-item="xxx-xxx-xxx">
<iframe src="//www.playbuz.com/item/xxx-xxx-xxx">
//iframe content from playbuzz servers
<html>
<head>...</head>
<body>...</body>
</html>
</iframe>
</div>
...
</body>
</html>In this way playbuzz controls the entire iframe page. The host side does not care how we handle it, and there is a separation between the host and the iframe page.
While this method works well for many years on many sites (youtube still uses it for example), it had many flaws:
- The communication between
iframeand the host (post-messages) is very slow. iframeassets are prioritized very low on the browser queue - the browser will allocate resources to theiframepage only after the host page, slowing theiframepage render.iframeis not responsive - every time the host page changes its layout (user switch from portrait to landscape mode for example) thesdk.jsshould be anonunced about it somehow, to change theiframelayout as well.- It is hard to optimise the SEO - google will index the page as a
playbuzzpage, while our partners would like it to be index under their own domain.
Now that we are familiar with the iframe solution, let's review how we do it in Playbuzz, using friendly iframes.
A friendly iframe is an alternative way to embed webpages into host sites. Basically, friendly iframe is an iframe that shares the same domain as the main page that hosts it (an iframe without src).
We use the same code snippet as before, but this time we build an iframe without src attribute, and then inject our item page (head and body) content into this iframe. This way we get the same result, but now without any reference to playbuzz servers on the host site.
//host page
<html>
<head>...</head>
<body>
...
<div class="pb_feed" data-item="xxx-xxx-xxx">
<iframe>
//iframe page content is part of the host page
<html>
<head>...</head>
<body>...</body>
</html>
</iframe>
</div>
...
</body>
</html>- Now our content is just another part of the host page DOM, our page will be rendered faster
- SEO is now as our partners want it to be - google index the page under their host domain.
- The parent-child communication is easier - we don't need the slow
post-messageanymore, we can usewindow.parentto call the host (we could not access the parent when our page was in a different domain). - Our resources get the same priority as those of the host page when the browser allocates resources to render assets
- Cookies and localstorage are now shared with the parent, so we can't use
playbuzzown cookie cross sites (we use xdomain library to solve this issue) - CORS - we need to configure our servers to handle calls from multiple domains instead of
playbuzzdomain only - It's harder to develop
freindly iframethen regulariframe- we need to take care of the content injection, cookies issue, and configure CORS on our servers - It's can be hard to convince host sites to break the isolation that regular
iframeholds
While classic iframe is much easier to implement and can fit many cases, there are some situations, e.g., when the SEO is important, or when you need to use parent-child communication many times, when it is better to use friendly iframe.
Anyway - I think you should definitely be aware of these two options, and the difference between them, so you could decide which is better for your case.