18 Agosto 2023

Kleecks, iSmartFrame e CDN che ottimizzano i Core Web Vitals: ecco come barano i test di Google e perché sono poco utili per la SEO

Vediamo come alcuni trucchetti possano migliorare il punteggio Google PageSpeed Insight ma non superare i test Core Web Vitals.

Nel dinamico mondo del web, dove ogni dettaglio può significare una differenza nel posizionamento e nell’esperienza dell’utente, Google ha compiuto un notevole salto qualitativo nella sua metodologia di valutazione. Dal momento in cui Google ha introdotto i PageSpeed Insights – strumenti che per anni sono stati il riferimento per gli sviluppatori e gli SEO per valutare le prestazioni dei loro siti – la sua evoluzione ha portato all’avvento dei Core Web Vitals. Questa nuova suite di metriche non solo misura l’efficienza e la velocità di un sito web, ma va oltre, focalizzandosi sulla vera e propria esperienza dell’utente.

I Core Web Vitals: La transizione da Vanity Metrics a Strumenti Cruciali

I giorni in cui bastava vantare un punteggio elevato sui PageSpeed Insights sono finiti. Ora, Google richiede una comprensione più profonda delle prestazioni effettive di un sito. I Core Web Vitals sono diventati l’emblema di questa evoluzione, segnando una chiara distinzione tra ciò che è puramente estetico e ciò che è fondamentale per l’esperienza dell’utente.

  1. I Core Web Vitals LABS: Si tratta di un set di test condotti in laboratorio da Google. Questi test, pur essendo rigorosi e dettagliati, sono in realtà delle simulazioni delle prestazioni di un sito. Non riflettono necessariamente l’esperienza dell’utente finale, ma sono strumenti preziosi per gli sviluppatori. Funzionano come una bussola che indica in quale direzione muoversi durante le fasi di progettazione e ottimizzazione del sito. Tuttavia, è cruciale comprendere che, pur essendo indicativi, non rappresentano la realtà concreta di come un sito viene percepito dagli utenti.
  2. I Core Web Vitals CRUX (Chromium Real User Experience): Qui entriamo nel cuore dell’esperienza dell’utente. Queste metriche sono basate sui dati reali raccolti dai browser basati su Chromium. Questi includono giganti come Google Chrome, ma anche Microsoft Edge, Opera, Brave e molti altri. Ogni volta che un utente apre una pagina web attraverso questi browser, essi inviano a Google una serie di informazioni dettagliate riguardo il caricamento della pagina, la sua interattività e la stabilità visiva. Google, analizzando questi dati, estrae una media delle performance degli ultimi 28 giorni e stabilisce se il sito risponde positivamente o meno ai parametri dei Core Web Vitals, sia per la versione desktop che mobile.

Mentre i test LABS offrono una visione “teorica” delle prestazioni di un sito, i dati CRUX forniscono una rappresentazione “pratica”, basata su esperienze reali. Questi ultimi sono diventati di vitale importanza nella determinazione della visibilità di un sito nella SERP di Google. In altre parole, un sito può avere punteggi eccellenti nei test LABS, ma se non soddisfa le metriche CRUX, la sua posizione nei risultati di ricerca potrebbe ne risentire gravemente.

Ne abbiamo parlato in modo intensivo e specifico in questo post: Core Web Vitals e dati CRUX.

In parole povere non necessariamente un punteggio con 100 di punteggio PageSpeed può superare i Core Web Vitals, e non necessariamente un punteggio con 60 di punteggio PageSpeed non può superarlo come possiamo vedere dall’analisi di questo cliente che con un punteggio PageSpeed media di appena 50 su dispositivi Mobile, supera comunque brillantemente il test Core Web Vitals, posizionandosi come 375esimo sito in Italia ed almeno 9,2 milioni di visitatori unici al mese ed oltre 15 milioni di pagine viste. (Fonte Similarweb.com con Analytics connesso).

PageSpeed IlCorrieredellacitta

