One of the more valuable things you can do as an optimizer is reducing page weight. That includes:

• What you’re serving.
• How much you’re serving of it.
• Where the things you serve are coming from (such as your own server v. a CDN).
• Who you’re serving (someone on gigabit fiber in South Korea is going to load your page faster than someone on EDGE in Namibia).
• The client-side processing load, which can be significant when you’re using lots of JavaScript.
• The server-side processing load, which can be significant if you’re using a framework that might not scale well – or you’re dealing with lots of spaghetti code.

This isn’t the world’s sexiest topic, but it pays off handsomely. Page weight usually has a direct correlation with conversion rate: reduce page weight, your conversion rate goes up. It’s one of the biggest no-brainers that any optimizer can do, and picking the lowest-hanging fruit tends to make a lot of money. Let’s talk about some of the easiest things you can do to boost conversions right now.

Compress Your Images

99% of businesses that I encounter don’t know how to prepare their images for the web. You should convert as many images to JPG as possible, crop & resize them so they remain retina-grade but no larger, in the correct aspect ratio, and then run them through Guetzli to compress them as much as possible.

If you have images that are translucent or partially transparent, keep them as PNG and run them through ImageOptim.

Yes, this needs to be done for every single image on the site: even ones that you’re pulling in through third parties. Do it for as many as you possibly can first, and then work on a strategy for each third-party provider (such as Instagram hashtag rolls, third-party review engines, etc).

Use SVG for All Vectorized Assets

Any vector or icon-based assets should be set up as SVG. This is usually the difference between a 150KB+ payload and a payload under 5KB. This can manifest in two ways:

• Easy: set up SymbolSet for the icon libraries that you need – likely SS-Standard and SS-Social (for share icons). This costs under $50, can be repurposed among many sites, and is SEO-friendly, using discretionary ligatures to
• Slightly less easy, but still pretty easy: convert everything to SVG, load it inline (or create server-side includes/templates to do it), and compress/minify everything using svgo.

Optimize Your Webfont Payload

Webfonts can add a lot to your page load, especially if you aren’t using specific weights or styles of a given typeface. TypeKit, Cloud.typography, Google Fonts, and others allow you to customize exactly what weights and styles of a typeface get loaded.

Only call the ones that actually pertain to your site, and ignore the rest.

Turn On Caching

You should be caching as many assets client-side as possible, so that people don’t download your logo over and over on every page of your site. This makes future loads faster in a given session. Use this tool to determine what assets are being cached by your customers – and what their corresponding settings are.

If your server is on Apache, you can set up caching by modifying the .htaccess file in your site’s root folder. Here’s a typical set of caching rules (which are set by file type) for a site; modify this however you see fit, and paste it into your site’s .htaccess file:

# 1 YEAR
<FilesMatch "\.(flv|ico|pdf|avi|mov|ppt|doc|mp3|wmv|wav)$">
Header set Cache-Control "max-age=31536000, public"
</FilesMatch>

# 1 WEEK
<FilesMatch "\.(jpg|jpeg|png|gif|swf)$">
Header set Cache-Control "max-age=604800, public"
</FilesMatch>

# 3 HOUR
<FilesMatch "\.(txt|xml|js|css)$">
Header set Cache-Control "max-age=10800"
</FilesMatch>

# NEVER CACHE - notice the extra directives
<FilesMatch "\.(html|htm|php|cgi|pl)$">
Header set Cache-Control "max-age=0, private, no-store, no-cache, must-revalidate"
</FilesMatch>

If your site is running on an ecommerce framework like Shopify, this may be taken care of for you. I’d reach out to your site’s support department and make sure, though.

Use gzip Compression

Most sites use a technology called “gzip” to compress assets as they get delivered to your customers. Use this tool to determine if your site is correctly serving assets via gzip.

Compression happens by MIME type, which is slightly different than filetype. MIME type is the specific way a file is read; filetype is the extension. For example, TXT & CSS are separate file types, but both are plaintext documents.

Modify the following however you see fit, and add it to your .htaccess file wherever you want:

