An image-heavy website can be slow to load, potentially driving away impatient visitors. Slow loading can also hurt your search engine rankings, because Google factors site speed into rankings.
In his article, 29 Ways to Speed Up Your Website, Ian Lurie offers good advice on using images without slowing down your site.
Say no to Flash
Most website animation is unnecessary, but if you feel you need it, try:
If you still want to use Flash, do so sparingly; no more than one or two Flash elements on a page.
Use a storage service for images
Most browsers will only load two images from one domain at a time, but will access up to four domains at once. Storing images (and other documents) on a different domain, such as Amazon S3, allows your site to load faster.
Host images on photo sharing sites
Free photo storage sites, such as Flickr or Picasa, make it easy to embed pictures on your site.
Compress images properly
There are two ways to compress images:
Upload the right size image
Large images take time to load, no matter what size they’re displayed at. Use Photoshop or another image editor to reduce the image (and file) size before uploading it.
These few tricks can keep your image-heavy website loading quickly. Read more about how to speed up your site by cleaning up the code.
Bellevue attorneys Gregorek & Associates have assisted the CaseDetails editorial team in identifying topics of importance to readers of this blog.
Did you know that your website code could be slowing down your page loading? Fast-loading pages keep visitors and search engines happy, so it’s worth learning how proper coding can speed up your website.
Ian Lurie explains five coding areas that matter in 29 Ways to Speed Up Your Website.
Clean code: Unfortunately, the code produced by your content management system (CMS) is rarely clean. Learn how it’s supposed to look and then clean it up, or request that your webmaster or designer do this.
CSS (Cascading Style Sheets): Page formatting can be written as HTML, but that gets tedious, repetitive and messy. CSS provides a simple set of style codes to incorporate into HTML documents.
CSS files: CSS belongs in its own stylesheet files (.css files), not embedded in the HTML coding. A simple command, usually in the page HEAD section, tells browsers which .css file to load.
Multiple CSS stylesheets: Your website probably contains a few design elements that are identical across the entire site, and then several different types of pages with varying styles. Create one .css file with the conserved style elements, and then individual files for each different type of page. Finally, instruct each page to load two .css files: The one with the conserved styles and the one with its specific style.
JavaScript files: When JavaScript is embedded in a page, browsers have to download it whenever they open a new page, which takes time. Instead, put it into a .js file and put a command in each page’s HEAD to load it, just like your .css file. Now a browser will download it once and cache it, making subsequent page loads faster.
Even if you use a CMS, learning how to code properly will allow you to make the tweaks necessary to speed up your website and provide a better experience for the potential clients visiting your site.
A Queens auto accident lawyer with Rubin & Licatesi has assisted the CaseDetails editorial team in identifying topics of importance to readers of this blog.
A question that I sometimes encounter: “Is my site optimized for the ______ (Firefox, Opera, etc.) web browser? ” Now, with Google’s Chrome browser entering the fray, it’s bound to spawn a whole new round of the same question. This kind of browser optimization should always be checked but, before you invest hours into re-coding your site to work correctly in Firefox or Chrome, you should know the market share to balance your consideration.
StatCounter.com is a wonderful, free web analytics program that is highly recommended. Who knew they had a blog? Well they do and, in it, they’ve revealed the latest stats on Global Browser Market Share, as it has been claimed by Chrome, Internet Explorer, Firefox, Safari and “Other” top browsers (Flock, Opera, etc.):
IE FireFox Safari Chrome Other
Aug 28, 2008 68.17% 24.66% 2.83% N/A 4.33%
Aug 29, 2008 67.81% 24.78% 2.84% N/A 4.57%
Aug 30, 2008 65.41% 26.38% 3.04% N/A 5.17%
Aug 31, 2008 64.49% 26.91% 3.06% N/A 5.56%
Sep 01, 2008 66.92% 25.26% 2.99% N/A 4.84%
Sep 02, 2008 67.58% 24.36% 2.91% N/A 5.06%
Sep 03, 2008 67.81% 23.54% 2.70% 1.11% 4.87%
Sep 04, 2008 70.87% 21.26% 2.48% 1.15% 4.25%
Very interesting that it’s Firefox and “other” users who presumably compose the 1.15% now claimed by Google Chrome. To me, it indicates first adopters are the only ones using Chrome so far. The numbers for Firefox (at 21.26% on September 4, 2008) are more intriguing… there may be some “techie” skew in the sample set but not much. Chrome’s numbers show us that. At approximately 20% of market share, Firefox has nearly doubled its user base since my recollection of one year ago.
Chrome and Firefox share the same Mozilla browser core, so there shouldn’t be any major difference in the way they render your pages. The message is clear, though, if you have an error in Firefox, you should invest the time and labor to fix it for the sake of 20% of market. If a Chrome-specific error arises, explore what browser optimization would be necessary to fix the issue, but take a wait and see approach for the next few weeks.
Ultimately, if you’re not able to correct a browser-specific issue, a USER-AGENT browser redirect will be necessary with different landing pages for different browser versions.
[Full Global Browser Market Share stats]
An XML sitemap is a simple way to “spoon feed” your page locations and other info (like page importance, update period, etc.) to the search engines. Through the recently-adopted Sitemaps.org XML sitemap standard, one file can serve the top 4 search engines. Most webmasters know about Google Webmaster Central and Yahoo! SiteExplorer, but those XML sitemap submission methods are cumbersome. Here’s the short way to tell search engines about your XML sitemap:
Ask.com:
Google:
Yahoo!:
Live.com/MSN.com is still the odd man out. To submit your sitemap to them, (as per Livesearch.spaces.live.com): modify robots.txt to include a line for Sitemap: <sitemap_location> where <sitemap_location>; is the complete URL of your Sitemap Index File (or your sitemap file, if you don’t have an index file).
My advice, use www.xml-sitemaps.com to create your sitemap, upload it to your root directory and use the methods above to submit!
[tags]XML sitemap, sitemaps[/tags]
You may have read but over the July 4th holiday, Google posted some subtle changes to their algorithm and rankings. I’ve seen a few notes about website age being one of the most noticeable factors in the changes. It’s a long story, but I’ve turned up pretty clear indications that they also rolled another feature into the new algorithm: Google is now indexing project titles and links within Flash SWF files. I’m still testing to see if they’re also spidering text content found inside SWFs but I can say with 99% certainty that they picked up URLs that exist only inside an SWF I previously had online. What do you think?
[tags]Google, algorithm, Flash, SWF[/tags]
The other day, I ran into a law firm with a website coded using the IFRAME element. While there is nothing programmatically wrong with IFRAMEs, they present some significant challenges for search engine optimization.
Here is a definition for “IFRAME” from Wikipedia:
“IFRAME (from inline frame) is an HTML element which makes it possible to embed another HTML document inside the main document… IFrames are more commonly used to insert content (for instance an advertisement) from another website into the current page.”
A few examples of sites using an IFRAME are:
http://www.samisite.com/iframephotos/index.htm,
http://calcium.brownbearsw.com/demos/miniframe.html &
http://www.webmonkey.com/webmonkey/96/37/stuff/iframe_ex.html
From a search engine optimization point of view, the use of the IFRAME is problematic for several reasons. First, whenever a search engine spiders the content that’s within an IFRAME, the search engine will normally link to the IFRAMED page itself instead of the “master” page it is housed within. Often, this means searchers are delivered to a page without site navigation. This is not optimal for keeping the attention of search engine spiders or visitors. A good example of a page like this within Google’s index:
http://www.paxilbirthdefect.com/source/about/prenatal_exposure.html.
Next, if you’re using an IFRAME to display another website’s content within your overall navigation structure, you’re now subject to showing whatever that site may change their content to say. Today’s IFRAMED page about birth control may be tomorrow’s IFRAMED page about a less savory topic. Of course, search engines will recognize you’re serving another site’s content so it will have no positive impact on your site’s rankings.
Additionally, some users turn off the IFRAME element in their browser’s advanced settings because of a the security hole it presents (trusted websites can unwittingly serve malicious content via IFRAMES).
Finally, and this is the most important point, I’ve spotted some sites that have multiple IFRAME “shells” on different URLs that all serve the same framed-in content. In the eyes of the search engines, this is duplicate content and is likely to be reason for de-listing.
If you can’t tell, I don’t recommend using IFRAME in your site’s code. Just like framesets, there was a time for them, but that was years ago. Duplicate content, end-user experience and security concerns are factors I consider to be argument enough.
[tags]IFRAME, inline frames[/tags]
I’ve been messing around with PDF files lately – trying to make sure they’re able to be spidered by (at least) Google. Here’s a crash course in what I found. Using a full version of Acrobat, open the PDF you want to optimize and press CTRL + D. This will open the Document Properties. Within the PDF’s Document Properties, enter in the PDF’s TITLE, Author, Subject and Keywords. Be accurate, be succinct and don’t spam.
The TITLE you set in your PDF Document Properties will show up in Google as the PDF’s link. (Without it, all of your PDFs will be indexed as Untitled.)
What about the rest of the document? Can the search engines read my PDF? Well, the answer is “it depends“. In general, if you open the PDF and can use the text tool to highlight individual lines of copy, it’s going to be indexable by Google. Another way to tell: open the PDF and press CTRL + A to select everything in the document. Then press CTRL + C to copy everything. Go to Notepad and press CTRL + V to paste what you just copied. If real text appears in your open Notepad, it’s searchable.
What about scanned PDFs? If you’re unable to select any text using the Text Tool, it’s likely your PDF is just an image of text — not searchable. What can you do about that? My best advice is to try to use Acrobat’s native OCR feature to convert that image to real, searchable text. Once the OCR has run, it won’t be apparent that anything has happened – that’s because Acrobat keeps that original image “in front of” the converted text. The converted text is now there, but it’s behind the scenes and only readable by “users” like search engine spiders. NOTE: the quality of the OCR is poor. I’ve never had much luck with it. To see what the converted text is, use the CTRL + A trick. This time, it will copy the converted text. When you paste it to Notepad, you’ll be able to see the quality of the results.
To answer the question “Are PDFs Searchable?” the answer has to be… sometimes. Use the tips above to find out if your PDFs can be read as real text. If not, don’t worry, setting the Document Properties will at least let you convey the PDF’s TITLE to the engines.
[tags]PDFs, PDF optimization[/tags]
On some sites I work on, I see the coders have used CSS to format the site’s H1 tags to not show the text but, instead, display an image in the text’s place. This is commonly called the “display:none” trick. The advantage is that it allows you to use an image as a header while, at the same time, keeping the text “version” behind the scenes. Spiders see the text, end-users see the image. Matt Cutts makes it clear Google is watching this “trick”… the biggest thing they’re watching is keyword spamming and multiple instances of the trick.
I’ve recommended a few sites use the trick when a client insists on a crazy font for their content headers but always use real, CSS formatted text in the H1 tag when you can. If you do have to use the display:none trick, make sure what’s inside the H1 tag is pretty well 1 phrase… 3-4 words at most… and reflects the content of the page. No matter what, be careful!
[tags]SEO tricks, h1 tag, CSS[/tags]