Escalera PHP: frecuencia y mejores prácticas

votos
23

Acabo de terminar de leer esta publicación: https://developer.yahoo.com/performance/rules.html#flush y ya he implementado un color después de cargar la parte superior de mi página (head, css, top banner / search / nav) .

¿Hay algún golpe de rendimiento en el lavado? ¿Hay algo así como hacerlo con demasiada frecuencia? ¿Cuáles son las mejores prácticas?

Si voy a presionar una API externa para obtener datos, ¿tendría sentido enjuagarlos de antemano para que el usuario no espere que esos datos vuelvan y, al menos, obtener algunos datos de antemano?

Publicado el 09/12/2008 a las 14:51
fuente por usuario
En otros idiomas...                            


4 respuestas

votos
19

La técnica descrita se ve bien, pero tiene varios inconvenientes:

1) el tiempo entre el comienzo y el final del script PHP es pequeño en comparación con el tiempo de transmisión; también, esto le ahorra al usuario aproximadamente 0.5 segundos, según su fuente. ¿Es una cantidad de tiempo significativa para ti?

2) esta técnica no funciona con el buffering de salida gzip

3) si se sonroja con demasiada frecuencia, enviará un paquete casi vacío en color, lo que en realidad podría aumentar el tiempo de carga (en conexiones lentas y ruidosas).

4) una vez que enjuagues, no puedes enviar más encabezados

5) (problema menor) la respuesta del servidor vendrá en codificación fragmentada, lo que significa que el cliente no sabrá el tamaño por adelantado (por lo tanto, no mostrará "x% hecho" al descargar un archivo).

Por otro lado, si espera que su secuencia de comandos se ejecute durante mucho más tiempo (más de 20 segundos), puede ser necesario enviar algunos datos (espacios, por ejemplo) para evitar que el navegador agote la conexión.

Respondida el 09/12/2008 a las 15:10
fuente por usuario

votos
5

El lado negativo es que no se puede descomprimir el contenido y enjuagarlo, así que siempre prefiero usar gzip en lugar de enjuagar.

Algunas versiones de Microsoft Internet Explorer solo comenzarán a mostrar la página después de que hayan recibido 256 bytes de salida, por lo que es posible que deba enviar espacios en blanco adicionales antes de descargar para que esos navegadores muestren la página.

Esto hace que esto no sea una idea, ya que parece que el relleno de más datos no es muy útil.

Respondida el 09/12/2008 a las 14:58
fuente por usuario

votos
3

Creo color, es en realidad un mecanismo de ajuste fino. Los navegadores utilizan solamente cerca de 8 hilos para descargar contenido (depende del navegador). Si usted tiene 15 imágenes, el navegador se iniciará la descarga de imágenes 8 y no descargar nada más hasta que uno de ellos se completa, entonces comenzará a descargar la imagen siguiente, etc. Por el lavado después de la cabecera, que son básicamente diciendo al navegador qué puede comenzar la descarga. En el momento de la entrega del resto de la página (es decir .5 segundos más tarde), el navegador puede ya haber terminado de descargar el CSS y Javascript archivos. Esto liberaría hilos de descargas de otros contenidos.

Es probable que no desea utilizar ras en cualquier otro lugar que justo después de la cabecera. Un navegador por lo general no va a hacer que las etiquetas HTML sin cerrar, por lo que la entrega de una parte de la página no mostrará las cosas con mayor rapidez. Las versiones anteriores de IE no se muestra nada en absoluto hasta que se recibe una cierta cantidad de datos, o la entrega página es completa.

Respondida el 30/03/2010 a las 14:11
fuente por usuario

votos
2

Siguiendo el punto de Piskvor, si esperas una espera de más de 20 segundos, es mejor que proporciones una página básica (que puede ser comprimida) y usar Ajax para actualizar la página cuando el proceso lento haya finalizado. Sin embargo, comienzas a infringir la utilidad básica de html estático.

Respondida el 09/12/2008 a las 15:17
fuente por usuario

Cookies help us deliver our services. By using our services, you agree to our use of cookies. Learn more