It’s easy to blame responsive design, but the truth is, we’ve just gotten into the habit of building bloated websites.

In the two decades since the Web came along, computers have swiftly been getting faster and more powerful. And our Internet connections, in our homes and offices, have just as swiftly increased in speed (many times over).

Our computers can do all sorts of magic things, so we want our websites to do magic things too.

As we’re designing or developing sites, we’re generally sitting in front of computers with pretty speedy connections in our offices or homes. It’s easy to forget that not everybody is using such a fast connection.

Remember dial-up? It seems archaic to even think about it. That screechy noise we had to listen to every time we connected to the Internet... It took a little while for everything to load, but we didn’t mind too much, because that was the only option. And it wasn’t even that slow, because websites were so much lighter a decade ago.

Today, only about 3% of Americans still have dial-up Internet access at home. That’s hardly anybody, right? Well, there are 300 million people in the United States, so 3% is only... 9 million. Hmmm. Well, perhaps that’s a few people we need to worry about. But forget about them for a moment, because the real issue we want to talk about is mobile Internet access.

While devices of all sizes have gotten more powerful, our connections—at least some of them—have gotten slower. So now what?

The issue is striking a balance. There are all sorts of amazing things you can do with HTML, CSS, and JavaScript to make your website look incredible and do incredible things.

But the goal of a website isn’t to look good, it’s to provide information and interactivity. And if your visual effects are slowing down your site so much that they’re getting in the way of the main goal, then you need to reexamine what you’re doing.

The first thing that needs to be pointed out is that slow performance isn’t an issue that’s unique to responsive design—it just tends to get noticed more on responsive sites because we’re paying attention to how they perform on mobile devices, which generally have slower connections.

Over time, websites have gotten more and more bloated.

According to the HTTP Archive, which compiles statistics based on thousands of the most popular websites, in the past two years the average page weight has increased from 807 KB to 1,492 KB.^[8] That’s nearly a megabyte and a half of data being downloaded to view just one page on a website!

Of course, that includes everything that’s needed to render the web page: HTML, CSS, JavaScript, images, web fonts, Flash, and so on.

Whether or not your website is responsive, there are many things that you can do to make it faster, and most of what we’ll discuss in this chapter is applicable to all websites, not just responsive websites. Even if your site isn’t responsive, there will likely be people visiting it using mobile devices and slow connections, so do your best to make it as fast as is feasible.

It’s not that simple, though. Responsive design is just a tool, and whether or not using responsive design produces a good website is up to the designers and developers who work on the site.

Simply taking a desktop design and adding responsiveness to it will frequently result in bloated code. That’s why you’re often better off starting at the beginning and designing carefully and thoughtfully.

First, you’re at your browser, either on your desktop/laptop computer or a mobile device. You type in a URL, or click on a link.

Latency is the amount of time it takes to connect to the Internet provider.

If you’re on a stationary connection (such as a broadband connection at your home or office), you don’t have to worry about this because you’re continuously connected to the provider.

But if you’re on a mobile network, there is a limited amount of bandwidth at any given point in time, so you don’t have a continuous connection; you’re only connected when you’re actively requesting or sending information to the Internet.

So, your mobile device needs to connect to the network in order to load a web page. To do this, the device contacts a local cellular tower and says it wants to start a connection.

Under ideal circumstances, the tower will reply right away and set up the connection. But circumstances aren’t always ideal, so this process could end up taking several seconds—and we haven’t even started loading the web page yet! Unfortunately, you (the website owner/developer) can’t do anything to speed up this part of the process for users, but you need to know that these delays can exist.

The speed of the original connection (latency) depends on how many devices are trying to get a connection at the same time. For example, if you’re at a major sporting event, or in a large city, it may take longer to connect because so many other people are trying to connect at the same time.

Once the connection is established, the browser sends out a request to the DNS provider, which is usually the Internet provider.

DNS (the Domain Name System) is what translates the URL into an IP address so the browser knows where to find the website. The DNS provider sends back the correct IP address, and then the browser knows where the website is hosted.

The browser is looking for the site located at a particular URL, such as http://www.example.com. However, websites are actually identified by the numerical IP address, such as 192.0.2.0, of the server they are hosted on.

A URL doesn’t necessarily go directly to an IP address, though. Sometimes you have a URL that redirects to a different URL. For example, if you type www.washpost.com in your browser’s address bar, the text will actually change to www.washingtonpost.com as it loads the site.

The redirection happens as part of the DNS process before the browser is told the IP address of the actual website.

