I’ve written more on cache behavior, and Live HTTP Headers is a great way to learn about HTTP caches (something every webdev should be interested in for performance reasons).Įven better, you can “replay” any header, editing the data that is sent. If items are cached, the browser may not request them at all (awesome!) or may request the element and get a 304 “Not Modified” response (slightly less awesome, you still had to check with the server). I know these questions keep you up at night, so here’s what you can do:Īs you visit a page, you’ll see HTTP headers fly by as your browser requests elements. What cache headers is my site sending back? Are my pages really gzip-encoded? Sometimes you need to dive into the nitty-gritty. Not satisfied? Check out the examples on the home page. If you are a more visual person, try this awesome collage: If you must optimize, optimize the common-case first.
You’ll get a report of where your code spends its time. Click “profile” to begin capturing information, do some commands, and then click stop. Profile Button (on Console Tab): Find the run-time performance of your page.
Net Tab: Find the download performance of your page. You can then hit the blue “play” button and continue running your app, until the next breakpoint. Reload the page and it will break (pause) when it encounters the line.Īt this point, you can switch over to the console to examine and change variables, and figure out what the heck is going on when your code won’t work. Click on a line number to set a breakpoint (red dot) in your javascript. Play around with your functions, change CSS attributes, add elements to the page - whatever it takes to test. You may have to enable it for the page.Ĭonsole Tab: Write quick javascript commands - it even has autocomplete on variable names and properties.
If you love yourself you will install it immediately and save countless hours of frustration.įirebug can debug javascript, examine the DOM, and do much more (you can and should read all about it). Keeping Javascript In Line: Firebugįirebug, how I love thee (or get the bookmarklet for other browsers). This is way faster than taking a screenshot and opening it up in Photoshop. This is great when designing, and you want to match a font color to a color in your page. I’ve found this very effective for editing CSS, you avoid the constant back-and-forth switching because Firefox now has a CSS editor.ĬolorZilla gives you a dropper that can find the hex RGB value (#123456) of anything on the page.
You are viewing the live file in Firefox, making changes, and copying those back into your text editor. It’s almost the reverse of creating a file in DreamWeaver and viewing it in Firefox. Select all the text in your edited CSS file and paste it into the real CSS file. The CSS won’t be valid so the border is ignored, but keeps the style around in case you want to enable it later. Play with widths, heights, margins and paddings until it lines up nicelyīut rather than deleting the border, put an “x” in front: “xborder: 1px solid red”.
Find a div with your mouse (ctrl + shift + f).I’ve done the following hundreds of times during the course of web development: My favorite CSS style is border: 1px solid red You can edit any attributes and see the effect in real-time (like giving Google a black background): This pops open a sidebar tab with the current stylesheets. Figure out how big an image is (pixel height and width)Ĭtrl + Shift + E: Edit CSS.Easily get the div’s id for use with Firebug (below).Figure out what classes are creating the styles you see.Move the mouse over an element and its attributes appear in a pop-up: the name, class, pixel sizes, fonts, everything. It can do a heck of a lot more, but here’s what I use it for:Ĭtrl + Shift + F: Display element information. The Web Developer Toolbar lets you inspect and edit (in real-time) the HTML and CSS of your page, so you can see what’s happening when things don’t line up. Just do it.ĭebugging CSS can be really frustrating. Here’s a rundown of the Firefox extensions I use to manage this madness. You have to deal with browser inconsistencies with HTML, CSS and javascript, let alone the difficulty of debugging javascript itself. Debugging is one of the most painful parts of developing web apps.