Similarweb Ilcorrieredellacitta

 

L’evoluzione nella ricerca di prestazioni web ottimali

Nel recente contesto digitale, dove la velocità e l’efficienza di un sito web possono fare la differenza tra un cliente conquistato e uno perduto, l’attenzione all’ottimizzazione delle prestazioni è diventata cruciale. La rinnovata importanza attribuita dai Core Web Vitals ha dato impulso al settore delle soluzioni di ottimizzazione, portando alla luce una serie di strumenti progettati per aiutare i siti web a raggiungere il massimo delle loro prestazioni.

Kleecks CDN e iSmartFrame: L’apparente magia nell’Ottimizzazione delle Prestazioni

Tra le molteplici opzioni disponibili per gli sviluppatori e i proprietari di siti web, emergono Kleecks CDN e iSmartFrame come due leader riconosciuti nella fornitura di soluzioni orientate alla performance.

  1. La filosofia dietro le CDN: Le CDN, o Content Delivery Networks, rappresentano una rete di server distribuiti in vari punti geografici, con lo scopo di servire contenuti ai visitatori in maniera più rapida e efficiente. L’obiettivo principale di queste reti è di minimizzare la distanza tra il visitatore e la fonte dei contenuti web, garantendo un tempo di caricamento ridotto e un’esperienza utente fluida.
  2. Kleecks CDN e iSmartFrame a lavoro: Entrambe queste soluzioni, pur avendo ognuna le sue specifiche caratteristiche, sfruttano le potenzialità delle CDN e operano come reverse proxy. In questa funzione, agiscono come intermediari tra l’utente finale e il server originale del sito.

    La magia avviene quando prendono in carico il codice sorgente di un sito web e lo ottimizzano, eseguendo operazioni tecniche avanzate come:

    • Minifizzazione: Comprimere codici JS e CSS, riducendo lo spazio e velocizzando il caricamento.
    • Conversione di immagini: Cambiare formati di immagine pesanti con formati più leggeri e veloci come WebP, senza compromettere la qualità.
    • Cache e riduzione della latenza: Grazie ai meccanismi di cache, i contenuti frequentemente richiesti vengono conservati e serviti più rapidamente, minimizzando i tempi di attesa per l’utente.
    • Molto altro ancora.
  3. Un dono per gli sviluppatori: La bellezza di queste soluzioni risiede nella loro natura di PaaS, o Platform as a Service. Invece di dover gestire manualmente le complessità dell’ottimizzazione, gli sviluppatori possono fare affidamento su queste piattaforme, che si occupano di tutto il lavoro pesante, permettendo loro di concentrarsi su altre sfide del progetto evitando di dover mettere mano al codice applicativo e risolvere le problematiche di performance correggendo il codice.

Analisi Approfondita della Discrepanza tra LABS e CRUX

Nel nostro continuo sforzo di comprendere la dinamica delle prestazioni dei siti web, ci siamo imbattuti in un particolare dilemma riguardante l’utilizzo di servizi come Kleecks, iSmartFrame e altri strumenti simili di ottimizzazione. Benché questi servizi promettano prestazioni ottimali, la realtà potrebbe essere leggermente diversa.

Fa piuttosto sorridere (per usare un eufemismo) come società che si pongono sul mercato come Leader di fascia Enterprise di ottimizzazione Core Web Vitals e Web Perfomance, abbiano i loro siti istituzionali con cui si interfacciano con il mondo, non in grado di superare i test Core Web Vitals, come possiamo vedere nelle immagini seguenti:

 

Arrivando in entrambi i casi ad avere serissimi problemi di TTFB che superano il secondo, laddove Google raccomanda un tempo di TTFB inferiore ai 200 ms.

Nel corso delle nostre indagini, abbiamo deciso di andare oltre la semplice teoria e supposizioni, ma di esaminare in dettaglio alcuni clienti che fanno uso di queste tecnologie emergenti. L’obiettivo era di comprendere meglio come questi stack tecnologici gestiscono le richieste e servono contenuti, in particolare in risposta all’user agent specifico di Google PageSpeed Insight.

