I need to check several filters on the page heavily populated with images. The filters check images text only, so I would like to set up the browser for not displaying the images to speed up the test execution. Is it possible in Cypress?
There's a couple of ways, but it depends on how the page displays the images.
If it fetches them from an API, use cy.intercept() to catch the call to the API and stub the response
Check the network tab of dev-tools for fetches that load the images.
General pattern,
cy.intercept('/url-fetching-images', {})
May need adjusting if URL's vary per image - you can add wildcard chars.
Related
I have implemented a menu of several tabs. When opening one of the tabs, several images are loaded from an external resource in jpg format.
If I open another tab, then other images are downloaded (this is expected). But when I go back to the previous tab, NextJS downloads the old images again.
How can I get rid of unnecessary downloads?
p.s. I want to clarify that depending on the tab, different components are drawn, removing others (perhaps this is important)
next js just compress your image and improve performance, you must not expect to not load the image when you will request to server again if you want to not download the image again the solution I think maybe can work: you must use your cash with react query when you want to request again when client change tab instead of axis or fetch,
react query will see if the image in the server is changed to load it again or not
I have a React app that cycles through questions for a user to answer. Each question has a different background image. The questions are cycled through twice so each background image is displayed to the user twice during the user experience.
I was having some issues with image loading lag, so I implemented an 'initial load' cache to put all images into the browsers cache. Similar to what's shown here.
I've confirmed in Dev Tools that the necessary images are being added to cache at the initial load (good!). However I noticed that as a move through the app, each image is added to the cache again. Thus, I still have my loading lag for these images
When I am using these images, I currently import at the top such as:
import redGreenBackgroundImage from 'assets/images/redGreenBackgroundImage.png';
and in the component reference with
<img src={redGreenBackgroundImage}/>
I'm thinking that React/the browser is viewing the image as being different each time, so it's adding to the cache? However I haven't been able to find anything to support that in my Googling.
I'm having trouble getting pages to show up in the NEW tab and in the Optimized for Kik search results.
All my pages have the required title, meta description, canonical and script tag served if the user-agent contains the string "kik".
Here is an example of a page that isn't being indexed.
http://playcanv.as/p/MW862amA
The pages have been correctly set up for around a week and still aren't showing up. Any ideas why?
Currently, the Kik browser shows a loading screen on top of your website until the window.onload event has fired. If the website takes too long to load the user is presented with an error screen.
Testing locally, http://playcanv.as/p/MW862amA downloaded roughly 5MB before window.onload and took roughly 30 seconds to get there. I'm betting the search index isn't let it in because of this.
So the fix is simply deferring expensive network requests until after window.onload. The easiest solution is to wrap your network calls in kik.ready(function(){})
I have an application that shows a screen of image thumbnails, each image is around 80k and they are stored in a database. To keep response time reasonable, the appilcation displays a placeholder image when it first starts and later downloads the images from the server. I'm expecting to show around 40 images on the screen at once so that's my batch size. What's the best way to serve these images up to the client? I've got two options in mind.
Create an ADO.NET Data Service that exposes the Images database table to the client. The client can asynchronously request the images, one at a time, and display them as they come back from the server. I've implemented this solution and it seems to work Ok; the speed isn't great and I feel like I could utilize the Http pipe better by requesting maybe 3 images at a time.
Create an HttpModule on the server that looks for requests that look something like /Images/1.jpg and then reads the database and returns the requested data. On the client side I can have many Image objects whose source points to the virtual Urls on the server. My theory is that by just giving Silverlight many Urls to deal with it may be able to transfer the images more efficiently than my code in option 1.
Would either of these methods be more efficient or is there another technique for getting this done? Thanks!
I don't know if it's more efficient, but I've accomplished a very similar task using an HTTP Handler (ashx). The handler pulls the image in from the database based on the Parameters in the uri (image ID), and then Silverlight fetches them asynchronously by setting the Source property of an Image control to the URI of the handler with the specific ID that I want in the query string. The Image control, in turn, is inside of an ItemsControl which allows me to display multiple images.
We are doing something very similar, and we are just using an ASPX page to server them up with a query parameter of the image identifier. We are also caching the images, and the ASPX page will used the cached value if it exists. If not, we pull it from the data store, cache it, and send it down. It is working really well for us.
Have you looked at using Deep Zoom? It's very efficient about progressive image loading, and gives you a nicer user experience when the images are fully loaded.
Examples:
Hard Rock Memorabilia site
Deep Zoom Pix
What are the reasons that cause plugin analytics to use 1x1 img pixels to call their code? What permissions does this shortcut?
The server hosting the 1x1px image logs the request. This allows collecting statistics about who loads (and renders) the page with the image. Browsers in general allow cross origin in img tags.
Also, this allows javascript to be loaded from the same domain as the image.
Behind these image is a server-based script like php, python or so on which can get and log information about the visitor (visited page, referer, ip, ...) for the tracking-stats. The server will be able to get all information you can get on the serverside from a http-request. The benefits of this methods are that it works on nearly all browsers and devices. Its also lightweight because an 1x1 image will cause nearly zero bandwitch.
Its a common solution to track pageviews. To get more flexible, some alternative tracking-methods like pwiki don't even use javascript. They're inserting a tracking-pixel which also works when the user has javascript disabled or he is using some plugins which remove tracking-scripts.
It also works on emails so that the sender has information about which and how much users read for example a newsletter-mail. But nowadays nearly all deskto- and webclients are blocking images in emails by default to prevent these tracking-methods. Images will only be displayed when the user explicit allow this for a specific domain.