Website

6 tips to turn your slow loading website into a brisk browsing experience

Internet users want a speedy experience and they’re not getting it, a fact that leaves them frustrated and website owners with less revenue. Don’t believe it? Numbers don’t lie. A full 53 percent of surfers want any site they visit load in three seconds or less. The largest ecommerce sites in the world recognize this necessity – they load incredibly fast. Most of the rest of the internet leaves a time gap that makes for a lot of gritted teeth and nervous toes tapping the floor. The good news is that speeding up a slow website is not difficult or time-consuming. The bad news is you might not choose to do it.

Are You Flirting with the Performance Poverty Line?

The performance poverty line is a term that represents the point at which being slow doesn’t matter because you’ve already lost most of your traffic. That number sits at around 8 seconds. The more pertinent question is, do you know your website’s speed. REALLY know your website’s speed?

No guessing because this is important stuff.

There’s an easy way to find out. Pay a visit to a website called Pingdom — it’ll probably load fast because it’s sort of their business — and enter your URL in the box. Select a location from the dropdown menu and hit “start.” Unless they’re exceptionally busy (it happens sometimes) you should get a performance summary in less than a minute.

Screen capture of Pingdom report

There’s a good chance what you see won’t impress anyone, but that’s okay. Few websites do. We’re here to provide you with a road map to get those numbers headed down, down, down and your visitors to start getting happy, happy, happy. Let’s call this…

A 6-Part Roadmap to Fast Websites and Happy Customers

Part 1: Magically Shrink Your Website

Actually, as far as we know, there’s no way to magically shrink your website but you can get the same effect by applying a sweet little bit of technology called Gzip compression. When implemented, some site owners have seen overall file size reduction of as much as 70 percent. That’s huge. Actually it’s tiny and that’s the point. It works like this. When a request hits the server to view the website, it automatically zips all the files before sending them onto the requester’s browser, where it is unzipped and displayed.

Part 2: Fix Bad Design and Too Many HTTP Requests

Every element on your website — we’re talking about images, videos, scripts, and even text — generates an individual request to the server. The more “stuff” your website has, the more requests there are and the longer it takes to load. If ever there was an argument for using a minimalistic approach when designing your website, this is it. Fewer requests mean a faster website. The tricky part is to not get distracted by all things you could do and stick to only what is needed to accomplish the site’s mission.

Overview of http requests and responses

Part 3: Put Hefty Images on a Diet

Images are huge. Incorrectly (or not at all) optimized, they put a terrible strain on bandwidth and leave the server and browser gasping from the strain. While we could write a book on the topic, there is one thing you can do that will fix a lot of the issues and that is choose the correct format — png, gif, and jpeg are good — and make the things as small as you can stand BEFORE uploading to your website. If you upload a full size image, even if you reduce it later, the server still has the original version and that’s the one that clogs the pipeline.

Part 4: Upgrade Your Hosting

We love cheap stuff as much as the next person but when it comes to choosing a web hosting plan, you need to understand the different types of plans and know when it’s time to upgrade. Inexpensive shared plans can be as low as a few dollars a month and that’s okay for a hobby or site that doesn’t have much traffic yet. Once you reach a certain level, though, the shared resource approach of this kind of plan will almost certainly mean slow-loading and downtime. While a dedicated server might not be worth the expense, a virtual private server or VPS hosting can be a great compromise.

Schematic depicting VPS

Part 5: Turn on Browser Caching

Browser caching is an easy-to-implement, tactic that most fast-loading websites use. The idea is simple. Rather than force the server to send over all the website files every time someone visits, static files (those that don’t change) are stored in the browser’s temporary memory and only dynamic files have to be retrieved. Obviously, this doesn’t help on a first visit but, with browser caching enabled, subsequent visits will be quicker. For WordPress websites, W3 Total Cache is a free plugin to look for. Others just require a simple code addition.

Part 6: Resolve Plugin Conflicts

This WordPress-specific advice is based on the reality that a lot of site owners install plugins that they never update or even use. Considering the third-party nature of these bits of software, it should be no surprise that they don’t always play nice together — they weren’t intended to. If your WordPress website is slow or buggy, one of the first actions to take is to uninstall any plugins you aren’t using. After that, turn what’s left off one at a time and check site speed. There’s a good chance you’ll find one of the culprits to slow loading.

Final Thoughts

The state of technology today is such that people expect (even if it’s not a reasonable standard) a website to load in three seconds or less. A clean, fast-loading experience will go a long ways towards creating loyal customers and more revenue, which are both good things to shoot for as an online entrepreneur. Keep in mind that the process is iterative. There’s no magic wand that will turn your site into a speed burner. Small actions taken methodically, such as the ones described, should, over time, move you incrementally closer to that three second target. Good luck and thanks for reading.

Photo of Gary Stevens

Member author Gary Stevens is a front end developer. He’s a full time blockchain geek and a volunteer working for the Ethereum foundation as well as an active Github contributor.

The post 6 tips to turn your slow loading website into a brisk browsing experience appeared first on Web Professionals.

View full post on Web Professional Minute

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Inspecting Security and Privacy Settings of a Website

Inspecting the Content Security Policy of a Website

Starting in Firefox 41, Mozilla provides a developer tool that allows users to inspect the security settings of a website. Using GCLI (Graphic Command Line Interface) a user can inspect the Content Security Policy (CSP) of a website. CSP is a security concept that allows websites to protect themselves against cross-site scripting (XSS) and related attacks. CSP allows website authors to whitelist approved sources from which content can be loaded safely. Browsers enforce that Content Security Policy header and only allow whitelisted resources to be loaded into that website. The CSP inspection tool » security csp lists all whitelisted sources.