This is relevant to performance, because any redirects can add time to the loading process. This applies not only when you redirect from one domain to another, but if you redirect to a different subdomain on the same site, such as if you have it set up to add www to a URL (so example.com would change to www.example.com).

Having one redirect in the process, such as for the www, isn’t a big deal, but sometimes URLs are set up in a convoluted way so that there are multiple redirects to get to the actual site. This can increase the loading time of your pages.

Once the browser finds out the IP address of the server where the website is located, the browser sends an HTTP request to the server, requesting that the server send the page located at the URL.

The HTTP request also contains additional information in the HTTP header (think of this as the metadata of the request). One of the key parts is the user agent, which identifies the requester’s operating system and browser.

In some cases, the website is set up so that the server will send back a different website based on the information contained in the user-agent string.

For example, if the website’s server knows that it’s a mobile browser making the request, it may send the mobile version of the website (an m-dot site) instead of the regular website. Unfortunately, the user agent cannot always be relied on as always correct, although it’s fairly accurate.

When the server receives an HTTP request, it sends a response, which consists of an HTTP header along with the file requested (in this case, the HTML file).

In the response, the HTTP header may contain additional information to be used by the browser. One important bit is whether the browser is permitted to cache the resource, and how long it can be cached. This is information provided by the website’s server (you can adjust these settings on your site’s server), not information that is part of the HTML file.

You can see HTTP headers using the Developer Tools in Google Chrome, as in Figure 11-1. Go to the Network tab, and click on any resource in the first column. On the right panel, you’ll see the HTTP headers for the request and the response.

Often, files such as HTML, CSS, or JavaScript will be compressed using gzip so that the file size is smaller and they will download faster.

When the browser sends its request, one of the HTTP headers tells the server whether the browser can accept compressed files (most modern browsers can). If the browser can accept a compressed file, that’s what the server will send. Otherwise, it will send an uncompressed file, which can take a bit longer.

Once the browser receives the compressed file, it will unzip the entire file right away.

Figure 11-1. The HTTP headers for The Washington Post website, viewed using the Google Chrome Developer Tools.

The next thing that happens is that the browser parses the HTML, creating a Document Object Model (DOM). Essentially, the DOM is a representation of the web page as it will be displayed. The DOM starts out being the same as the HTML for the page. But if you have JavaScript events that change the content of the page, the changes will be made to the DOM, not to the HTML.

For example, you might have a script that allows you to click a “more” link to view additional text directly on the page. The HTML for the page doesn’t contain the additional text, and when you first load the page, neither does the DOM. But after you click the “more” link, activating the script, the additional text will be added to the appropriate place in the DOM and will be displayed on the page.