# compress text, html, javascript, css, xml:
AddOutputFilterByType DEFLATE text/plain
AddOutputFilterByType DEFLATE text/html
AddOutputFilterByType DEFLATE text/xml
AddOutputFilterByType DEFLATE text/css
AddOutputFilterByType DEFLATE application/xml
AddOutputFilterByType DEFLATE application/xhtml+xml
AddOutputFilterByType DEFLATE application/rss+xml
AddOutputFilterByType DEFLATE application/javascript
AddOutputFilterByType DEFLATE application/x-javascript

This compresses any text you’re going to be sending out. You don’t need to compress other file types (think about it: you already compressed your images!). Text is the one that really needs it.

Send as Little JavaScript as Possible

Finally, you are probably delivering a suboptimal payload of JavaScript. This sucks for three reasons: it increases payload, it increases client-side processing load, and it’s harder to debug when something goes wrong.

You should only deliver the JavaScript that’s necessary for conversion, period. Here are the first steps you should take to do that!

Kill Off Redundant Framework Calls

Go into your web inspector, shift-refresh the page, and sort by file name. It’s very likely that you’re calling multiple versions of various tracking snippets (especially GA, if you use the latter) and JavaScript frameworks (especially jQuery). Make sure you’re only loading one of everything! I’ve personally removed over 10MB of redundant tracking snippets from a single page.

It’s very easy for frameworks and tracking snippets to sideload stuff you may not want, as well. Both Olark and Yotpo load their own versions of jQuery, and to the best of my understanding there’s no way to turn them off. If you use VWO, a 1.4.x version of jQuery sideloads with your snippet by default – which means at best, you’re dealing with double the client-side processing load; and at worst, if you’re using jQuery 3.x.x, you risk significant bugs in the way jQuery-enabled JavaScript is being loaded. Change vis_opt.js to vis_opt_no_jquery.js (in your synchronous snippet) and set use_existing_jquery to false (in your asynchronous snippet) to remove the jQuery snippet that’s being sideloaded – and make sure that VWO isn’t going to break when you do it.

Aggressively Test Third-Party Plugins

Are you loading a live chat widget on your site? Trying to get feedback on a page? All of these load extraneous JavaScript that harms page load – and the conversion drawbacks might outweigh the potential business benefits that you’re getting from these third-party tools.

Questioning Appropriateness

As usual, you should first assess whether it makes sense to have a given widget on a page. For example, it may be the case that quick view is sideloading too many high-resolution images in the background, especially on mobile. And it may be that live chat doesn’t make sense to deploy on the home page – only on interior pages when someone is further along in the funnel, more likely to trip up, and more open to reaching out for help.

Most businesses carelessly spray their shiny new conversion-helping tools all over the site, thinking that ubiquity will help. But you should really research whether it does – and pare back extraneous tools when they prove to be distracting or frustrating to your customers.

Testing Effectiveness

What’s one good way to simplify the page’s JavaScript? Yep: through A/B testing. Try removing a given widget (or two or three) and measure its impact on conversion for yourself. You’ll probably be surprised how little of a difference those little widgets make in practice!

Minify What’s Left

Lots of frameworks and toolkits have minified versions of their code, which remove white space, condense variable names, and move everything onto one line. For example, jQuery 3.2.1 is 270KB uncompressed, and 90KB when minified. You get the exact same functionality in each – it’s just one is human-readable and takes up another 180KB of bandwidth for every single page load.

Go through all your frameworks and determine whether you’re accidentally sending the uncompressed versions of each – and whether you can get a major quick win by sending the minified versions, instead.

Why This All Matters

I spent exactly two sentences in this lesson talking about A/B testing – and it was secondary to the bigger goal, which is optimization. I want to be very clear here, though: the ultimate goal is to increase your conversion rate, by whatever means are at your disposal. And if you take these steps to reduce page weight for your customers, you’ll probably watch your conversion rate increase accordingly.

You need to make it easy for people to browse, make a decision, and act – quickly.

← Back to the Blog Check Out Draft’s Store →