The main intention behind CSP is to protect websites against XSS attacks, but the protection needs to be deployed in a way that allows support for legacy code on these sites. For example, the keyword ‘unsafe-inline’ was originally introduced to support legacy inline scripts while transitioning sites to use CSP. This keyword whitelists all inline scripts for a site, but it also allows attacker-injected scripts to execute, making CSP ineffective against most XSS attacks. Hence, the CSP devtool not only lists all whitelisted sources, but also provides a rating for each whitelisted source, to indicate the level of protection.

Inspecting the referrer policy of a website


Starting in Firefox 43, Mozilla exposes more website privacy settings and also allows users to inspect the Referrer Policy » security referrer. The referrer policy allows websites to exercise more control over the browser’s referrer header. Specifically it allows website authors to instruct the browser to strip the referrer completely, reveal it only when navigating within the same origin, etc. The referrer devtool provides an example of what referrer will be used when visiting different websites, allowing the user and developer to inspect what information is sent when following a link.

Inspecting the Content Security Policy as well as the Referrer Policy is only the starting point to providing end users with more feedback about the security and privacy settings a web page uses. We hope to add more tools in the future to give users more transparency and control over the security and privacy of the websites they visit.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)

Embedding WebRTC Video Chat Right Into Your Website

Most of you remember the Hello Chrome, it’s Firefox calling! blog post right here in Mozilla Hacks demonstrating WebRTC video chat between Firefox and Chrome. It raised a lot of attention. Since then we here at Fresh Tilled Soil have seen a tremendous amount of startups and companies which have sprung up building products based WebRTC video chat technology. Tsashi Levent-Levi who is a WebRTC evangelist has been interviewing most of these companies on his blog, the list is quite impressive!

WebRTC chat demo

Much like most of early adopters we have been playing around with WebRTC for quite awhile now. We have of course created our own WebRTC video chat demo and have also very recently released WebRTC video chat widgets.

The widgets work very simply, anybody can take the following HTML embed code:

<!-- Begin Fresh Tilled Soil Video Chat Embed Code -->
<div id="freshtilledsoil_embed_widget" class="video-chat-widget"></div>
<script id="fts" src="http://freshtilledsoil.com/embed/webrtc-v5.js?r=FTS0316-CZ6NqG97"></script>
<!-- End Fresh Tilled Soil Video Chat Embed Code -->

and add this code to any website or blog post. You’ll see the following widget on their website:

From here it’s dead simple to start a WebRTC video chat, just make up a name for a room, type it in and click start chat. Tell the other person to do the same and you’re all set.

As always make sure you’re giving this a try in Firefox Nightly or the latest stable build of Google Chrome. If you are on a tablet make sure you are on Google Chrome beta if you are using the Google Chrome browser.

Something else to note is that for this first version our video chat is limited to just two participants per a room. If a room name is occupied by two people the third person who tries to connect to this room simply won’t be able to connect.

How It Works

Without getting too deep into the code behind how WebRTC video chat actually works, let’s briefly go over what is actually happening behind the scenes when you click the start chat button and how WebRTC video chat actually works. Here is a step by step timeline of what actually happens to give you a better idea:

A quick note about this step: “Once remote media starts streaming stop adding ICE candidates” – this is a temporary solution which might result in suboptimal media routing for many network topologies. It should only be used until Chrome’s ICE support is fixed.

A quick and very important tip to remember when you are trying to get this to work. We used a ‘polyfill’ like technique as shown in this article by Remy Sharp. As Remy describes we wrote a piece of code to adapt for the Firefox syntax to get cross-browser functionality.

Issues We Ran Into and How We Solved Them

As you might expect we ran into a number of problems and issues trying to build this. WebRTC is evolving quickly so we are working through a number of issues every day. Below are just some of the problems we ran into and how we solved them.

PeerConnection capability in Google Chrome

While working with the new PeerConnection capability in Chrome we discovered a strict order of operation for it to work; more specifically:

  • Peers must be present with local streaming video before sending SIP (offer/answer SDP)
  • For ‘Answerer’; Do not add ICE candidate until the peer generates the ‘Answer SDP’
  • Once remote media starts streaming stop adding ICE candidates
  • Never create peer connect for answerer until you get the ‘Offer SDP’

We fixed it by handling those issues and handling the connection in the order described above. This was crucial to making the connection work flawlessly. Before we did that it would work only every once in a while.

Added latency due to lag

When streaming to a mobile device there is added latency due to lag and limitations of surfing the net via mobile phone.

We solved this by making the resolution of streamed video reduced via a hash tag at the end of the URL. URL can optionally contain '#res=low' for low resolution stream video & '#res=hd' for HiDefinition streaming video as an optional URL parameter. A quick note here that other configurable properties are now available such as frames per second which you can use for this same purpose.

Recording the WebRTC demo

We’ve been dabbling with recording video WebRTC demo. When recording video we used the new JavaScript type arrays to save the streaming data. We quickly discovered that it is only possible to record the video and audio separately.

We solved this by creating two instances of recording, one for the audio and one for the video, that utilized the new javascript data types and recorded both streams simultaneously.

Conclusion

It’s exciting to dabble in this stuff, we love WebRTC so much that we created an entire page dedicated to our experiments with this technology and others which we believe will transform the web in 2013. If you have any question please give us a shout.

View full post on Mozilla Hacks – the Web developer blog

VN:F [1.9.22_1171]
Rating: 0.0/10 (0 votes cast)
VN:F [1.9.22_1171]
Rating: 0 (from 0 votes)