You can find a more detailed explanation of the DOM in Chris Coyier’s “What Is the DOM?” (http://css-tricks.com/dom/) on CSS-Tricks.

Once the DOM is ready to go, the browser starts to render the HTML document. It goes one element at a time, starting with the very first element in the <head>.

Only after the browser has finished with the <head> can it start rendering the <body>.

It starts at the top and renders one element at a time. The browser needs to know what each element should look like, and where it will go on the page, so it looks at the CSS to figure out what to do.

After everything in the page has been loaded and rendered, the document executes any onload JavaScript events. onload simply means that the event will be triggered as soon as the page is finished loading.

This seems obvious, but write your code as straightforward as possible.

Don’t add a class or ID name in order to apply a style to an element if you can apply the style without it. For example, don’t do this:

<header>
<ul id="navigation">
...
</ul>
</header>

If there’s only one <ul> in your <header>, you don’t need an ID, and you can apply styles like this:

header ul { ... }

That one is pretty obvious, but extra classes/IDs have a tendency to work their way in during the coding process, and you many not realize they’re unnecessary until you go back and look at the code later.

Take advantage of the cascade to avoid repeating CSS. For example, if most of the text on your site uses a certain font, apply the font-family to the <body> element, rather than separately to <p>, <li>, and so on. Then you’ll only need additional CSS for the exceptions.

Go back and clean up your stylesheets. You probably have styles in there that apply to something on your site that no longer exists.

Although it’s best to keep your code straightforward while you’re writing it, it’s hard to predict what’s going to be necessary or not, so make sure to go back at the end to look for any pieces you can take out.

We add a lot of empty space as we write code, because it makes it much easier to read, but the browser doesn’t need all those extra spaces, line breaks, and indentions.

Minification is the process of removing these unnecessary characters from your files. For example, instead of:

p {
    font-family: Georgia, serif;
    font-size: 1.1em;
}
li {
    font-family: Helvetica, sans-serif;
    font-size: 1.2em;
}

the browser only needs to see this:

p{font-family:Georgia,serif;font-size:1.1em;}li{font-family:Helvetica,sans-serif;font-size:1.2em;}

In this example, I was able to remove 10 spaces, 2 tabs, and 7 line breaks—nearly 15% of the characters!

Of course it would be incredibly difficult to have to write your CSS like this, with no spaces. And you can’t simply search for and replace all the spaces and line breaks in a document—some of them actually do need to be there (e.g., applying a style to nav li wouldn’t work if the browser saw navli).

Thus, there are tools called “minifiers” that you can use to minify your CSS, JavaScript, or HTML files before uploading them to your web server, removing comments (unnecessary for the browser) as well as whitespace.

There are a few ways to make this happen.

First, for a very small site with infrequent edits, you could minify each file individually before uploading it to your web server. If you want to minify one page at a time, there are several websites that can do this via a simple form—try CSS Minifier (http://cssminifier.com) or YUI Compressor (http://refresh-sf.com/yui/), or search online for a “CSS minifier” or “JavaScript minifier.” But for many sites, minifying the files manually would be too much extra work.

If only one person is working on a site, it’s easy—if all your files are saved on your own computer, you can use a preprocessor or an app such as LiveReload (http://livereload.com) or Mixture (http://mixture.io) to minify your files before uploading them to a server, allowing you to always edit the original file with spacing and comments intact.

If you collaborate on files, it’s a little trickier, as everyone will have to work from the same original files, rather than downloading the files from the server to get the latest versions.

You could set up your server to automatically minify files on the fly, by using a tool like Minify, which works on PHP, but the extra processing time tends to offset the benefit of sending a smaller file, so it’s not recommended.

One easy way to reduce HTTP requests is to call fewer CSS and JavaScript files by using concatenation to combine them.

Again, it might be more convenient for the developer to separate everything out into separate files that serve different purposes, but because each file requires a separate HTTP request, this can increase the load time of the page.

If you decide to have multiple files for development purposes, you can combine the multiple files into one or two files before uploading them to the server. Many of the same apps that you use for minification will also do concatenation, such as YUI Compressor (http://yui.github.io/yuicompressor/) or Minify (https://code.google.com/p/minify/). You can also use something like QuickConcat (https://github.com/filamentgroup/quickconcat), which works sever-side if you’re using PHP.

And obviously, some files can’t be combined—for example, if you’re using media queries in stylesheet links to target different stylesheets to different screen sizes, or if some stylesheets are only called on certain sections of the site.

And of course it would be easier to simply decrease the number of stylesheets by combining the code in a few files rather than many. You can use comments to separate sections for easier reference, and use a minifier to strip out the comments for the live version.

However, don’t go overboard. Browsers do have the ability to download a few files at once in parallel, so having a couple of CSS files may be better than one very long one.

Anything that’s being downloaded from another domain can cause a delay. This might include embedded videos, maps, ads, or analytics.

The main issue is that every additional domain adds another DNS lookup during the process of loading the page. This is avoided if all the content is coming from the same domain.

A secondary issue is that you’re relying on someone else’s site to provide the content. If that site is slow—or not available—your site can get held up or stuck while trying to load the assets.

One of the most common culprits here are social media widgets—you know, those little icons for Facebook, Twitter, and other sites, with a “Share This” link.

These are often implemented on the page using third-party software that allows you to track how many users click on each action, on any given page. The problem is that usually they are made up of a ton of code.

Figure 11-4 shows what the social media widget looks like on The Washington Post website.

Figure 11-4. The social media widget from The Washington Post website.

It looks simple enough, but part of the problem is the “More” link at the bottom, which includes links to several other social media sites. The code is not optimized—each option is a <div> and a <span> inside a <li>, along with several classes and an onClick event.

That’s not to mention all the icons, which at least are in only one image sprite, although it’s a whopping 22 KB.

Think about whether you really need such a complex widget. Users will still be able to share your content without it. Oliver Reichenstein wrote a great blog post called “Sweep the Sleaze” (http://ia.net/blog/sweep-the-sleaze/) on the Information Architects Inc. website that details the reasons why social media widgets don’t add value to your website.

But if you do need to keep widgets like this, which are usually made of JavaScript, definitely think about whether their loading can be deferred to after the page has rendered (later in this chapter we’ll talk more about deferring JavaScript). Sure, it will pop up on the page a second later, but users generally will at least have started reading the page before they make a decision to share.

Image sprites, as we looked at in detail in Image Sprites in Chapter 6, are a way to reduce the number of files to download by combining several small images into one large image.

This is most effective when the images are related to each other (e.g., a set of icons that are displayed together).

An HTTP redirect is when a user loads a page from a URL that is different from the actual URL of the page, and the browser is redirected to the correct URL. This is something that would be configured on your web server, such as by using .htaccess in Apache, or by using functionality in your content management system (CMS).

The most familiar kind of redirect is when a website can be accessed from alternate domains. For example, if you type www.newyorktimes.com into your browser, once the page loads, you’ll see in the address bar that you’re actually viewing www.nytimes.com.

You may also use redirects when the URL of a page has changed and you want to make sure users who go to the old URL will still get to the correct page, or if you want users directed to a particular subdomain of the site.

On sites with separate mobile and desktop versions, it’s common to use redirects to get users to the correct version of the page for their device—for example, a redirect from www.example.com/pagename to m.example.com/pagename. (One of the advantages of responsive design is that you don’t have to worry about this type of redirect.)

Obviously, there are many occasions when you need to use HTTP redirects. But keep in mind that they do have a performance cost.

Especially make sure that any files used by your website, including images or stylesheets, are being called using the correct URLs. As a start, use relative links (/images/file.jpg) rather than absolute links (http://www.example.com/images/file.jpg) when linking to files on the same domain.

If URLs on your site change during a redesign, change the actual links on the site whenever possible, rather than using redirects to get users to the right place.

Avoid having more than one redirect chained together.

Compression can be used to reduce the size of all the files being sent.

Most web servers are able to use the gzip format to compress files before sending them to the user’s computer. When a browser requests a page, it will tell the server whether it can process compressed files. The server will send compressed files to browsers that can handle them.

You can use GIDZIPTest (http://www.gidnetwork.com/tools/gzip-test.php) to check whether a web page is compressed and, if so, to compare the file sizes. For example, if I test the front page of The Washington Post website, I see that it is gzipped, with a savings of 69.5% (300 KB to 92 KB).

You can enable server compression as a configuration on your web server. For example, Apache sites use mod_deflate (http://httpd.apache.org/docs/current/mod/mod_deflate.html). Your web hosting provider may offer this as a setting on your control panel, and it may be enabled by default. If you’re on a shared host, you may not have the ability to turn compression on and off.

All of your HTML, CSS, and JavaScript files should be compressed.

A lot of the files that are downloaded to display a web page will be reused as the user browses to other pages on the site. This includes stylesheets, images, JavaScript files, and fonts.

Browser caching means that the browser can temporarily store these files on the user’s computer for a specified period of time, so that as the user visits other pages on the site, or if she comes back to the site another day, the browser doesn’t have to reload those files.

Not only can this decrease the load time of a page by reducing the amount of data that needs to be downloaded, but it also decreases the bandwidth required to download the page, which is helpful to mobile users who have plans with limited bandwidth, or have to pay per MB.

Browser caching doesn’t necessarily happen automatically. The browser doesn’t decide what to cache; rather, your web server has a set of rules that tell the browser if and when it’s all right to cache certain files.

How you set up browser caching depends on the type of web server you have. For example, in Apache you would edit the .htaccess file.

Your hosting may have browser caching turned on by default. If you aren’t sure, you can use Google’s PageSpeed Insights (http://developers.google.com/speed/pagespeed/insights/) to check.

You can set different expiration times for different types of files. For example, you could specify that .jpg files expire after one month. The browser would then save any .jpg files, and not try to reload them until a month after the first time they were downloaded.

Choosing how long to allow files to be cached depends on the types of the files, and how frequently you update those file types on your site. For example, you probably don’t change image files on your site often, so it would be safe to allow them to be cached for a long time. If you do need to change an image file, such as changing to a new version of the site logo, you could simply give the replacement image a different filename, so the browser would be forced to download it.

If you change your stylesheets very frequently, you may want to give them an expiration of one day. That would allow the user the benefit of not having those files redownloaded as he browses the site, but changes would show up for the user within 24 hours after you make them.

Keep in mind that the browser’s cache is likely limited in size, so if a user visits a lot of websites, not all assets with long expiration times will actually be stored for that long. This is especially an issue on older mobile devices, which have very limited caches. But even with minimal cache storage, files will be kept in the cache during the user’s current visit to the site, decreasing the load times of every page except the first one visited.

Generally, static resources should have an expiration of at least a week, and longer if possible. The maximum allowed is one year. Only assets that change many times a day, such as the front page of a news website, should be set with no caching at all. Even allowing a few hours of browser caching on frequently changing resources can decrease the load times of a website.

You already know that your website is built in layers, starting with HTML for the content, and then a second layer, CSS, for presentation.

The third layer is JavaScript, which is for interaction, or behavior. It’s an optional layer—you can create a perfectly good website without any JavaScript at all, as long as you are only building something for users to read and look at, and perhaps have only basic interactions with.

Some of the common things that JavaScript is used for are validating form field entries, allowing the page to load new content without reloading the whole page, and the animation of page elements.

JavaScript is a client-side programming language. That means that all the JavaScript code has to be loaded by the browser (the client), and the browser does all the work of making things happen. This is in contrast to a server-side language like PHP, which does things to the page on the server before it is even sent to the browser.

JavaScript can be included in either your HTML page, or as a separate file with the .js extension (linked from a <script> element in either the <head> or the <body>).

After the browser loads an HTML document, it starts at the very top of the <head> and loads/renders/executes each element as it encounters it. So, if the first element in the <head> is a link to a CSS file, it loads the file before moving on to the next element.

When the browser encounters JavaScript—either a link or an inline script—it loads and then executes the script before moving on to the next element.

So, if you have scripts in your <head>—either inline or links to separate JavaScript files—the browser will execute these scripts before it even gets to the <body>, and before it starts putting content on the screen! That means your users will be looking at a blank screen while the scripts run.

However, that doesn’t mean that when this JavaScript executes, it’s actually making anything happen.

Most JavaScript is triggered by an event. For example, you might see onclick—that means that whatever that bit of JavaScript does, it’s not going to happen until the user clicks on a specified element. onload means that the JavaScript does its thing when the page is done loading. Another example is having a script that validates form fields when the user clicks the submit button.

Much of the JavaScript in a web page is simply getting everything set up for something that will happen later, via an event like onclick.

Unfortunately, these scripts can cause a lot of problems, because depending on where on your page you add or link to JavaScript, it can block the rendering of the page, slowing it down considerably.

Additionally, the way that browsers work means that the browser can’t be rendering the page and executing a script at the same time. So although a browser can kind of do more than one thing at once (it’s complicated...), if it encounters a script, it has to stop any rendering while it’s executing the script.

JavaScript that blocks the loading of page is sometimes called blocking JavaScript.

Because the browser has to run the JavaScript as it encounters it, the browser may be forced to run all the JavaScript before it renders the HTML and CSS, even if doesn’t need most of the JavaScript until after the page has finished loading.

If you aren’t sure whether any of your JavaScript is blocking rendering, try Google’s PageSpeed Insights (http://developers.google.com/speed/pagespeed/insights/), which will tell you if your site has any blocking elements. See Figure 11-5 for an example.

Figure 11-5. PageSpeed Insights will tell if you if any of your JavaScript is blocking the rendering of the page.

To keep your JavaScript from blocking the rendering of the page, you should make sure that as the browser loads and renders the page, it’s only loading the JavaScript that’s necessary to display what the user will first see on the page. All other JavaScript should be loaded after the page is rendered.

<head>
    <script type="text/javascript">
        ...
    </script>
    ...
</head>

<script type="text/javascript" defer>
    ...
</script>

<script async src="example.js">
    ...
</script>

Using JavaScript libraries or frameworks can be another cause of bloat on your site.

A JavaScript library is a collection of prewritten JavaScript that makes it easy to write scripts for your website. Basically, it sets up a bunch of common functions that you can use on your site, so you only have to write a single line of JavaScript, rather than having to write all the JavaScript from scratch.

There are many different JavaScript libraries, with the best known being JQuery (http://jquery.com). A JavaScript framework is similar to a library, only with more capabilities.

The problem with adding a JavaScript library to your website is that you may only be using a small part of its functionality—but you’re stuck with all the other code in the library that you don’t need.

If you’re using a JavaScript library on your website, look at whether you really need a whole library. You can now find a lot of micro-libraries or micro-frameworks, which are much smaller (generally 5 KB and under) and only contain the code to do one particular task. Visit the Microjs (http://microjs.com) site, which has collected a list of hundreds of them, and allows you to search for exactly what you need.

Another option, of course, is to just write the JavaScript you need, instead of relying on someone else’s prewritten code.

Using a CSS framework can cause a similar problem to using JavaScript libraries—you end up with a lot of code that you don’t actually need. Frameworks take into account all the possible things that a site might need to do, and they include code for all of that. As such, they’re far more complex than is needed for most websites that use them.

If you use a framework, such as Bootstrap or Foundation, to build your site, be aware that this is an issue.

The CSS in frameworks is generally easy to follow, so you should be able to go through and pull out broad sections of CSS that you know you won’t be using.

For example, if your website doesn’t contain any data tables, you can remove all the CSS referring to tables. Of course, you can always add this CSS back in later if you decide to add tables to your site.

You can save some more code, although with a bit more of a time investment, by going through and removing any specific classes you aren’t using on the site.

Additionally, make sure you aren’t duplicating CSS rules. The framework will provide values for pretty much everything. If you need to change something, such as the font-size for <h1>, don’t just add that CSS on the end. Instead, find the <h1> in the framework stylesheets and replace the value. Adding a separate declaration at the end not only adds unnecessary code, but it also can create confusion for developers who are trying to edit the stylesheet later.

Finally, although frameworks can come in very handy if you need to get a site up quickly, or if you need to create a website using staff that aren’t experienced developers (e.g., for nonprofits, small businesses, or hobby projects), you’re never going to get a site that’s as lean as one that is created from scratch.

You can use a content delivery network (CDN) as part of your web hosting solution. When using a CDN, instead of having all of your website files hosted on one web server, copies are hosted on servers at data centers in various geographic locations. When content is requested from your website, the requests are routed to the most optimal servers, based on physical location, current web traffic patterns, and so on.

This can increase the performance of any site, although it is most particularly useful for live, streaming content, or for sites with a high volume of traffic.

A site may choose to host only part of its content on a CDN. For example, a high-traffic ecommerce site may host all of its images on a CDN, because the site is very image-heavy, but host the rest of its content on regular hosting.

You can purchase CDN service either as an add-on from your web host, or from a separate company, typically an Internet service provider (ISP). Prices can start as low as $10/month for very small websites, up to thousands of dollars each month for very large sites.

Your content management system (CMS) might also be slowing down your site. This is more of an issue with enterprise CMSs than with basic CMSs like WordPress or Drupal.

Unlike just sending a plain HTML page when requested, a lot more has to happen for a CMS to send a requested page to a browser. Your entire website is contained in a database. A bunch of queries will run to piece together all the separate elements of the page on the fly—navigation, content, plug-ins.

Ideally it will happen very quickly, but a lot of things can go wrong and add delay.

Studies have shown definite performance differences among CMSs, so you should research performance when choosing a CMS.

If you already have a CMS, check all the settings to make sure you’ve done everything you can to improve performance.

Always make sure you have the most recent version of your CMS and any plug-ins—outdated software is likely to run slower, and may cause conflicts that add delay.

The University of Notre Dame website uses RESS, in addition to responsive design, to serve different content to desktop and mobile users.

The desktop version of the site has each of the main sections all on one page—About, Academics, Admissions, and so on. You can see on the left of Figure 11-7 the top of the page for the desktop site, with the Admissions section just below the main section. If you resize your desktop browser to 320 pixels and load the site, as in the center image, you still get all that content, although media queries have rearranged everything into one column. The image on the right shows what you get when the site is loaded on a smartphone—that’s all of it.

Figure 11-7. Mobile phones are served an entirely different version of the University of Notre Dame’s website.

On the mobile phone, you still get access to the main sections, such as Admissions, but now each is on a separate page instead of further down the main page. And you don’t have content parity, because much of the desktop site is missing on the smartphone version.

I personally don’t like sites where all the content is on one page and accessed by anchor links, making it seem like there are separate pages when there really aren’t. It’s easy to get lost on the page, and if you want to share particular content, you can’t simply copy the URL from the address bar of your browser, because it’s the URL of the home page. (This page doesn’t even use real anchor links, which would give you an add-on at the end of the URL that would allow you to link to a particular section of the page, such as #admissions.)

I’m glad they aren’t giving all that content on one page to mobile users, because it would be impossible to navigate through the page on a small screen. But I don’t think they need to give desktop and laptop users all that content on one page either. Not only is it confusing, but it means a heavy page weight, and not everyone with a laptop has a fast connection—especially students who are toting their laptops around campus and may or may not be getting a good WiFi signal.