10 Tougher Tasks to Reduce Page Weight

January 24, 2014 - General

This entry is part 4 of 2 in the series Reducing Page Weight

In my previous article, 10 Quick and Easy Fixes to Reduce Page Weight, I discussed basic techniques that slim your site without fundamentally changing code. If your pages are still obese, there are more drastic dieting options you can contemplate…

1. Remove social network buttons

Do you have Facebook, Twitter, Google+ and LinkedIn sharing buttons on your pages? That’s 580Kb of content you’re serving to frustrated end users. Much of it is JavaScript that must be executed by the browser and some networks stipulate it must be loaded before your content appears.

Bloated social widgets are completely unnecessary — you can add fat-free social buttons to your pages with a few lines of HTML. A little JavaScript can progressively enhance the experience and show a pop-up window on desktop devices.

While simple buttons won’t show click statistics, you can discover far more information with event tracking in Google Analytics.

2. Check all third-party widgets

Social networks aren’t the only culprits. Adding third-party widgets to your page has a hidden cost that significantly exceeds the included markup. Even if the content is loaded from another domain, it may contain hundreds of kilobytes of data, JavaScript, CSS, and images.

If you must use a widget, consider one that is better written. Ideally, the widget JavaScript should be lightweight, loaded at the end of the page but able to place content in a specified HTML container. Alternatively…

3. Consider lazyloading — or on-demand content

Presume you’re showing a video hosted by a specialist provider. While the video is downloaded only when the user hits “play”, you are probably loading video API code and other related resources regardless of whether the user plays the video or not. Why not load all that content when the user requests it?

You can also consider on-demand images and content that download as the user scrolls the page. I’m not a fan of the technique; it can potentially have a negative impact on usability or SEO. However, it is useful for some types of web applications–for example image galleries.

4. Replace images with CSS3 effects

Are you slicing images to create gradients, rounded borders and shadows? I hope not — CSS3 makes such techniques redundant.

The effects won’t work in IE8 and below but oldIEs are dying and users won’t be aware because they won’t compare your site in multiple browsers. You can add clever shims such as CSS3 PIE but I wouldn’t recommend it: they can bulk up your page and make the older browsers slow to a crawl.

CSS3 effects generally degrade gracefully so it’s rare you need worry about older browsers. Pixel perfection has always been futile and is utterly ridiculous when you’re building responsive designs that adapt to different screen sizes.

A note of caution though: CSS shadows and gradients have been shown to be costly during browser repaints, especially if you’re displaying dozens of elements with these features added. So use the effects sparingly and test scrolling performance and repaints before committing to overusing these effects to replace images.

5. Replace JavaScript with CSS3 effects and animations

Is your JavaScript littered with $ ("#x").fade() and $ ("#y").slideDown() effects? That may have been necessary a few years ago but CSS3 animations, transitions and transformations have to a large degree superseded JavaScript effects. The reasons:

  1. CSS3 animation is natively handled by the browser; if it’s done right, it will often be much faster and smoother than JavaScript execution.
  2. CSS3 animation is easier to write and requires significantly less code.
  3. CSS3 offers 3D transformations which are extremely difficult — if not impossible — in JavaScript alone without a specialized library.

There are situations when you want fine-grained JavaScript control but they are rare exceptions. Again, effects won’t work in old browsers but should degrade gracefully.

6. Consider Scalable Vector Graphics (SVGs)

SVGs contain points, lines, and shapes defined as vectors in XML. SVGs are ideal for responsive designs since they will scale to any size without loss of quality and the file size is often smaller than a bitmap.

SVGs aren’t suitable in all situations. Photographs and complex images will always be better as a JPG or PNG. However, logos, diagrams, and charts are usually appropriate. What’s more, SVGs can be manipulated on the client using CSS and JavaScript.

There are tools that convert bitmaps to vector format, but starting from scratch will yield the best results. Packages such as Illustrator, Inkscape, and SVG edit provide a good start, although learning XML basics will help you produce cleaner code.

7. Replace images with icon fonts

You may have dozens of small icons in use throughout your site and managing individual image files isn’t fun. Fortunately, icon fonts can save space and sanity. A single font can contain hundreds of vector-based images which can be set to any color and scaled to any size in all browsers (going back to IE6).

You can use a dedicated font or, for optimal bandwidth-saving, use a tool such as Fontello, IcoMoon or Flaticon to create a font pack containing the icons you need.

8. Use image sprites

Bitmap images should be the last choice once CSS3, SVG and icon font options have been rejected. Often-used bitmaps can be packaged into a single sprite file so individual images can be accessed in CSS, e.g.

 .sprite { 	width: 16px; 	height: 16px; 	background: url("sprite.png") 0 0 no-repeat; }  .sprite.help { background-position: 0 -16px; } .sprite.info { background-position: 0 -32px; } .sprite.user { background-position: 0 -48px; } 

The advantages:

  1. You require a single HTTP request to load the sprite.
  2. A single sprite will normally result in a smaller overall file size than the total weight of the individual images.
  3. All images appear when the sprite has loaded.

Image sprites can be created in a graphics package or using tools such as Sprite-Cow and Instant Sprite. You can alternatively incorporate sprite production in your Grunt workflow.

9. Use data URIs

Data URIs encode binary and text assets as if they were external resources. Bitmap images and SVGs can be encoded directly in HTML, JavaScript, or — more usefully — CSS:

 .bullet { 	background-image: url("data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAABAAAAAQAQMAAAAlPW0iAAAABlBMVEUAAAD///+l2Z/dAAAAM0lEQVR4nGP4/5/h/1+G/58ZDrAz3D/McH8yw83NDDeNGe4Ug9C9zwz3gVLMDA/A6P9/AFGGFyjOXZtQAAAAAElFTkSuQmCC"); } 

This will reduce the number of HTTP requests — although maintenance is more difficult unless you can automate the process in some way. I would only recommend it for small, often-used images that are unlikely to change.

Tools such as DataURL.net and data: URI Generator will convert files to data URIs for you.

10. Use website assessment tools

You won’t know whether your diet has been successful unless you’re monitoring your page weight and the resulting download speed improvements. Browser developer consoles and free online tools such as Google Page Speed Insights can help. A comprehensive list is coming in my next article before we discuss more radical, liposuction-like page weight reduction techniques in the last part of this series.

The post 10 Tougher Tasks to Reduce Page Weight appeared first on SitePoint.

SitePoint

Bookmark and Share

› tags: Page / Reduce / Tasks / Tougher / weight /