Therefore, all of our iframed content is treated as its own site with no benefit to the parent page / domain. Therefore we are not altogether sure that our core content does much besides giving a viable experience to users who have JS turned off, or those whose machines fail to cut the mustard for our enhanced experience.
However, search engines have improved so that they now both index pages and also execute javascript(JS).This means that Google now fires our JS which in turn hides/deletes the core content from the parent page and loads the iframe in its place. This means that we embed the nub of the interactive piece as flat HTML that screen readers, older browsers and search engines can access. We deal with this by having core content accessible to the search engines. It is generally a bad thing for us that content produced by the BBC is not considered part of the bbc.co.uk page it is embedded on: we would like any BBC authored content to be searchable regardless of where it originates. Even though our bbc.co.uk page visually includes content from that domain and it is our own content, in the eyes of a search engine spider it doesn’t “belong to” bbc.co.uk. When an iframe requested by a bbc.co.uk page is served from .uk it is not considered “part of” bbc.co.uk by a search engine.
We serve Visual Journalism content(along with much of the BBC’s static content) on a separate cookieless domain through a CDN: .uk. Iframed content is dealt with, quite rightly, as a separate domain and indexed accordingly. Shadow DOM has no such requirement as it’s ‘native’ to the page. Iframes require a ‘title’, otherwise screen readers announce them simply as ‘iframe’. Iframes are hard to write for: CORS errors are common, as iframes are locked down and things like hooking into scroll events need to be ‘normalised’ before forwarding to the iframe, to take into account the iframe offset. This comes with library bloat andcomputationaloverhead. Iframes are inherently unresponsive, so we have to set up a postMessage-driven mechanism of manually keeping the height up to date.
Consequently, the iframe initialisation is much slower than the shadow DOM, where all of the requests are already ‘in the page’, so to speak: The Shadow DOM is one of the four Web Component standards that can deliver content in a similar way to iframes in terms of encapsulation, but without the negative overheads.
#Alternative to iframe download#
With iframes, the iframe itself is a separate document - so the page has to download and render the iframe document, which itself requests assets such as JavaScript and CSS. Each of these messages takes time and when we are trying to increase front end performance, eliminating these messages would be a big boost. When we set up an iframe, we need to send messages from the iframe to the parent/host page to communicate events backwards and forwards: if the user resizes their window, we need the parent to tell the iframe if the iframe changes its dimensions by loading in extra content, the iframe needs to inform the parent if a user clicks a button, we need to inform the parent so we can track this data to measure our project efficiency etc. However, there were many drawbacks to using iframes as the de facto method of distributing our content to the different internal endpoints. Photo by Matthew Henry on Unsplash The downsides of iframes Third parties can ingest our content without us losing control. Syndication is also easier with our iframes.
So sandboxing our content has made sense for the longest time - it protects our content from changes beyond our control.Īnd, reciprocally, it protects the rest of the BBC from our changes, so we can’t bring down the article pages if we do something a little careless. When another department makes changes to something on the front end(CSS,HTML or JS) we cannot risk it breaking all of our old content. Each of our projects is bespoke and compiled on multiple different endpoints for multiple use cases. The content that the Visual Journalism department produces is added to pages that we don’t control, pages that are built by a scale enterprise CMS and publishing system and maintained by other teams. But why were we using iframes in the first place, why didn’t we just use Web Components, and what lessons can I impart to you, dear reader? It took us six months from concept to production but the results make it worthwhile: our products load more than 25% faster and feel more interactive. Recently we, in the BBC’s Visual Journalism department, have made the switch from iframes to Shadow Dom. Or: How I learnt to Stop Worrying and Love the Shadow Dom
0 kommentar(er)
