blog

New static website theme

demo website template

I have a need for speed, well speedy websites anyway. My goal is to build a bunch of super fast website themes that I can base my future work on, so here’s my first attempt. It’s a lightweight, responsive static website theme.

The entire website CSS is only 1.67 KB and the JavaScript is only 485 bytes gZipped! I’ve set up a demo version on my staging website and it runs like a scalded dog. 🙂
You can download the files on Github.

Putting Your CSS Framework On A Diet

I’ve worked on a couple of projects now that use Bootstrap. I like Bootstrap for prototyping, it’s quick and easy. However, I don’t care for the weight especially in public facing projects. Analyzing one Bootstrap project that I’m putting on a diet has a final stylesheet of 150k and over 3,000 unused classes (ouch).

Mobile users and users in rural areas with poor internet connections may be clients and customers. Getting users content delivered fast is crucial, well if you want to stay competitive. I believe speed is king and a couple of tools I’ve started investigating to speed up the projects are…

PurifyCSS and UnCSS, both of these tools are used with a task runner like gulp or grunt their basic mission is to strip out all unused classes. I’m not real clear about the dynamic classes yet. I guess this is another reason to prefix classes tied to JavaScript with “js-” or hey target the data-” attribute instead. Regardless I’m hoping one of these will slim the CSS down.

Browser Support

I’m finally getting settled (or kinda settled) into having a new baby in the house and I hope to get back into a routine of writing. I am really enjoying experimenting with some of the new features of HTML5 and CSS3, however, sometimes it doesn’t work well with older browsers and I wonder about the new feature support.

If it were just me I wouldn’t be concerned about browser compatibility, but I have to buy diapers by the truckload. And working for me doesn’t buy diapers or even wipes, so when I’m working for others I try supporting the latest browsers and I like to stay compatible with 2 previous browser versions. I just came across this website, and it seems to be a pretty good resource when checking for browser compatibly issues http://caniuse.com/.

Setting Media Query Breakpoints

I am a big fan of using analytics to make informed decisions and it is an important tool in determining break-points in CSS media queries. In Google Analytics you can check those by visiting…

Audience > Technology > Browser & OS > Screen Resolution

I look through the top 100 resolutions and make sure there isn’t anything out really wacky, like a trend in huge or small screens, then design for the most common devices and that will also depend on the goals of the website. I group the most common resolutions together in the breakpoints using “max-width” and “min-width” in the media query to save time. There’s a popular saying about designing for mobile first, I don’t believe that is necessarily true, I’m always going to design for the user first. There are a lot of factors to consider when determining the breakpoints for the design, but the user, content, readability, and usability should be at the forefront when making those decisions.

On side-note resolutions change all the time and it’s a good idea to check these periodically. Below are the top 20 screen resolutions for one of my websites. 1366 x 768 has held the top spot since 2012, before that it was 1024 x 768. With smartphones and tablets outpacing computers to access the internet it will be interesting to see what resolutions will be in the top 20 in a few years. Regardless of resolution or device, its a safe bet to design user first.

  1. 1366×768 – (25.94%)
  2. 1440×900
  3. 1280×800
  4. 1280×1024
  5. 1600×900
  6. 1920×1080
  7. 1024×768
  8. 320×480
  9. 320×568
  10. 768×1024
  11. 720×1280
  12. 360×640
  13. 1680×1050
  14. 1280×720
  15. 1093×614
  16. 480×800
  17. 1536×864
  18. 1301×731
  19. 1360×768
  20. 1438×808

HTML5 Responsive Images and CSS3 Image Flipping

It’s hard to have a responsive website without responsive images, I usually use the HTML5 figure “figure” or the aside “aside” tag for responsive images. In your CSS just assign your width, max-width and/or min-width to the tag.

In the code below, the image below will not exceed 800 pixels wide or get smaller than 300 pixels wide.

figure{min-width:300px;max-width:800px}
figure img{width:100%;}

Using CSS3, we can also flip images horizontally without the use of an image editor or JavaScript.

aside img{
-moz-transform:scaleX(-1);
-o-transform:scaleX(-1);
-ms-transform:scaleX(-1);
-webkit-transform:scaleX(-1);
transform:scaleX(-1);
}

Check out the demo here, be sure to resize the browser window.

Real World Speed Test

In my quest to build the fastest website possible, I stay busier than a Colorado Taco Bell employee working the late shift. I have several methods of testing website speed; one of the automated tests I like to use is Google PageSpeed Insights.

In following their recommended techniques, websites will get a lower grade for using an external style sheet (if the style sheet is small). Therefore, I started testing inline styles as opposed to an external style sheet. I realize there are many different variables in determining the speed and my test are not the most scientific, but if you look at “exhibit A”, the page with the inline styles is over 100 milliseconds slower than “exhibit B” which is using an external style sheet. However, by using an external style sheet, the site loads faster in the real world, so I believe I am going to stay with the external file on my website for now.

I am using Typekit for my web fonts and that also brings down the score, but I am thinking it is still faster than using images, not to mention the time it takes to develop and optimize the images. I believe speed is king and it will always be a factor on the web. With the percentage of mobile web surfers climbing it will be even more of a factor. In the end, using automated tools for testing is good, but using common sense and real world test will always be a better solution.

3 reasons I like using SASS

I started using SASS a few months ago and feel like I have just scratched the surface of this new approach to CSS. I was hesitant to start using SASS, at first I thought it ran on the server and was like a type of middleware, and I would have to learn another scripting language. However it’s not middleware, and I didn’t have to learn anything new to start using SASS. I’m using a nifty tool called compass.app it’s easy to use and here are 3 reasons I will continue to use SASS.

Helps keep my development files organized.
I’m a speed freak; I like fast websites and will try to squeeze every last byte out of a file. By using SASS, I can keep comments in the production file, and it compresses the final CSS automatically. I used to use PHP to strip out the end-of-line breaks and comments and maintain 2 files, not anymore.

Variables and Mixins
Defining variables and mixins saves me time. No more find-and-replace, which isn’t too bad until you start working with multiple files.
Having the ability to use @import and break the CSS into multiple files allows several developers to work on different areas of the site without running into one another. I’m using the @import to pull in my reset, and form stylesheets and to test my CSS 2.1 files before I use the CSS 3.