Posts tagged HTML
Amazon Really Knows How To Press My Buttons
Apr 16th
I have to deal a lot with buttons at Amazon. They can sometimes cause quite a bit of irritation at work, so I decided I wanted to try to change it. Here is the proposal I wrote up for Amazon, but sadly I don’t think anyone has read it, and worst I need approval to make a change. Let me know what you think, or if you have seen similar struggles at other companies.
Amazon Buttons
The Problem with Buttons
The button making process is quite tedious at Amazon. Our buttons are image based, so every new button or change to a button needs to be created by our designer. There are many different events during a project that give our designer work of creating buttons. Our designer usually creates buttons at the start of a project, and then might add or change buttons when business requirements change throughout the project. He will also create buttons for the different locales that our project will deploy. Our team has 6 different locales and 2 have multiple languages. And generally he will make additional buttons when strings get mistranslated. For the most recent project of mine our designer has had to make 23 buttons. This causes a lot of extra work for the designer and a lot of unnecessary downtime for the developer as he waits for new buttons. There is also a high chance of error with this process. It’s very easy to forget to upload a new image for a button in our less viewed locales, or forget to update an alt attribute when the button changes. Our buttons are often inputs elements and inputs where the type attribute is equal to “image” don’t function the same across all browsers. IE will not post the name of the input to the server where other browsers do.
The Proposed Solution
I propose we fix this button plague. Instead of having our designers create button after button, they won’t create any. How? By making the button text based. Instead of having the text in the image, it will come from the HTML. The look and feel for it to be a button will be done with CSS and one sprited image for the different types of buttons.
Pros
Eliminates Cross-browser Issues
The inputs can now be of type submit or button (whatever is needed for the page) which will eliminate the cross browser issues when it was of type image.
Localization
Because the text in the HTML is what is shown to the user, we won’t have the potential of our alt attribute being incorrect. We also eliminate the potential of forgetting to upload or change images on the media server. We didn’t eliminate that we might forget to change the string in some random locale, but at least now it’s more visible to spot a mistake like this.
Time (Designer and Developer)
By removing the designer as the button creator we save significant development time. In addition to the designer just not spending time creating buttons, the developer no longer needs to fill out keystones for buttons, or wait for the button’s creation.
Performance
Using text based buttons also has performance gains. Let’s look at the gift card ordering page as an example. There are 11 buttons that are downloaded on page load. Not only do these images add a lot of weight to the page they cannot be download in parallel. For the majority of our user’s browsers; only two images can be downloaded in parallel from the same host (all 11 images are from the same host). With the text based button there are only 2 requests instead of 11; one for the CSS and one for the image sprite. The CSS will get bundled with other CSS on the page so there is actually only 1 additional request instead of 11. In addition the CSS, HTML, and image sprite, needed for a text based button is much smaller than a full button image. As a test I created a page with 11 text based buttons, and compared it to a page with 1 image based button from the gift card order page (the “proceed to checkout” button). The total size of the text based buttons was 20% smaller than that of the imaged based button. My test page was neither full featured nor optimized, but expect similar results when it is.
Test page with 11 texted based buttons
The total size for all components is 2.4K. It has 3 components which are the doc a css file and one css image.
This test page just has one image from the order page
The total size for its components is 3K
Cons
Fonts
Now this method isn’t perfect. The font on the image based buttons is Frutiger Condensed. This is not a standard system font which means we must use other fonts to mimic the look and feel. Although we can get a very close looking font it won’t be perfect. There is the possibility of using @font-face to load the needed font to the browser, but there is a performance cost.
Text Based Button Imaged Based Button
A Look at HTML Minification for Amazon
Feb 25th
If you take a look at any HTML source of an Amazon page you’ll notice that there is a ton of extra whitespace. This has been puzzling me for a while. It is important minify our JavaScript and our CSS, so shouldn’t we also minify out HTML? (Just as a note, if you look at Amazon’s CSS today you’ll notice it’s not minified, but I think I’ve convinced them to change this.) I asked one of my coworkers on our latency team about why we don’t minify the HTML. He told me they didn’t feel it was worth it because whitespace gets compressed really well. I was a bit skeptical about his conclusion so I took a deeper look to see what the potentials of HTML minification are.
I took a small sample of Amazon pages (the same ones I’ve used for my other posts) and tried to remove the extra whitespace. I went to each page and saved the HTML document to my hard drive. I then ran the tool “HTML Compressor” on the doc. Although “HTML Compressor” has a fancy name it only removes whitespace. The one problem with this tool is it will also removes whitespace from whitespace sensitive elements like a PRE tag. Luckily I didn’t see any whitespace sensitive tags, so I think it did exactly what I wanted for this test. On average I saw a 5% decrease in the file size once gzipped. The pages ranged from a 3.47% to 6.69% savings. I also looked at what the savings were on the raw file, but I decided to focus on the gzipped version, because that is what the user received. I thought 5% was a pretty good amount a savings for such a giant company. I’m not really sure why they decided it wasn’t a big enough win when they originally looked into it.
Removing whitespace is good, but there are many more optimizations we can perform on our HTML. Luckily for me Page Speed has a lovely new feature that will allow us to minify our HTML with more advanced optimizations. I did the exact same experiment with the same pages and compared my results. This time I saw an average of 10.25% savings once gzipped. The range for this one was 7.47% to 12.07%. Interestingly the savings for removing only the whitespace was about half, when compared with Page Speed. Here are my results.
http://spreadsheets.google.com/pub?key=tjKHbaZ3gf9PRJdgMY1JAlg&output=html
Unfortunately even though Page Speed showed some great improvements I can go praising it quite so soon. Although the page was smaller it actually broke things. Here’s a look at the three different pages.
Amazon.com with whitespace only minification
Amazon.com with Page Speed minification
As you can see the page that had Page Speed minify it is completely broken. I dived a bit deeper to see if I could figure out why. It looks like Page Speed is struggling with HTML comments embedded in script tags. In earlier browser a developer would have to add <!– //–> around their JavaScript. This was needed so that browsers without JavaScript would just ignore the script and move on. <!– //–> is no longer needed and can be removed from all scripts tags. Page Speed seems to be keeping the first part(<!–) of the comment in the HTML, but removing the second part(//–>)(at least sometimes). This is causing a lot of extra HTML to be placed inside the script tag. For example the link tags for the CSS are stuck in this script tag instead of the head causing none of the CSS to be loaded to the page. Luckily there’s an easy fix. Just remove the <!– //–>. It’s not needed and will work exactly the same in all modern browsers (Yes that includes IE6). By removing these comments from the page before running Page Speed, it gave me a working and minified page, as you can see here.
http://gregthebusker.com/Amazon/amazon-com-comp-edit.html
Page Speed did a great job, but I noticed that there was a bit more it could do. They can remove comments. The amazon.com page has comments in more places than just the script tags. Style tags for example but I’m not sure why. And just like the other comments they are not needed in the HTML, so might as well get rid of them. I also noticed it wasn’t combining adjacent script or style tags. If two style or script tags are next to one another might as well combine them into one, all you have to do is make sure to preserve order. Has anyone else played with Page Speed’s HTML minifier? What else could they be doing?
