Personal tools

speed

Feb 18, 2013

Sviluppo Front-End: ottimizzare le prestazioni

Migliorare l'esecuzione delle risorse di front-end

Sviluppo Front-End: ottimizzare le prestazioni

Alcuni trucchi e consigli per migliorare la velocità dei siti web

Per quanto riguarda lo sviluppo front-end, c'è sempre più attenzione alle performances, dato che favorendo la velocità dell'esperienza utente c'è un ritorno diretto in termini di soddisfazione da parte di chi fruisce il progetto web.

E' uscito da poco un articolo molto curato sull'argomento che ha attratto la mia attenzione:

Front-end performance for web designers and front-end developers di Harry Roberts.

Nell'articolo vengono illustrati e sintetizzati molti degli argomenti relativi all'ottimizzazione dello sviluppo front-end.

read more

Jun 04, 2012

Update Security Settings: time consuming? Non per forza!

Update Security Settings, dietro le quinte!

Update Security Settings: time consuming? Non per forza!

Filed Under:

Analisi di un processo tedioso per un manutentore di siti con molti oggetti

Nella mia carriera di tartaruga plonista, mi è capitato diverse volte di lavorare con siti di dimensioni notevoli. Quello a cui più sono affezionato a oggi conta quasi 400K oggetti in catalogo.

Quando il cliente ti chiede di cambiare una piccola impostazione di sicurezza in un workflow associato a 600 o 700 oggetti, tu plonista programmatore e manutentore sai che la to-do list sarà:

  1. Cambiare il workflow associato all'oggetto;
  2. Aggiornare il prodotto nell'installazione e ricaricare il profilo legato ai workflow;
  3. Premere in ZMI Update Security Settings e, se il sito è molto grosso, andare a casa! Ci si pensa la mattina seguente... (se la notte è stata sufficientemente lunga)

Ma non si può proprio fare meglio?

Si! Si può e ora vediamo come.

 

read more

May 13, 2012

Discipliniamo i bot di ricerca con robots.txt

introduzione al file robots.txt

Discipliniamo i bot di ricerca con robots.txt

Filed Under:

Cos'è e come sfruttare al meglio questo utile file

You shall not passCome molti sapranno, il robots.txt è un utile file da piazzare nella root di un qualunque sito internet, che permette di definire delle regole da dare ai vari spider dei motori di ricerca che accedono al nostro sito per indicizzare le sue pagine. Serve in sostanza a dare una lista di pagine a cui lo spider non può accedere e che quindi non vogliamo far apparire tra i risultati dei motori di ricerca.

Bisogna fare molta attenzione a queste regole e scriverle correttamente, perché per esempio se si è troppo restrittivi si rischia di nascondere tutte le proprie pagine al mondo intero (e i clienti non ne sarebbero molto contenti), mentre al contrario se si lascia troppa libertà c’è il rischio che vengano indicizzati anche contenuti indesiderati (anche se questo con il nostro amato Plone non dovrebbe accadere usando correttamente i workflow e i permessi).

Ultimamente mi sono interessato particolarmente alla customizzazione di questo file, perché abbiamo avuto problemi di prestazioni su alcuni portali, anche causati proprio dai bot che cercavano di accedere massivamente ad alcune pagine lente del sito, occupando parecchie risorse e di conseguenza rallentando tutto il sistema, se non addirittura bloccandolo.

Migliorare le prestazioni del sito con robots.txt? Certo! basta non far indicizzare pagine lente e senza contenuti rilevanti

 

read more

May 06, 2011

Varnish purge after article rate

Filed Under:

For one of the projects we are using a very aggressive Varnish configuration. We are caching also html (not for long but still) for anonymous users. It could be a problem if you have some dynamical features - like rating. 

But not any more. Using this simple vcl add-on you can purge article view after making a vote:

sub vcl_recv {
...
   if (req.http.Cookie && req.http.Cookie ~ "statusmessages=") { 
       purge("req.url ~ " req.url);
       pass;
   }
...
}

 

It simply checks if you have a statusmessages cookie in request (after rating an article Plone is displaying confirmation status message) and purge current url from cache. Simple, clean and it works!

May 04, 2010

New collective.funkload releases

I have recently released a new version of collective.funkload and collective.recipe.funkload. There is one major improvment - funkload recorder is now working properly with collective.funkload scripts.

Here @RedTurtle we are heavily using funkload for acceptance and benchmarking tests. We have started using it in 2008 just after Bristol Performance Sprint. We have found even more useful with buildout recipe. The only missing part was the recorder. It's built-in Funkload itself, but it was not enabled in the recipe. Well - now it is ;-)

/ If you want to know how to include funkload in buildout project - check my previous blog /

Starting a recorder is quite easy:

$ ./bin/funkload record -p 8080 MyTest


for full usage call:

$ ./bin/funkload record --help


This will start proxy on 8080 port and save all your browser requests to MyTest funkload scenario. Now open your browser, change proxy configuration to localhost:8080 and click-through test case. When you finish - stop the proxy with Ctrl-C. Funkload will generate a test_MyTest.py file and notify you where you can find it. It should be now collective.funkload compatible - you can lunch:

$ ./bin/funkload test /path/to/test_MyTest.py


To test it.

Another small improvement is a PloneFLTestCase. It extends default funkload test case, implementing two additional methods helping with Plone content creation. Right now instead of using this approach:

folder_portal_factory = self._browse(server_url + "/coreloadtests/Members/" + self.user_id +"/createObject?type_name=Folder",
                                             method='get', 
                                             follow_redirect=False,
                                             description = 'Get folder portal factory')

folder_edit_url = folder_portal_factory.headers.get('Location')        
folder_id = folder_edit_url.split('/')[-2]

folder_created = self.post(folder_edit_url, params=[
    ['id', folder_id],
    ['title', 'folder'],
    ['description', ''],
    ['description_text_format', 'text/plain'],
    ['subject_existing_keywords:default:list', ''],
    ['last_referer', 'http://localhost:8080/coreloadtests/Members/' + self.user_id + '/view'],
    ['form_submit', 'Save']],
    description="Post /coreloadtests/Members/user...280843853/atct_edit")

new_folder_id = folder_created.url.split('/')[-2]

 

you can just do:

new_folder_id = self.addContent(
        server_url, 
        portal_type='Folder', 
        params=[['id', 'id'],
                ['title', 'testing title'],
                ['description', 'testing description'],
                ['description_text_format', 'text/plain'],
                ['form.submitted', '1'],
                ['last_referer', ''],
                ['form_submit', 'Save']], 
        description='Create folder')

 

It doesn't do much, but for sure it helps you keep you test case readable.