Google Sitemaps Zuigt!

Veld Bouwmanagement heeft een nieuwe website, gemaakt door VisualMedia. De website ziet er netjes uit, niets bijzonders op zich. De oude website was al iets meer dan een jaar online en was ook opgenomen in Google. Het is dus een vertrouwde site, zoals Google zelf aangeeft.
Nu werd het natuurlijk tijd dat de nieuwe site ook opgenomen werd in Google. Standaard onderdeel van het CMS van VisualMedia is dat er RSS feeds en een Google Sitemap worden gegenereerd. Deze sitemap is meteen na lancering van de site op 16 oktober toegevoegd aan Google’s Sitemaps tool, onderdeel van de Hulpprogramma’s voor Webmasters (jammer dat daar geen API voor is trouwens). De sitemap wordt dagelijks netjes, zonder fouten, gedownload. Maar heeft het ook enig effect? Nee! De oude versie van de site blijft eigenwijs in de index aanwezig.

Google geeft hierover aan:

Met Google Sitemaps kunt u al uw URL’s op een eenvoudige manier verzenden naar de Google-index en kunt u gedetailleerde rapporten genereren met informatie over de zichtbaarheid van uw pagina’s op Google. Met Google Sitemaps kunt u ons op de hoogte te houden van uw huidige pagina’s en de updates die u in deze pagina’s aanbrengt. Als u een sitemap verzendt, biedt dit geen garantie dat al uw pagina’s worden gecrawld of worden opgenomen in onze zoekresultaten. 

Als Google ons geen garantie geeft dat de pagina’s worden gecrawld of opgenomen in de zoekindex, waarom zouden we die Sitemap dan nog aanmaken? Als de site zelfs na een verloop van een maand nog steeds niet is opgenomen in de index, wat heeft het dan voor nut?

Yahoo hebben we helemaal niets verteld over de lancering van de site. Dit hadden we wel kunnen doen via Yahoo’s Site Explorer, maar dit hebben we destijds niet gedaan. En wat blijkt? Yahoo heeft de bewuste pagina’s wel gevonden, zonder de hulp van een Sitemap dus. Zoeken we op ‘bouwmanagement’, dan komen we Veld gegarandeerd tegen in de index. MSN is daarmee niet zo snel, daar komen we de gehele site (dus ook de oude) niet tegen.

Ik mis nu dus het algehele nut van de Sitemaps. Het nut voor Google snap ik wel, maar voor de webmaster? Vandaar misschien dat Google allemaal andere features als Crawl statistieken heeft toegevoegd aan de Sitemaps tool?

Websites sneller maken? Yahoo vertelt.

Yahoo wijst ons vandaag op een eenvoudige manier van websites optimaliseren: het limiteren van het aantal plaatjes en andere bestanden die worden gebruikt om een pagina op te maken. Deze tip is logisch en niets nieuws, maar nu veel grote websites denken “iedereen heeft toch breedband” wordt deze tip weer heel toepasbaar en actueel. Een webpagina bestaat tegenwoordig uit veel meer dan alleen HTML. Kijk bijvoorbeeld naar de oorzaken voor de performance problemen van Hyves.

Een fragment uit hun weblog:

Popular web sites are spending between 5% and 38% of the time downloading the HTML document. The other 62% to 95% of the time is spent making HTTP requests to fetch all the components in that HTML document (i.e. images, scripts, and stylesheets). The impact of having many components in the page is exacerbated by the fact that browsers download only two or four components in parallel per hostname, depending on the HTTP version of the response and the user’s browser. Our experience shows that reducing the number of HTTP requests has the biggest impact on reducing response time and is often the easiest performance improvement to make.

Lees verder op Yahoo User Interface Blog. Hun volgende artikel zal gaan over de invloed van caching op de performance van een website. Mijn gok is dat er minder gecached wordt dan over het algemeen wordt aangenomen. Fijn dat Yahoo deze gegevens openbaar maakt. Ik had het zelf graag onderzocht, maar dit zijn tijdrovende klusjes.

Het risico van teveel power

Even de strekking van een gesprek bij ons op kantoor.

“Hmm.. Die nieuwe sites die we gelanceerd hebben die doen wel wat traag aan!”

“Ja, hebt gelijk, de performance is niet helemaal wat het zou moeten zijn. Maar het zal die enorme flash header wel zijn die er van het reclamebureau bij moest.”

“Je hebt gelijk, die is ook veel te groot, maar ja, daar kunnen wij ook niks aan doen. Wat moet dat moet. De laadtijd kan nog net door de beugel.”

Maar op een gegeven moment gaat het je toch een beetje dwars zitten dat de site wel erg vaak tegen de irritatiegrens van 2 a 3 seconden aanhikt. Je gaat het onderzoeken door dingen uit te sluiten. Zonder de flash header blijkt de site niet veel sneller. De productcatalogus blijkt het ook niet te zijn, ondanks dat dat in verband met de multi-language functionaliteit een nogal heftige query is. Wat is het dan wel?

Na lang zoeken bleek het de functie te zijn voor het ophalen van het menu, waardoor er door een foutieve recursieve functie niet 1 of 2, maar 240 queries per pagina werden uitgevoerd, alleen al voor de weergave van het menu! Dat is nu het risico van teveel power. Onbegrijpelijk dat we die fout niet eerder hadden opgemerkt.
Wat hebben we vandaag geleerd: tel altijd het aantal uitgevoerde queries per pagina en accepteer NOOIT, maar dan ook NOOIT meer een acceptabele laadtijd.

(Het voordeel was trouwens wel dat alle overige code, voordat we de fout gevonden hadden, nu helemaal geoptimaliseerd is. Dat dan weer wel.)