Can We Incorporate Video Into Websites Without Hurting Seo?

in SEO
Blog Image

Answer: Yes, but, as with every other design topic, video integration needs to consider website functionality, loading procedures and speed, and, of course, portability to mobile platforms.

To video or not to video


If you ask the designers, more often than not, they'd like to embed videos, high resolution graphics and all kinds of dynamic gizmos and whatchamacallits into your website. In particular, they'd like nothing better than using a nice video as a background for your home page. They do have a point: getting and retaining the viewer's attention is and should be the first objective of a website..


If you then go and ask the guys behind the scene--the techies, the SEO experts--they will tell you that resource-expensive stuff such as videos, and in particular those heavy full-screen video backgrounds, are evil and should be avoided at all costs. They have a two-pronged point: 1) viewer engagement is heavily dependent in the loading speed of a website, and 2) website speed is a prime factor in the way Google ranks websites. In other words, the critical factors involved with getting the viewers' attention, that the designers so covet in the first place.

According to most sources, even a slight increase in average loading time will give a viewer pause or cause him/her to quit. (1) People have always been rather fond of their own time, and unwilling to waste it on idle waiting, and now the "faster is better" camp has been further boosted by the dominance of mobile devices. In a data-conscious world, waiting not only means boredom but also a waste of money.

Loading delay means bounces


Let us be frank: what's wrong with video backgrounds is not the technology per se. The problem is the poor implementation employed in the vast majority of the cases. 

Video backgrounds are not worse than other graphic or layout elements, but they can be a concern, since they have a healthy potential for disaster than images rarely have. When poorly deployed, they can drag your site loading speed to a halt, interfere with interactive elements and slow down your browser due to their expansive use of CPU and GPU processing resources.


In spite of the drawbacks of video backgrounds, a lush graphic presentation can be vital for many industries. Plainer sites, while faster loading and economic, can be damaging to their image, or make them lose ground to their competitors. In many cases a video background can make the difference from the point of view of appeal and can also convey the essence of the product/service or brand the website is supporting in a clearer, more direct way than simple text and images ever could.


Yes. Developers have a toolbox with a number of ways to reach a compromise. While not the fastest loading website ever, your website can still load at decent speeds and provide a fully entertaining experience. Let us take a look at those tools.


Before you even dream about that lush full screen video hypnotizing your viewers, all the basics for a fast-loading website have to be in place. You need to ensure there are not other parts of your setup jamming sticks in your wheels. .

