@antonico said:
Non penso sia un'affermazione estiva... credete davvero che gli ingegneri di google facciano le cose tanto per farle? Visti i risultati penserei proprio di no.
[link omesso so io perché ]
Torno a ripetere, prima che nel posizionamento influisca la velocità di scansione del bot, troppe altre cose devono essere fatte.. e fondamentalmente non sono d'accordo con la "non chiusura" dei tags.
Ho letto l'articolo di cui parlavi e allora non è proprio quello che ho letto io che si riferiva proprio a codice scritto male, secondo il quale Google lo indicizzerebbe meglio.
Quello che hai postato tu è sì interessante, ma si riferisce ad alcuni tag dell'HTML4 e infatti sotto il filmato c'è scritto chiaramente quali tag si possono omettere e a quali condizioni.
HTML - as opposed to XHTML, even when delivered with the MIME type text/html - allows authors to omit certain tags. According to the HTML 4 DTD, you can omit the following tags (tags of so-called "void" - empty - elements are marked as strikethrough):
*HTML - contrariamente a XHTML, anche se espresso con il tipo MIME text / html - consente agli autori di omettere alcuni tag. Secondo la DTD HTML 4, è possibile omettere i seguenti tag (gli elementi contrassegnati come barrato si possono omettere):*Quindi segue una lista di elementi di cui si possono o si devono, omettere i tag di chiusura.
Riporto per semplicità solo quelli da omettere e cioè: /area, /base, /br, /col, /hr, /img, /input, /link, /meta, /param.
Sono elementi che non hanno chiusura in HTML4, come riportato nella guida del W3C, qui tradotta in italiano: diodati.org/w3c/html401/struct/objects.html#edef-AREA dove si dice chiaramente che i marcatori AREA e MAP non vanno chiusi, e questo lo sapevamo, poi segue la lista, che non riporto più, di quegli elementi la cui chiusura è opzionale, come i paragrafi per esempio. Quella paginetta è pleonastica, dice cose che già sapevamo: alcuni tag si possono lasciare aperti ma solo e soltanto in HTML4, in XHTML i tag vanno sempre chiusi, in alternativa usa HTML5.
Il tempo è denaro, tanto denaro, specialmente per google che ha milioni di siti internet da scansionare e tenere in archivio.
A sì non c'è dubbio, ma quel video in pratica ci sta semplicemente dicendo che non dobbiamo usare XHTML ma addirittura HTML 4 e che meglio sarebbe usare HTML5 che è più breve. Io non aggiungo altro!
Prova a vedere cosa esce con il validatore HTML5 sul sito del W3C a proposito della pagina principale di Google.
html5.validator.nu/?doc= prova e vedrai che schifezza.
Ipotesi ridicola: google dice che posizionerà meglio le pagine che hanno i tag <li><p> non chiusi perchè crede che il superfluo sia inutile. Cosa fai, rispetti le regole standard, o ti adatti per stare dietro a quel giochino che genera più dell'80% del traffico internet mondiale?No, non dice affatto che si posizionerà meglio, dice solo, e non è poco, che potresti risparmiare anche il 20% nella dimensione dei tuoi file e che gli utenti troveranno più facilmente ciò che cercano nel tuo sito, in pratica ti hanno già trovato, solo che cercano qualcosa all'interno del tuo sito, il chen on è cosa da poco, ma è ben lontano dal discorso dell'indicizzazione.
Inoltre parla di codice più pulito
If you combine all these methods together you should be able to save 10-20% in file size (and even more markup), depending on your coding style and the amount of text content in your pages. Your code will look much cleaner, and your site's visitors will get to your content faster. We applied many of these techniques in our Privacy Centers, saving about 20% of the original file size.
Se si combinano insieme tutti questi metodi si dovrebbe essere in grado di risparmiare il 10-20% nelle dimensioni del file (e ancor più di markup [e certo, praticamente ti sta dicendo di togliere proprio il markup, nota mia]), a seconda del vostro stile di codifica e la quantità di testo contenuto nelle tue pagine. Il codice sarà molto più pulito [ma che cacchio dice, e certo se scrivo male il codice farà schifo comunque sia la codifica che scelgo di usare* :D], e nel tuo sito i visitatori riusciranno a trovare più rapidamente i tuoi contenuti [questa parte non chiarissima ma è colpa della traduzione ne sono certo]. Abbiamo applicato molte di queste tecniche nei nostri Privacy Centers, il salvataggio di circa il 20% delle dimensioni del file originale.*
Ho provato il codice del Privacy Centers di cui mette il link nella paginetta che hai postato tu, l'ho provato col validatore del W3C ed è uscito che è valido per HTML5 + ARIA oh bene!
Ma noi ci stiamo girando intorno ad una pagina che sostanzialmente dice solo di usare HTML 5 che è bello, che è figo, che fa risparmiare tempo e denaro e soprattutto ci stiamo lavorando sodo, che non è poco.
Uno dei coordinatori del progetto HTML5 è un certo Ian Hickson, inventore dei test Acid1 e Acid3, sviluppatore tra l'altro proprio di HTML5, dice chiaramente di non usare HTML5 per progetti, ma lo sapevamo già! Solo perché HTML5 non è ancora uno standard e quando lo diverrà moltissime cose potrebbero cambiare.
Dato che non posso mettere links... w3.org/QA/2009/05/_watching_the_google_io.html Qui dicono chiaramente che in Google devono smetterla di parlare di HTML5 standard, perché non lo è ancora.
Insomma, aspetta, non ti entusiasmare troppo, quella pagina è la pubblicità di un prodotto che verrà, dice un sacco di cose ovvie e di corbellerie, ma sostanzialmente dice che Google sta spendendo molto su HTML5 e che quindi anche voi, noi, dobbiamo usarlo e che se lo facciamo, quei lumaconi del W3C lo faranno uscire finalmente. E che cavolo!
Ma nel W3C non sono lumaconi, semplicemente non basano le loro scelte su un solo gruppo di lavoro che spinge per un'uscita solo e soltanto perché fa comodo a lui; l'hanno fatto in passato, vedi Netscape e Microsoft e non vogliono commettere gli stessi errori, a me sembra più che giusto.
I fogli di stile esistono da anni, più di dieci, ma grazie all'idea che table fosse un'implementazione per formattare il layout di pagina solo di recente ci siamo resi conto che ad usare pesantemente i fogli di stile porta a indubbi vantaggi.
E table è stata un'idea spinta e voluta fortemente da Netscape, vogliamo ripetere gli stessi errori solo perché con l'attuale estensione di HTML5 Google risparmia suoi soldi? Ma scherziamo?