Dopo una serie di test accurati e meticolosi, abbiamo ottenuto risultati sorprendentemente illuminanti. Abbiamo scoperto che, al rilevamento dell’user agent di Google PageSpeed Insight, diversi file JavaScript non vengono effettivamente caricati. Questo permette ai siti di ottenere un punteggio LABS impressionantemente elevato, quasi come se stessero indossando una maschera di ottimizzazione. Tuttavia, quando si tratta dei test Core Web Vitals, i risultati sono meno lusinghieri: non solo non superano questi test cruciali, ma presentano anche notevoli carenze in termini di performance.

Ad esempio, un dato particolarmente preoccupante è stato l’elevatissimo Time to First Byte (TTFB), ovvero la latenza, un indicatore chiave della velocità di risposta del server che Google consiglia mantenere sempre sotto ai 200 millisecondi.

TTFB 200 ms

Appare assurdo insomma vedere TTFB di oltre un secondo in siti di aziende che si propongono di fare ottimizzazione delle Web Performance, risultando a priori poco credibili.

Per rendere i nostri risultati più accessibili e comprensibili, abbiamo condensato le nostre scoperte in un video di analisi. Invitiamo tutti gli interessati a visionarlo per ottenere una panoramica dettagliata e una comprensione approfondita di ciò che abbiamo scoperto.

Disallineamento tra metriche sintetiche e dati reali

Abbiamo osservato che molti siti web, dopo aver integrato tali soluzioni, presentano punteggi eccezionali quando vengono analizzati tramite i test LABS di Google PageSpeed Insight. Questi punteggi, però, non sembrano coerenti con i risultati forniti dai Core Web Vitals (CRUX), che rappresentano le prestazioni del sito per gli utenti reali.

Abbiamo voluto a tal proposito prendere ad esempio alcuni siti che possiamo vedere nel filmato sopra che lasciano intendere sia la discrepanza, che la metodologia utilizzata per andare a verificare il modus operandi di queste “CDN miracolose”.

L’apparente disconnessione tra queste due metriche solleva alcune preoccupazioni:

I Test LABS Sintetici: Affidabilità e Limiti nel Mondo Reale

I test sintetici, come quelli offerti dai LABS, rappresentano un tipo di analisi che simula il comportamento degli utenti su un sito web in un ambiente controllato. Sebbene siano estremamente utili per identificare problemi di prestazione in fase di sviluppo o di ottimizzazione, presentano alcune limitazioni intrinseche che potrebbero rendere i loro risultati meno rappresentativi delle esperienze reali degli utenti.

Come funzionano i test sintetici?

Tali test vengono eseguiti in laboratorio, o in ambienti virtuali, dove le variabili come la larghezza di banda, la latenza e le risorse del dispositivo sono standardizzate o simulate. Ciò consente agli sviluppatori di ottenere metriche di prestazione in condizioni “ideali”, eliminando le fluttuazioni che potrebbero verificarsi in condizioni di navigazione reali.

Limitazioni dei Test Sintetici
  1. Ambienti Standardizzati: Poiché questi test sono eseguiti in condizioni controllate, possono non tener conto delle diverse combinazioni di hardware, software e connettività che gli utenti finali potrebbero avere. Un sito potrebbe funzionare bene su un dispositivo di fascia alta con una connessione veloce, ma avere prestazioni scarse su un dispositivo più vecchio o con una connessione lenta.
  2. Interferenze Esternali: Gli utenti reali potrebbero avere molte schede aperte, applicazioni in esecuzione in background o addirittura software di sicurezza che potrebbero influenzare le prestazioni di un sito web. Questi fattori non sono tipicamente simulati nei test sintetici.
  3. Caching e Interazioni Utente: Mentre i test sintetici possono simularne alcuni, potrebbero non catturare completamente il comportamento reale degli utenti, come scorrere una pagina, fare clic su vari elementi o come i browser gestiscono il caching di un sito durante visite successive.
  4. Strategie Ingannevoli: Come menzionato in precedenza, tecniche come il cloaking potrebbero permettere a un sito di “ingannare” i test sintetici, presentando una versione ottimizzata quando rileva un test in corso. Questo potrebbe tradursi in metriche di prestazione artificialmente elevate.

