Today many websites have voluntarily taken themselves offline or censored themselves to drawn attention to and protest two pieces of potential legislation currently under consideration in the United States. SOPA and PIPA are complex pieces of legislation which have a number of provision and I encourage people to read more about them to understand their composition and implications. They have gone through multiple revisions which have added or removed various provisions and are still in a state of flux. Also, exactly what measures are or are not in each bill, and it what form they have been modified to, are not entirely clear.

Broadly, these pieces of legislation do several things. First, they provide a mechanism to create a blacklist of websites which contain copyright infringing content. Network operators and Internet service provides in the United States would be required to prevent access to these sites. Additionally, there is a separate provision restricting websites from linking to websites on the blacklist. These pieces of legislation also provide a mechanism for copyright owners to notify payment processors like banks or credit cards about an offending website and ask that the payment processors not do business with those offending sites. Furthermore. there is an anti-circumvention provision which would make it illegal to discuss technical measures which could circumvent the parts of the legislation, such as discussing technology or methods to access blacklisted websites.

While I have strong personal feelings about this legislation, this is not an appropriate venue to discuss them. However, there two aspects of SOPA and PIPA which directly impact Zoompf’s business and are of great concern. This post is to discuss those issues and why Zoompf, as a company, is against SOPA and PIPA.

Safe Harbor Provisions

Zoompf’s technology works much like a search engine. We crawl a website, copying and storing its contents in various forms, analyze it, and generate reports containing that content or links to that content. A customer or someone using our free performance scan can use Zoompf to analyze a site containing illegal copyrighted material. Zoompf would then have a copy of that material and make some of that content available in various forms.

Currently, Zoompf is protected from liability for copyright infringement done by Zoompf users under the safe harbor provisions of the Digital Millennium Copyright Act (specifically title 2, the Online Copyright Infringement Liability Limitation Act). Other companies such as Google and even hosted blogging solutions like WordPress.com are also protected from the infringing actions of their users by these safe harbor provisions. However, both SOPA and PIPA alter these safe harbor protections. Zoompf’s liability potentially increases. Additionally, the review process which we would need to go through to resolve copyright infringement disputes would change. The exact changes to the process and their ramifications are still vague and have not been addressed by SOPA or PIPA. At this time the process appears to be much more onerous, difficult, and expensive. This is a great concern to Zoompf as it potentially increases our liability for the actions of our users while simultaneously replacing a known and proven path to resolve disputes with an unknown, unproven, and more costly path.

Definition of Foreign Website

SOPA and PIPA are only applicable to "foreign websites" or "foreign companies." This seems to make Zoompf objections moot as Zoompf Incorporated is a US company. However the definitions of "foreign websites" or "foreign companies" in these bills are not clear. For example, Zoompf runs on top of and serves content from data centers in other countries such as Germany and Singapore. These are isolated from the US in that only customers in EMEA and APJ uses these systems and content from websites scanned in those areas is not placed on Zoompf assets in the United States. Are those "foreign websites?" What if our web interface is served from one country and our database is in another? Is it a "foreign website?" It is not clear at what point, if any, a US company operates a "foreign website."

Additionally, as part of our expansion into new markets in other countries, it may be advantageous for Zoompf to create foreign subsideraries inside those countries to do business. Is a subsiderary in a foreign country wholly owned by a US company considered a "foreign company" under the provisions of SOPA and PIPA? According to our lawyers this is not clear.

Actions taken by Zoompf

Zoompf is concerned about how SOPA/PIPA alters the protections Zoompf currently enjoys under the safe harbor provisions of the DMCA. Zoompf is also concerned about how a law that targets "foreign" assets and entities applies to us as we host more and more of our computing and storage assets around the world and as we expand into other countries and new markets.

Since Zoompf is based in Atlanta GA, we telephoned both our senators: Sen. Johnny Isakson (202-224-3643) and Sen. Saxby Chambliss (202-224-3521). Both are co-sponsors of the PIPA bill in the Senate. We also telephoned Rep. Tom Price (202-225-4501) who represents our congressional distinct.

In each case we spoke with a receptionist who said they were receiving an overwhelming response about SOPA/PIPA. They asked us our information and what our concerns were. We calmly explained our specific issues with the bills and asked if there was any information about how the member of congress planned to address those issues.

Sen. Chambliss’s office said he was strongly reconsidering his position on PIPA in light all of the opposition and potential negative ramifications of the bill which had not been considered. Rep. Tom Price has not taken any public position for or against SOPA and was listening to his constituents to understand their views before taking a position. Sen. Isakson’s office did not say what the congressman was going to do to address the concerns.

That is Zoompf’s position on SOPA/PIPA. While it is still unclear what will ultimately happen we are hopefully that both SOPA and PIPA will be defeated.

This the first post in Zoompf’s Lose the Wait series, where we provide tips, tricks, guidance and encouragement to help you lose the wait and optimize your websites for maximum speed. The wait/weight homonym isn’t just us being clever. According to the excellent HTTP Archive, more than any other factor, the total amount of data transmitted for a webpage has the highest correlation to its page load time.

This makes sense. The more data that the browser has to downloaded, the longer a webpage will take to load. So by losing kilobytes of page weight you can truly lose the timing wait.

Measuring Page Weight

When I say “page weight” I mean the size, in bytes, of all the content which has to be downloaded to view a webpage. This means the base HTML file, any CSS, JavaScript, Images, web fonts, Flash, and anything else that needs to download to render the page. Reducing the size of this content will help us reduce page load time.

