Web Development

Dr Derek Bridge
School of Computer Science & Information Technology
University College Cork

Lecture Objectives

learn some simple techniques for improving performance in the case of external resources such as images

External Resources

Typically, images in web pages are external resources
— stored separately, in their own files.

Typically, the following are also external resources:
favicons
videos
audio files
CSS stylesheets
fonts
JavaScript programs

External Resources

Suppose a web page references several external resources (stylesheets, images, etc.).

When a client requests the web page, the server does not send all the content in one go.

The client receives the web page and then sends a separate request for each external resource.

External Resources

Suppose this web page is hosted on www.example.org


<!DOCTYPE html>
<html lang="en">
<head>
    <title>Animal News!</title>
    <link rel="stylesheet" href="styles.css" />
</head>
<body>
    <figure>
        <img src="images/logo.gif" alt="" />
    </figure>
    <main>       
        <h1>Welcome to Animal News!</h1>   
        <p>
            <img src="images/dog.jpg" alt="A dog" />
            Dog bites man. Man bites dog in return.
        </p>
        <p>
            <img src="images/cat.jpg" alt="A cat">
            Cat plays piano. Badly.
        </p>
        <p>
            <img src="http://www.other.org/images/wombat.jpg" alt="A wombat">
            Wombat doesn't play piano. Learns saxophone.
        </p>    
    </main>
</body>
</html>

Multiple Requests

A minimum of 5 additional requests:

The browser makes separate HTTP GET requests for the stylesheet and the four images, additional to fetching the web page itself.

External Resources

The example also illustrates the following ideas:

same-origin requests:: where a web page's external resources are requested from the same domain as the web page.
cross-origin requests:: where a web page's external resources are requested from a domain that differs from the web page's domain.

In the next module, we will see examples where there is a same-origin security policy, where cross-origin requests are not allowed.

Render-Blocking Resources

render-blocking resources: browsers will not display ('render') any of the web page until these external resources have arrived
non-blocking resources: browsers will start to display whatever they have, even though these resources have not yet arrived

Typically, CSS and JavaScript are render-blocking.
Images (including favicons), fonts, video and audio files are non-blocking.

Avoiding Multiple Requests

How can we avoid multiple requests in the case of images?

Instead of putting your image in a separate file, you can produce its corresponding data URI and then include this directly in your HTML or CSS.

Data URIs

There are tools for converting images to data URIs.

Example of a data URI:


data:image/jpg;base64,/9j/4AAQSkZJRgABAQEASABIAAD/4QAWRXhpZg…


<img src="photo.jpg"
     alt="…" />

becomes


<img src="data:image/jpg;base64,/9j/4AAQSk…" 
     alt="…" />

Avoiding Multiple Requests

You can use data URIs for:

foreground bitmapped images (in your HTML);
background bitmapped images (in your CSS);
favicons (in your HTML);
fonts (in your CSS); and
video and audio (in your HTML).

Avoiding Multiple Requests

The code for SVG images can also be placed directly into your HTML.
To avoid multiple requests, we can also use inline styles or embedded stylesheets instead of external ones.
Similarly, JavaScript is similar to CSS: there are three ways of associating JavaScript with your web pages.

Comparison

external resource	data URI/ embedded resource
several requests/responses	one request/ one response (but bigger)
separate caching may reduce subsequent requests	no separate caching

Minor considerations for data URIs: an extra step is needed to build a web page; images always download (inside their web page), even when disabled.

External file can be cached and then does not need to be requested again if the web page is reloaded or another web page uses the same stylesheet or logos or fonts. Embedded resources cannot benefit from this. It also makes the remaining resoucres larger, so they take longer to load. This may not matter in the case of render blocking resources (CSS, JS): you had to wait for these, whether they were external or not. But in the case of render non-blocking resources (images, fonts), you've now made them blocking because they're part of the web page.

A longer discussion of CSS. By default, an external CSS stylesheet is a render blocking resource: the browser waits for the CSS to load before diaplayng the web page. This is a good decision else you'd see a FOUT (flash of unstyled content): the browswer would display the unstyled HTML and then, when the CSS arrives, it wuld re-rendder it with the CSS, which would be somewhat jarring.

The bigger the stylesheet, the longer the wait.

You might be tempted to split a long stylesheet into smaller ones. If there are media queries, this seems like an obvious basis for the split, and then the media queries can be in the link elements, e.g. <link rel="stylesheet" href="shared.css" /> and <link rel="stylseheet" href="medium.css" media="(min-width: 48em)" />

Or should you even inline your whole stylesheet (including the media queries) using style tag.

So, that's three options: one sheet, several, embed.

One sheet: + one blocking request + more opportunity for compression + it's all there if window/orientation changes + you can cache But - you are loading stuff you probably won't use

Several sheets: This looks like a saving but no! Currently all browsers load all sheets and then use the one that applies. (E.g. my print sheet is loaded even when not used). (What some browsers such as Chrome will do is make the ones that currently don't apply into non-blocking requests. So at least user will see something as soon as the ones that do apply have arrived.) So - several requests - less compression on each individual file - loading stuff you probably won't use But + if window/orientation changes, then it's all there + you can cache

Inline: + one request but a bigger one + more compression, like with one sheet But - you can't cache for the benefit of other requests - you're loasing stuff you probably won't use - it's all there if window/orientation change So this is really only suitable for single-page sites or ones where most pages have their own CSS.

So, of these three, the first is the only good solution.

Well...if performance is a real problem there may be inventive solutions. E.g. inline above-the-fold CSS and lazy load the rest in a non-blocking way (JS has loadCSS function that works in this way). So users will quickly see a styled page (but it may be less than perfect if she quickly scrolls before the rest has arrived and been applied). (Fallback: load full CSS in noscript tag for browsers with no JS.)

Conditional Loading and Lazy Loading


<img src="ucc.jpg" alt="..."
     loading="lazy" />

loading="eager" (default):
browser requests the image, regardless of whether it will be visible in the viewport.

loading="lazy":
browser defers requesting the image until the user scrolls to a point where the image will soon need to be visible in the viewport.

Performance

Monitor continuously!

Web Development

Lecture Objectives

External Resources

External Resources

External Resources

Multiple Requests

External Resources

Render-Blocking Resources

Avoiding Multiple Requests

Data URIs

Avoiding Multiple Requests

Avoiding Multiple Requests

Comparison

Conditional Loading and Lazy Loading

Performance

G'luck!