Il Cloaking: Una Strategia Ingannevole per Manipolare i Test di Google?

Il termine “cloaking” fa riferimento ad una pratica di ottimizzazione per motori di ricerca (SEO) che, negli anni, ha sollevato molte polemiche. Questa tattica si basa sulla presentazione di versioni diverse di una pagina web ai motori di ricerca e agli utenti reali. L’obiettivo principale dietro questa manovra è di manipolare e migliorare il ranking di un sito nelle pagine dei risultati dei motori di ricerca (SERP), mostrando ai motori contenuti che potrebbero essere visti come più pertinenti o ottimizzati.

Come funziona il cloaking?

Il funzionamento del cloaking si basa sul riconoscimento dell’User Agent o dell’indirizzo IP che sta effettuando la richiesta al server. Se l’User Agent è riconosciuto come quello di un crawler di un motore di ricerca (come Googlebot), allora viene mostrato un contenuto differente rispetto a quello che vedrebbe un normale visitatore, come ad esempio un html che esclude il caricamento dei Javascript.

CDN e Cloaking : Un Nuovo paradigma per l’ottimizzazione dei Core Web Vitals ?

Alla luce della crescente enfasi posta su metriche come i Core Web Vitals, si potrebbe supporre che alcune CDN, nella loro missione di ottimizzare le prestazioni, ricorrano a tattiche simili al cloaking. Questo significherebbe che quando tali CDN rilevano un test LABS da Google PageSpeed Insight, potrebbero servire una versione “alleggerita” o “ottimizzata” del sito, eliminando o modificando alcuni elementi per ottenere punteggi più elevati.

Durante le nostre indagini, abbiamo simulato essere un bot di Google modificando l’User Agent del nostro browser ed abbiamo notato che, in alcune circostanze, script Javascript esterni, notoriamente pesanti e potenzialmente rallentanti, non venivano caricati. Questa omissione, seppur potrebbe tradursi in tempi di caricamento apparentemente più rapidi durante i test, potrebbe non riflettere l’esperienza reale dell’utente.

Un pericoloso precedente nel plugin WP Optimize per WordPress accusato di alterare PageSpeed

WP-Optimize, un popolare plugin di WordPress per migliorare le prestazioni dei siti, è stato accusato di manipolare i benchmark. Gijo Varghese, sviluppatore specializzato in prestazioni web e creatore del plugin FlyngPress, ha evidenziato che WP-Optimize disabilita JavaScript durante i test con strumenti di benchmarking. La sua affermazione è stata avvalorata da uno screenshot che ha mostrato come il plugin impedisca il caricamento di file JavaScript durante i test.

Questo comportamento ha generato reazioni negative da parte della comunità di WordPress. Alcuni hanno paragonato questa tattica a truffe simili, come lo scandalo delle emissioni di Volkswagen. Gli utenti hanno espresso la loro delusione e preoccupazione per queste pratiche ingannevoli. La discussione ha sottolineato l’importanza di concentrarsi sull’esperienza degli utenti reali piuttosto che sui punteggi dei test. Tuttavia, la fiducia in WP-Optimize è stata compromessa a causa di queste rivelazioni.

Implicazioni ed Etica

La potenziale scoperta dell’utilizzo di tecniche di cloaking da parte delle CDN non è solo un dettaglio tecnico, ma solleva questioni profondamente radicate sia dal punto di vista etico che tecnico. Quando un’organizzazione opta per il cloaking, potrebbe effettivamente “mascherare” le vere prestazioni di un sito, dando l’illusione di un’ottimizzazione che in realtà non esiste. Sebbene l’intenzione primaria possa sembrare quella di migliorare le prestazioni, ciò che realmente accade è una distorsione dei risultati dei test, tradendosi in una rappresentazione ingannevole delle capacità effettive del sito. Questo può portare sviluppatori e titolari di siti web a prendere decisioni basate su dati erronei, deviandoli dalla rotta ottimale.

