The Digg Bar is the most obvious (and noxious) example, but the new trend of URL shorteners coupled with a URL hijacking frame is spreading alarmingly. More and more I’m seeing this odious technique. These things break bookmarks, wreck navigation cues from the URL and are generally sleazy and rude.
And there’s how to beat them. Insert this code in the head of your document and frames will disappear:
I’m going to be posting a series of notes on the production of my first HTML 5 demo page. I’m doing a presentation on it at work (to be shared here, of course) and I want to capture my thoughts as I have them in the process of producing some fully formed HTML5 content.
One of the things I’m looking at with interest is the new Video element. Anything that simplifies embedding video on a web page gets a thumbs up in my book. Read the rest of this entry »
The difference in speed between my day job and the after hours hacking I do is sometimes mind-boggling. My day job is a typical “day job”. Anything of note takes time to happen. I’m cool with that.
I’m also cool with what happens at home. Where I can get an idea, hit Google for some quick research and get on with the business of making it happen.
As I recently mentioned (on Twitter, does that really count?), I’m not a fan of URL shortening services. I don’t like the idea of trusting the value of links pointing to my sites to a third party. Especially since the URL shortening space itself is so sketchy. With that in mind, it was with interest that I read about the “shortlink” relation. It’s basically a scheme set up to instruct browsers and applications on the proper “short” URL to use for a document. There’s actually a competing, but similar “shorturl” specification floating around out there as well.
Whichever one wins, I approve of the concept. I want to own my own short URLs. I don’t want any Digg bars framing my site, or sneaky, link-juice stealing redirection schemes. Read the rest of this entry »
I finally finished reading Even Faster Web Sites. It’s good, but in terms of things for my day to day, it’s kind of a mixed bag. In some ways (specifically in the areas of JavaScript efficiency, image compression and CSS selectors) it’s more practical than High Performance Web Sites and in others I had a hard time coming up with a concrete example that I’d actually run across that would be served by the topic at hand.
With that in mind, looking at the table of contents I found the bolded chapters most interesting for my day-to-day coding (your mileage may vary, of course)
Chapter 1. Understanding Ajax Performance
Chapter 2. Creating Responsive Web Applications
Chapter 3. Splitting the Initial Payload Chapter 4. Loading Scripts Without Blocking
Chapter 5. Coupling Asynchronous Scripts Chapter 6. Positioning Inline Scripts Chapter 7. Writing Efficient JavaScript
Chapter 8. Scaling with Comet Chapter 9. Going Beyond Gzipping Chapter 10. Optimizing Images
Chapter 11. Sharding Dominant Domains Chapter 12. Flushing the Document Early
Chapter 13. Using Iframes Sparingly Chapter 14. Simplifying CSS Selectors Appendix A. Performance Tools
Which isn’t to say that the other chapters weren’t interesting. They were, I just don’t need to deal with some of the issues solved by those techniques very often in my day job. That was especially true of the the Comet chapter and many of the issues related to managing multiple script files and/or large blocks of JS code.
In this webinar, you will learn how Amazon CloudFront can improve the performance of your website and cost you less than a traditional content delivery service (CDN). Amazon CloudFront is an easy to use, high performance content delivery service that lets you quickly and cost-effectively deliver website content to your users using a global network of edge locations in the United States, Europe and Asia.
You will learn how Amazon CloudFront is different from most traditional CDNs and how easy it is to get started.
I use CloudFront at both home and work and love it. It’s cheap and performs as advertised. Low-latency, high transfer speeds, rock solid uptime (pingdom has yet to report a problem in nine months) and utilizing edge locations is an obvious benefit (especially to the healthy percentage of visitors my personal site has in Europe.) So, if you’re at all interested maybe the above will be just the thing to get you started.
Why bothers? Well, for performance geeks it’s the easiest way to clear Yahoo’s performance rule #2. Don’t you want to be a cool performance geek?
As it stands, I’m always storing bits of data in globally accessible places (either in the DOM or in a namespaced Data object,) and I always have to document what I’m doing so having a standard place to park data is great.
The fact that it stretches across an entire session? I love it. Especially since it’s so straightforward when compared with cookies. I hate dealing with cookies. It feels like coding through a time machine. sessionStorage is much more modern. Convenience FTW.
Interested in the ongoing discussion of web fonts (the embeddable, fancy kind?) one of my co-workers, Colin Henson is working on a great series outlining the whole shebang. check out: Web Fonts part 1 and Web Fonts part 2.
We worked together on the redesign of CramerOnline.com where we used Cufon for headers, so it’s very topical around the office.
Quick verdict on Cufon, btw? Slightly tricky, but definitely ready for prime time
It’s with that in mind that the good press Windows 7 is getting should be greeted with great joy by web developers the world over. While many IT departments skipped over upgrading to Vista (I know of what I speak, we use XP at work), the lure of Windows 7 might be too much for them to ignore.