That means a lean stylesheet, a fast and reliable server (why not a CDN? - more below), "lazy loading" scripts (loading scripts that aren't needed for the initial screen after everything else has loaded) and properly sized and minified images/videos, among other things. .

Google itself makes available a great tool to understand where the speed bumps are. (2)


One thing most people don't always keep in mind is that the first screen-full of a website can earn you a lot of extra time. The viewer's impatience can be assuaged if you give them a quick first view of the page, and soon after interactive functionality for that first screen. At that point you can proceed to load everything else--mind you, that does not mean you can spend eons loading your page, or that you can reshuffle things around after you finish yet another stage of loading. (3)

Instead, you can pin the site architecture in place from the get go, using stand-ins for the elements you plan to introduce later. And foremost among those elements are videos. Videos should never-ever be loaded with the first paint. .

By now you can probably guess how this part of the puzzle works: we use a static image in lieu of the video while the page is loading, and program it to start playing once the main stuff is in place. If you use the initial screen of the video as the source for your image, the process can be seamless.


At the risk of repeating myself, I am going to repeat myself: even after the first screen is in place, you want the rest of the page to load fast. A big part of that can be accomplished by reducing the size and weight of images and videos. Here is the rule: use only what you need. You do not need a 5000 pixels video - ever. Reduce it to the most optimal size for your needs. Same goes for images. (4)

Remember: oversized pictures suck.

If that is a bit too technical, here is another explanation: not only oversized pictures and videos strain your network by sending and receiving unnecessary data, but the receiving computer needs to do a lot of processing in order to resize them. Most important of all, the loss in quality is much greater when the browser does the shrinking, than when a good editing program does it! .

An important consideration is of course the video itself: choosing--or creating--the right video and configuring it for best performance can make all the difference in the world. 

You may want your brief (and hopefully light) video banner to auto-play, but you sure don't want your informational videos further below to start playing on page loading. As a matter of fact, you do not want your on-page videos to load until they are requested. As mentioned above, a clickable screen capture or image of the video can be used instead of the video itself, and the user can decide if and/or when to press play. .

Other considerations may include whether to loop or not the video so it plays over and over again (I say nay!). 

Practical and design aspects are sometimes intertwined: for instance not using sound with video backgrounds gives you the double whammy of a lighter video and a client that stays in your website. Nobody likes background noises in their background. If your video needs sound, it should be a foreground video. .

And last, but not least: never ever use video backgrounds in the mobile versions of your website. The load impact is too costly and the impact of its immersive effect is lost in small screen sizes.


Much of the speed of a page depends on the server. Usual stumbling blocks are the response time of the server, its processing speed and memory, and its throughput. 

Although its influence on the speed of your website is not as important as the other factors cited above, if your business is local in nature you may also want to consider the geographical placement of the server. All things considered the closer the server is to the viewer the faster will be each exchange of information. You can verify this by testing your own connection speed to different places at any speed-testing server. (5)

But no matter how fast your server, chances are as far as video is concerned it cannot compete with the cloud. 

Cloud-hosting videos is easy to implement and does not involve a great expenditure. If you are willing to put your video "out there" the best solution is using popular video broadcasting sites such as YouTube or Vimeo. Not only they are free, but if properly optimized they add a secondary source of links and another platform for your products. .

If you are concerned with video ownership issues and you don't want it in the public domain, there are plenty of Content Delivery Networks (CDN) out there that will do the work at a very reasonable rate--or even free! (6)


To wrap it up, as is the case with every other element of design, use video as needed, no more and no less.

Just make sure you use it properly, which means the following:

  • Choose the proper video for your purposes. Put some thought into its configuration, according to its function and placement.
  • Use it within a page that is properly optimized for speed,
  • Load it after the core of the site is loaded and functional
  • Serve it lean and size it so that it doesn't exceed its intended usage, and
  • Stream it from a fast server, preferably a cloud-based content distributor.

Simple enough, no?


(1) From https://web.dev/why-speed-matters/:
"every 100ms decrease in homepage load speed worked out to a 1.11% increase in session-based conversion" and "the BBC found they lost an additional 10% of users for every additional second their site took to load."

From https://www.thinkwithgoogle.com/marketing-resources/data-measurement/mobile-page-speed-new-industry-benchmarks/:
"As page load time goes from one second to 10 seconds, the probability of a mobile site visitor bouncing increases 123%. Similarly, as the number of elements-text, titles, images-on a page goes from 400 to 6,000, the probability of conversion drops 95%."

(2) https://developers.google.com/speed/pagespeed/insights/

(3) This is called Cumulative Layout Shift (CLS), and Google doesn't like it one bit. You have probably seen the sites, usually click-bait: they load a few items and then, just when you are going to click on a link, or while you are trying to read the content, enjoy a picture or interact in any other way with the page, they start moving the furniture around. The link, the image, or the text - they suddenly move down a few lines because now in between it and the header there is a new ad, or a video that wasn't there before.
And I am willing to bet you did not enjoy the experience a single bit.

(4) https://www.foregroundweb.com/image-size/

(5) https://www.speedtest.net/, for instance.

6) The most famous of them is probably Cloudflare: https://www.cloudflare.com/cdn/



First Contentful Paint: is the stage at which the viewer first sees something of your web page.
First Meaningful Paint: marks the point at which the first piece of content can be understood by the viewer.
Time to Interactive: is the level at which the website is fully interactive and ready to use.


Largest Contentful Paint (LCP): measures loading performance.
First Input Delay (FID): measures interactivity.
Cumulative Layout Shift (CLS): measures visual stability.

© Copyright 2024 – Cityline Websites | Terms | Privacy Policy | Site Map