Oltre a ciò, è fondamentale considerare il significativo onere finanziario che tali soluzioni comportano. Le tariffe di alcune di queste CDN possono raggiungere cifre considerevoli, anche diverse migliaia di euro al mese, che si traducono in spese mensili considerevoli nel lungo periodo. Se queste ingenti somme vengono spese senza conseguire un miglioramento tangibile, come il superamento dei Core Web Vitals, si potrebbe legittimamente domandare se tali risorse sarebbero state meglio spese altrove.

In effetti, considerando il panorama attuale delle tecnologie web e la crescente enfasi sulle prestazioni, avrebbe assolutamente senso reinvestire queste somme in soluzioni più sostenibili e definitive. Impegnare risorse per l’assunzione o la consulenza di esperti, come sviluppatori web dedicati e sistemisti Linux specializzati nelle prestazioni web, potrebbe offrire un ritorno sull’investimento molto più significativo. Queste figure professionali possono affrontare e risolvere le problematiche di performance alla radice, offrendo soluzioni su misura che non solo risolvono le sfide immediate, ma anche prevengono problemi futuri. E il tutto con un investimento una tantum, piuttosto che onerose tariffe ricorrenti.

L’Impatto del Javascript sulle Prestazioni Web: Una Lama a Doppio Taglio

Il Javascript è diventato uno degli strumenti fondamentali nello sviluppo web, permettendo di creare applicazioni web ricche, interattive e dinamiche. Tuttavia, come ogni strumento potente, se non utilizzato con discernimento, può avere conseguenze non intenzionali sulle prestazioni di un sito.

Il Peso di Javascript sul Browser

Quando un browser carica una pagina web, deve analizzare e eseguire gli script Javascript inclusi nella pagina. Questo processo può essere piuttosto oneroso, soprattutto quando si tratta di:

  1. Script di Grandi Dimensioni: Script voluminosi richiedono più tempo per essere scaricati, analizzati ed eseguiti. Ciò può ritardare l’elaborazione di altri elementi cruciali della pagina.
  2. Esecuzione Intensiva: Alcuni script, a causa della loro natura o della loro complessità, possono richiedere molte risorse durante l’esecuzione, causando un carico elevato sulla CPU o sulla memoria del dispositivo.
  3. Dipendenze Esterne: Gli script che fanno affidamento su librerie esterne o che richiamano risorse da server terzi possono introdurre ulteriori latenze, specialmente se tali risorse esterne sono lente o non ottimizzate.
Impatti Diretti sulla User Experience

L’esecuzione inefficiente di Javascript può portare a vari problemi, tra cui:

  • Blocco del Rendering: Gli script che vengono eseguiti prima che la pagina sia completamente caricata possono bloccare la visualizzazione del contenuto, lasciando gli utenti in attesa.
  • Interattività Compromessa: Se uno script impiega troppo tempo per rispondere, le interazioni dell’utente, come scorrere o fare clic, potrebbero essere ritardate o interrotte.
Tattiche Ingannevoli e Test LABS

Per ottenere punteggi elevati nei test sintetici come i LABS, alcune CDN potrebbero adottare strategie ingannevoli, come “saltare” il caricamento di risorse Javascript problematiche. Se un sito web “nasconde” questi script durante un test LABS, il risultato sarà una pagina che sembra caricarsi molto più velocemente, regalando al sito un punteggio di prestazione artificialmente elevato. Questo, tuttavia, non riflette l’esperienza reale dell’utente, che potrebbe essere esposto a tutti i problemi causati da tali script in un contesto di navigazione reale.

Conclusione: La Sottile Linea tra Metriche e Realtà

