@pstrada ha detto in Tempo di risposta del server:
Mah, se fossi un tuo utente non mi lamenterei delle performances, lo sto guardando da telefono, sia con wifi sia con 4g e non riscontro lentezza.
Sì, infatti non mi preoccupo dei clienti, ma del crowler di google.
Poi è un ecommerce..Stai valutando i tempi della home o delle pagine di prodotto? Se mai google ti penalizzerà non lo farà per i tempi di risposta, ma per altri motivi.
Home e pagine
@jabba ha detto in Tempo di risposta del server:
I tuoi concorrenti non si posizionano meglio perchè la loro pagina carica 0.1 sec più velicemente della tua, ma perchè hanno backlink, testi SEO, immagini indicizzate ecc...
A parte i backlink, come Seo e immagini indicizzate non sono messo male.
Allo stesso modo il tuo utente non sarà più felice se le pagine caricano in 1 secondi invece che in 1.1 secondi... si spazientiscono se vanno sopra i 3, ma adesso come adesso non mi sembra il tuo caso.
Questo sicuro, infatti non mi preoccupo dei clienti , ma del crowler di google.
Per tornare comunque alla tua domanda il TTFB dipende da tante cose: oltre al sito in sè dipende molto dall'hosting (sei su un condiviso? Dedicato?) oppure la distanza geografica (sei sotto CDN? Il tuo hosting è oltreoceano?)
Prova a controllare i competitor su quale hosting sono e vedere cosa torna indietro anche con un semplice ping da cmd.
Male che vada puoi sempre provare a contattare il tuo hosting e vedere se hanno qualche indicazione da darti (magari hanno sistemi integrati di CND o cache particolari che potrebbero aiutarti)
Hosting condiviso, primo piano il più economico.
C'è modo di verificare da solo se l'hosting è oltreoceano?
Un saluto a tutti.
Da diversi test effettuati su PageSpeed Insights e GT metrix rilevo un tempo di risposta del server un po' altino.
E' basso SOLO se attivo la cache ma NON attivo il componente GDPR (200 ms circa)
Con cache ma con GPDR attivato sale sui 500ms (non con avviso) e 700/800ms (avviso in rosso)
Senza cache e con GDPR sempre alto 700-800 ms.
Per il resto i punteggi delle performance del sito sono ottimi.
Poi guardando una decina di miei competitors che si posizionano prima di me, alcuni hanno performance più scarse su altri settori, anche segnalate con percentuali in rosso! Ma il loro tempo di risposta del server lo hanno molto basso! 20-30-50 ms circa!
Quindi anche il mio tempo più basso di 200ms non è ancora... basso!
Ho paura che pur avendo ottime performance questo mio tempo di risposta del serve alto possa penalizzarmi sulle SERP.
Cosa dovrei controllare? Sarà il mio server che è lento? (Ergonet, piano base "Equilibrio"). Oppure mi sfugge qualcosa del mio sito? Sito semplicissimo con template Cassiopeia, senza plugin, scorre liscio... Utilizzabile anche senza cache!
Schermata di un test con migliori prestazioni, ma peggiore risposta del server:
Per tornare in tema dell'argomento del post (cache),
facendo ulteriori prove con la cache attiva noto è utile per abbassare il tempo di risposta del server fino a 400 ms.
-Attivare la cache nel plugin (Sistema - Cache pagina), selezionare SI' su Usa cache Browser
-Attivare la cache unica moderata in Configurazione globale->Sistema
(Poi nel mio caso specifico la risposta del server vien peggiorata dal componente GDPR)
@pstrada ha detto in La/le cache, come usarle al meglio sui siti Joomla?:
Puoi provare a fare una misurazione disattivando il codice per il gdpr, che sicuramente introduce del ritardo. Guarda anche la sezione waterfall, di GT metrix, per vedere dove si presenta il ritardo maggiore
Sì, disattivando il GDPR il ritardo si riduce e scompare l'avviso della risposta del server!
Da valutare l'estensione GDPR (se sono tutte così o alcune più veloci)
@Gioacchino ha detto in La/le cache, come usarle al meglio sui siti Joomla?:
@ste981 se guardi i vari tool non ne esci più, guarda questi risultati:
https://gtmetrix.com/reports/www.crear-arredi.it/Ni3LhLtK/
Gtmetrix da risultati sempre diversi e ogni tanto positivi, come se il problema è monte del sito:
https://gtmetrix.com/reports/www.crear-arredi.it/ZvIBFj2E/
(Ho utilizzato il server di Londra invece di quello di Vancouver che propone di default)
Ho provato ad abilitare la cache (prima disattivata), e rifare un po' di test su PageSpeed Insights e GTmetri, ma pare che la cache lato sito non influisce sulla risposta del server.
@pstrada ha detto in La/le cache, come usarle al meglio sui siti Joomla?:
Con gtmetrix non mi chiede l'attivazione di un utente pro. Se vuoi ti faccio gli screen e te li mando. Che template utilizzi. In ogni caso il sito è accessibile senza problemi, non diventerei matto sulle performance ma mi concentrerei sul layout
Utilizzo template di default Cassiopeia, pochissime estensioni di terzi. So bene che il layout è vecchio stile ma per questioni di semplicità di uso del sito e mia di produzione ( non sono programmatore), per aver implementato in tempo successivo una sezione ecommerce e visto i risultati su google ottenuti negli anni, non ho mai fatto "ammodernamenti" drastici.
Un layout più attuale sarebbe più carino, ma dovrei studiarmelo....
@Gioacchino ha detto in La/le cache, come usarle al meglio sui siti Joomla?:
Ci sono diversi parametri che potrebbero influire, sempre meglio testare con più tool, ma anche visivamente ad occhio se ti sembra sia lento il caricamento sicuramente qualche approfondimento in più si può fare, stiamo parlando 1,2 secondi
Visivamente il caricamento non è lento, ma anzi è rapido, anche con connessione dati.
@pstrada ha detto in La/le cache, come usarle al meglio sui siti Joomla?:
Hai provato ad attivare la cache di pagina? Comunque predi con le pinze i dati di Pagespeed, prova eventualmente a fare un'analisi con GT Metrix se da ulteriori dettagli. Se ti va metti il link dell sito.
Devo provare con la cache di pagina, ma di logica quella di pagina influisce sul utente navigatore, non sugli spider dei motori di ricerca....o sbaglio??
GT metrix non ho l'account a pagamento e con il free non vedo i dettagli.
Il sito è quello in mia firma: www.crear-arredi.it
Buongiorno a tutti.
Non ho mai usato la Cache. Le immagini sono ottimizzate, il sito è leggero e lato utente carica velocemente.
Ora però, dopo alcuni lavori ai fini SEO, da un analisi con PageSpeed Insights ho un risultato non soddisfacente su tutte le pagine per il Time to First Byte (TTFB) e la risposta del server!
Ho paura che questo sia dannoso per il crawler di Google e il posizionamento (altri miei competitors su questi fattori non sembra abbiamo problemi).
Cosa mi consigliate di fare? Attivare (dovrò acquistare un piano più costoso su Ergonet) la cache lato server? ...Queste lacune saranno causate solo dal server oppure sul sito c'è qualcosa che rallenta la richesta del server?? (il sito è quello in firma)
@jabba ha detto:
Si il robots è corretto. Ti consiglio di mettere in fondo anche l'url della sitemap. Tipo In questo modo favorisci il crawling a tutti i bot (a Google dovresti già avergliela inviata tramite Search Console).
Ciao
Sì grazie, c'è anche la sitemap in fondo 
@jabba ha detto in Indirizzi con HTTP:
Sisi capisco quello che intendi. Quello che volevo dirti è che quei link (a immagini, librerie, ecc...), su Joomla, sono gestiti dinamicamente dal router. Quindi dal momento che attivi l'HTTPS nel pannello di controllo tutti queli link diventano automatico in HTTPS a meno che non siano fisicamente scritti all'interno del database, cosa che però dubito sia avvenuta se hai sempre inserito contenuti (link, immagini, video, ecc..) con gli editor di joomla e non a mano direttamente nel codice.
No, scritto a mano nel codice nulla.
Ok, quindi l'attivazione dell'HTTPS non è un redirect, ma una sotituzione di tutti gli indirizzi del sito. (E quindi Google non vedrà mai versioni HTTP)
Per stare in tema di Googlebot, secondo te è un buon file Robots.txt questo?
Ho messo Allow per il componente e-commerce, che altrimenti sarebbe rimasto in Disallow: /components/
User-agent: *
Disallow: /administrator/
Disallow: /bin/
Disallow: /cache/
Disallow: /cli/
Disallow: /components/
Disallow: /includes/
Disallow: /installation/
Disallow: /language/
Disallow: /layouts/
Disallow: /libraries/
Disallow: /logs/
Disallow: /modules/
Disallow: /plugins/
Disallow: /tmp/
Allow: /components/com_jshopping/
Allow: /components/com_jshopping/files/img_products/
Allow: /components/com_jshopping/files/img_categories/
Ciao a tutti.
Questione JCH optimize:
Su J4 si diceva non essere particolarmente utile, oggi su J5?
Ho fatto alcune prove su un semplice sito:
Su PageSpeed Insights e su Pingdom non ci sono differenze ad averlo attivo o no (a volte 3-4 punti di prestazione in più su Page Speed disattivandolo!)
Su GTmetrix, disattivando JCH, performance generale +4% e più veloce di 0.3 sec.
A questo punto credo che potrei disattivarlo o disinstallarlo, non tanto per la velocità del sito (sono valori insignificanti per il navigatore), ma per eventuali problemi di avere un plugin che si diceva potesse dare più danni che benefici, e forse essere un piccolo ostacolo in più al crawler di Googlebot...
(Credo che un sito leggero, semplice, ben ottimizzato non abbia bisogno di JCH, e anzi... forse meglio non averlo proprio)
in questo articolo si sconsiglia l'uso di plugins per l'ottimizzazione:
@jabba ha detto in Indirizzi con HTTP:
Questa secondo me è un suggerimento valido solo per chi ha Wordpress perchè
quegli sciaguratquei birbanti di WP quando crei un link nell'editor ti mette l'url assoluto con anche il nome del dominio. Quindi se nell'URL c'è HTTP allora te lo tieni sempre e comunque.
Joomla è più furbo e tutti i link sono salvati in formato non-sef (index.php?valore&valore&valore...) e tutto il resto (URL friendly, dominio ecc..) viene aggiunto dal router, quindi anche l'HTTPS viene aggiunto in automatico.Ovviamente il discorso cambia se tu, nel corso degli anni, hai inserito negli articoli o moduli o simili dei percorsi assoluti. In quel caso sarebbe meglio cambiarli ma sinceramente, a meno che non siano migliaia, lascerei perdere, non è quello che brucia il crawler budget.
Ciao!
Grazie per le informazioni!
Tu stai parlando di link nelle pagine, io mi riferivo ad indirizzi presenti e trovati nel codice del sito:
Ho circa 200 indirizzi di pagine sul sito, ma Screaming Frog trova circa 3180 percorsi in HTTP nel codice del sito (comprese le 200 pagine). Questi percorsi sono:
Link diretti alle immagini (1170)
dipendenze Javascript (414)
dipendenze CSS (650)
dipendenze sconosciute Javascript e CSS (640)
(tra quelle, 650 javascript/css sono bloccati da Robot.txt con Disallow alla directory /pluging)
Tutti questi numeri sopra sono stati trovati anche in HTTPS e quindi sarebbero il doppio (6200)
Per questo era consigliabile l’eliminazione dal database dei circa 3000 percorsi HTTP per alleggerire Googlebot il quale ci passerebbe comunque ogni volta sopra nonostante il redirect massivo
Un saluto a tutti.
Con un analisi Seo tramite Screaming Frog sono emersi indirizzi duplicati: con http e con https e con suffisso .html e senza.
Sono subito andato ad attivare l'opzione Forza HTTPS, (ora non sono più accessibili le HTTP), ma è necessario scrivere anche altri codici nel file .htaccess per il reindirizzamento delle pagine da HTTP a HTTPS? O è sufficiente l'opzione da backend?
Inoltre ho aggiunto questo codice nel .htaccess che reindirizza gli URL senza suffisso .html a cm CON suffisso (io uso il suffisso e ho notato che Joomla apriva anche tutte le pagine senza meterlo il suffisso .html).
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !.html$
RewriteRule ^(.*)$ /$1.html [R,L]
Un altra questione importante che mi dice chi ha fatto l'analisi: oltre il redirect da HTTP a HTTPS bisognerebbe andare ad eliminare proprio gli url HTTP nel database con un search and replace.
In questo modo il crawler di google perderebbe meno tempo a scansionare e reindirizzare questi indirizzi inutili.. cosa ne dite?
Esiste una guida per fare ciò?
@Lucantropo ha detto in Cassiopeia/Bootstrap5 modalità desktop in mobile:
Penso che ottimizzare bene il sito coi css per i vari dispositivi sia sempre la miglior soluzione pensando un rapporto tempo dedicato/ % di utilizzatori.
Mediamente la percentuale di chi usa i tablet non è altissima, chi conosce e usa questa funzione del browser probabilmente è trascurabile.
....e conseguentemente trascurabile il fattore di voler per forza avere la possibilità di visualizzazione desktop su tablet!
Effettivamente lavorare sulle classi css dei moduli (soprattutto per me che non sono del mestiere) è la miglior soluzione come dici, rendendo il sito ben responsive su tutti i dispositivi dal tablet in giù.
Grazie per il contributo.
@Lucantropo Ho provato anche io il sito Yootheme, se ci fai caso però anche lì attivando l'opzione sito desktop, non mostrano il menu mobile per cellulare, ma quello per tablet posizionato in verticale.
Ora, scartando il discorso cellulare che non ha senso attivare la modalità desktop, su un tablet in verticale la modalità desktop sarebbe stata utile per alcuni siti.
si @jabba , le classi le ho già usate per nascondere l' Accordeon menu sul desktop e alcuni moduli su Mobile. Ho usato anche questa comoda tabella che allego...
Per il "problemino" di cui parlavo forse è proprio un impostazione di bootstrap5/cassiopeia. Ho voluto fare una prova con il template demo che si trova in rete. Puoi provare anche tu per curiosità:
apri questa pagina con cellulare, attivi "sito desktop" e si presenterà ancora con il toggler del menu a tendina. Poi da impostazioni zoom dell'app chrome scendi a 95% e vedrai il vero sito desktop puro! (anche da tablet 10.5" in verticale fa così)
cassiopeia.joomla.com/sample-layouts/articles
@jabba il "barbatrucco " css che proponi restringe la schermata (la dimezza anche settando 0.5!), ma mantenendola sempre in visione tablet (ristretta) sul cellulare settato in modalità desktop.
Il meta tag viewport nell’index.php non restringe la schermata ma abbassa lo zoom su mobile, fino al punto che si vede in modatità desktop senza selezionalra, ma anche lì la modalità desktop (selezionata su chrome) risulta sempre in tablet sia su cellulare che su tablet in verticale
(quest’ultimo è interessante per diminuire un po’ lo zoom generale del sito, in quanto forse su 1.0 è un pelo grande, su 0.9/0.8 parfetto.)
Come dicevi giustamente l'opzione modalità desktop è inutile su cellulare, ma su tablet in verticale potrebbe essere gradevole. Però nel mio caso, anche se come affermi è utilizzata poco dagli utenti, non è bella la visualizzazione tablet con tutti i moduli in vista prima degli articoli.
A questo punto se non risolvo con codici vari posso lavorare sulle classi dei moduli per nascondere sempre la modalità tablet (che ricordo viene visualizzata su cellulare in modalità desktop e su tablet in verticale)
Grazie ancora per le dritte!