Of course, you cannot improve what you can’t measure. Having a quick, clear, and reliable way to calculate and visualize page weight is an important first step on our optimization path. Surprisingly most performance tools don’t do this very well. WebPageTest and Zoompf WPO will tell you the basic information like total page weight, but they do this as a byproduct of their performance analysis. This means you are going to have to wait 30 seconds or more while they scan your website to get page weight information. YSlow‘s “Statistics” tab is better since it provides content size grouped by resource type in addition to total page weight. However you still have to conduct run a YSlow analysis, which can be slow (don’t use YSlow’s autorun feature, it pretty much ruins Firefox’s performance).

We need something that allows us to dive even deeper into page weight data and something that is fast. For that we can use super awesome View Dependencies add-on for Firefox.

View Dependencies adds a “Dependencies” tab to Firefox’s native Page Info dialog. View Dependencies shows size of web content and groups them by usage, not content type like YSlow. This is very helpful as images used as a CSS background are separated from regular images. This helps you to track down resources that aren’t referenced properly and are not served from a static, cookieless domain.

Groups of responses are then organized by the hostname that served the response, allowing you to quickly identify servers which are bloated and need further investigation. View Dependencies also rolls up the number of requests for a specific resource type or requests to a specific host.

Best of all, View Dependencies is fast. Since it hooks into Firefox’s existing Page Info dialog, it doesn’t need to scan or re-request any resources. The only thing separating you from this wealth of data is how quickly you can get that dialog box open! Sadly, modern Firefox no longer has a native keyboard shortcut for Page Info like it has CTRL+U for View Source. The easiest way to get to the Page Info dialog is to right-click on the current webpage and select “View Page Info” from the context menu. There is also an add-on, Page Info Button, which places a button on Firefox’s toolbar which opens the Page Info dialog. This add-on also implements a keyboard shortcut CTRL+I which will open the dialog as well.

The Often Forgotten Transfer Weight

Page Weight isn’t the only thing we have to worry about. The bytes of the response body aren’t the only thing that gets sent to a visitor’s browser. HTTP itself adds weight in the form of request and response headers. HTTP response headers appear on every response, even empty responses. HTTP headers are also verbose text headers which cannot be compressed the way response bodies can be. HTTP header weight can really add up. Artur Bergman of Wikia and Fastly fame recent tweeted that they send nearly a terabyte of HTTP headers every day.

Clearly our Lose the Wait fitness plan will need to examine how we can lose some of this transfer weight.

Page Weight/Transfer Weight Fitness Plan

Over the next several posts, Zoompf plans to explore in great technical detail ways to reduce both response weight and transfer weight. Think of it as your fitness plan to reduce your wait by losing some the weight.

To some people that might sound very boring or redundant or even too elementary. You might be thinking: “OK. This is basic stuff. I already know how to reduce the size of content. A little HTTP compression, some minification, a bit of Closure compiler, some Smush.it, and I’m done”.

While this might be true, we often find that there are aspects of even the most basic optimization that people overlook or think they already know. For example, most people know that HTTP compression should be applied to text resources. But people often forget that “text resources” means more than just HTML, CSS, and JavaScript. XML and JSON API responses, Robots.txt, sitemaps, and HTML5 manifest files are all examples of text content which should be served with HTTP compressed but usually isn’t.

In fact, saying HTTP compression should apply to “text resources” isn’t the entire picture either. HTTP compression should apply to any non-natively compressed resource. SVG and ICO files are good examples of this. They are images so people think they don’t need to be compressed. But SVG and ICO are not natively compressed. SVG is just XML, and ICO is a primitive form of the uncompressed BMP file format. Both of these should be served with HTTP compression. Cursor files are another example. Various other binary files and formats are not natively compressed as well.

To ensure that you are fully optimizing your site, Zoompf is publishing a series of posts exploring different ways to reduce page weight and transfer weight as part of a Lose the Wait fitness plan. Below is a current snapshot of the topics list we plan to write about over the next few weeks:

• HTTP compression (and doing it right)
• Optimizing HTTP headers
• HTML optimization (removing and refactoring structure)
• HTML minification
• CSS minification (and why all the tools suck)
• JavaScript compilation and minification
• Traditional lossless image optimization
• Intelligent lossy image optimization

Make sure to follow Zoompf on Twitter and subscribe to the Lickity Split Blog RSS feed so you don’t a post in our Lost the Wait series.

Happy 2012! It’s a new year and that means people make New Year’s Resolutions to change something about their life for the better during the coming year. This year, Zoompf asks you to make another New Year’s Resolution: Lose the Wait.

That’s right, start the year off right by promising to Lose the Wait of your website by improve its performance. This just won’t make your life better, promising to Lose The Wait will help make everyone happier:

• Your visitors will be happy. A fast website leads to happy, engaged visitors who are more likely to do business with you.

• Your IT Ops folks will be happier. A more efficient website reduces server load and allows them to do more with their existing resources.

• Your CFO or VP of Finance will be happier. Optimizing your website reduces operational costs like bandwidth, and there is no better gift to a financier than reducing costs (except perhaps more money, see first bullet).

Now I know what your thinking. You’ve made New Years Resolutions in the past and they didn’t work out. Or your made some progress towards your goal but it didn’t last. well fear not! This time around is different because Zoompf will be there to give your the guidance and encouragement so you can you finally Lose the Wait permanently. To do help you build faster sites Zoompf is starting a new series of blog posts, webcasts, white papers, and workshops entitled Lose the Wait!

If you really make to change your website’s performance for the better, if you are sick are tired of your slow and bloated site, if you are finally committed to Losing the Wait, Zoompf is here to help you achieve it. We start next week, bright and early so make sure to follow Zoompf on Twitter and subscribe to the Lickity Split Blog RSS feed so you don’t miss a step.

Image by puuikibeach