Nel complicato panorama del web, è facile lasciarsi sedurre da numeri perfetti e punteggi massimi. Ma, come spesso accade, ciò che luccica non è sempre oro. Google PageSpeed Insight, pur essendo uno strumento fondamentale, può talvolta offrire una visione parziale delle prestazioni effettive di un sito web.

Il Fascino Ingannevole dei Punteggi Perfetti

Un punteggio LABS di 100 in Google PageSpeed Insight può sembrare la testimonianza inequivocabile di un sito web ottimizzato e performante. Tuttavia, è fondamentale comprendere che tale metrica, se presa da sola, può essere fuorviante. Alcune società, ben consapevoli di questo, potrebbero ricorrere a tattiche ingannevoli per “truccare” i test LABS, al fine di esibire questi punteggi elevati soprattutto a clienti finali che non hanno la capacità o le competenze per distinguere la differenza tra una simulazione e l’esperienza reale dell’utente.

Il Risvolto della Medaglia: Il Cliente Finale Ingannato ed il business non migliorato.

La tentazione di impressionare il cliente finale con punteggi perfetti è comprensibile. Tuttavia, spesso, i proprietari di siti web o gli stakeholder non sono completamente consapevoli della natura tecnica e delle sfumature delle metriche web. Presentare un punteggio LABS elevato senza un superamento coerente dei Core Web Vitals negli ultimi 28 giorni potrebbe soddisfare a breve termine il cliente, ma non porterà benefici a lungo termine, soprattutto quando i visitatori iniziano a riscontrare problemi reali di navigazione sul sito.

Il Cuore della Questione: L’Esperienza Utente Reale

Oltre ai numeri, ciò che conta veramente è la CRUX – l’esperienza reale dell’utente. Se un sito non fornisce prestazioni consistenti e affidabili ai suoi visitatori, i punteggi LABS perfetti diventano irrilevanti. E nel tempo, la reputazione del sito potrebbe subire un danno irreparabile.

 

In Ultima Analisi

Mentre gli strumenti di analisi come Google PageSpeed Insight sono preziosi, non dovrebbero mai sostituire una valutazione completa e autentica dell’esperienza utente. È imperativo per chiunque gestisca un sito web guardare oltre i numeri brillanti e concentrarsi su ciò che conta veramente: fornire un’esperienza di navigazione di qualità a tutti i visitatori. E ricorda sempre di diffidare delle soluzioni che sembrano troppo belle per essere vere; spesso, lo sono.

Indipendentemente dalla soluzione di ottimizzazione delle prestazioni che scegli di adottare per il tuo sito web, è fondamentale non fermarsi ai primi risultati, ma piuttosto analizzare e monitorare l’andamento dei Core Web Vitals nel medio periodo. La tecnologia web è in continua evoluzione e ciò che oggi sembra funzionare alla perfezione, domani potrebbe non essere altrettanto efficace. Pertanto, una valutazione continua e prolungata nel tempo ti permetterà di avere una visione chiara e realistica delle prestazioni del tuo sito. Mirare al superamento dei Core Web Vitals non dovrebbe essere un obiettivo a breve termine, ma un impegno costante, garantendo così un’esperienza di navigazione di qualità ai tuoi utenti e una solida reputazione per il tuo sito nel panorama digitale.

 

Hai dei dubbi? Non sai da dove iniziare? Contattaci !

Abbiamo tutte le risposte alle tue domande per aiutarti nella giusta scelta.

Chatta con noi

Chatta direttamente con il nostro supporto prevendita.

0256569681

Contattaci telefonicamente negli orari d’ufficio 9:30 – 19:30

Contattaci online

Apri una richiesta direttamente nell’area dei contatti.

INFORMAZIONI

Managed Server S.r.l. è un player italiano di riferimento nel fornire soluzioni avanzate di sistemistica GNU/Linux orientate all’alta performance. Con un modello di sottoscrizione dai costi contenuti e prevedibili, ci assicuriamo che i nostri clienti abbiano accesso a tecnologie avanzate nel campo dell’hosting, server dedicati e servizi cloud. Oltre a questo, offriamo consulenza sistemistica su sistemi Linux e manutenzione specializzata in DBMS, IT Security, Cloud e molto altro. Ci distinguiamo per l’expertise in hosting di primari CMS Open Source come WordPress, WooCommerce, Drupal, Prestashop, Joomla, OpenCart e Magento, affiancato da un servizio di supporto e consulenza di alto livello adatto per la Pubblica Amministrazione, PMI, ed aziende di qualsiasi dimensione.

Red Hat, Inc. detiene i diritti su Red Hat®, RHEL®, RedHat Linux®, e CentOS®; AlmaLinux™ è un marchio di AlmaLinux OS Foundation; Rocky Linux® è un marchio registrato di Rocky Linux Foundation; SUSE® è un marchio registrato di SUSE LLC; Canonical Ltd. detiene i diritti su Ubuntu®; Software in the Public Interest, Inc. detiene i diritti su Debian®; Linus Torvalds detiene i diritti su Linux®; FreeBSD® è un marchio registrato di The FreeBSD Foundation; NetBSD® è un marchio registrato di The NetBSD Foundation; OpenBSD® è un marchio registrato di Theo de Raadt. Oracle Corporation detiene i diritti su Oracle®, MySQL®, e MyRocks®; Percona® è un marchio registrato di Percona LLC; MariaDB® è un marchio registrato di MariaDB Corporation Ab; REDIS® è un marchio registrato di Redis Labs Ltd. F5 Networks, Inc. detiene i diritti su NGINX® e NGINX Plus®; Varnish® è un marchio registrato di Varnish Software AB. Adobe Inc. detiene i diritti su Magento®; PrestaShop® è un marchio registrato di PrestaShop SA; OpenCart® è un marchio registrato di OpenCart Limited. Automattic Inc. detiene i diritti su WordPress®, WooCommerce®, e JetPack®; Open Source Matters, Inc. detiene i diritti su Joomla®; Dries Buytaert detiene i diritti su Drupal®. Amazon Web Services, Inc. detiene i diritti su AWS®; Google LLC detiene i diritti su Google Cloud™ e Chrome™; Microsoft Corporation detiene i diritti su Microsoft®, Azure®, e Internet Explorer®; Mozilla Foundation detiene i diritti su Firefox®. Apache® è un marchio registrato di The Apache Software Foundation; PHP® è un marchio registrato del PHP Group. CloudFlare® è un marchio registrato di Cloudflare, Inc.; NETSCOUT® è un marchio registrato di NETSCOUT Systems Inc.; ElasticSearch®, LogStash®, e Kibana® sono marchi registrati di Elastic N.V. Hetzner Online GmbH detiene i diritti su Hetzner®; OVHcloud è un marchio registrato di OVH Groupe SAS; cPanel®, L.L.C. detiene i diritti su cPanel®; Plesk® è un marchio registrato di Plesk International GmbH; Facebook, Inc. detiene i diritti su Facebook®. Questo sito non è affiliato, sponsorizzato o altrimenti associato a nessuna delle entità sopra menzionate e non rappresenta nessuna di queste entità in alcun modo. Tutti i diritti sui marchi e sui nomi di prodotto menzionati sono di proprietà dei rispettivi detentori di copyright. Ogni altro marchio citato appartiene ai propri registranti. MANAGED SERVER® è un marchio registrato a livello europeo da MANAGED SERVER SRL, Via Enzo Ferrari, 9, 62012 Civitanova Marche (MC), Italia.

SOLO UN ATTIMO !

Vorresti vedere come gira il tuo WooCommerce sui nostri sistemi senza dover migrare nulla ? 

Inserisci l'indirizzo del tuo sito WooCommerce e otterrai una dimostrazione navigabile, senza dover fare assolutamente nulla e completamente gratis.

No grazie, i miei clienti preferiscono il sito lento.
Torna in alto